-
Notifications
You must be signed in to change notification settings - Fork 281
Roadmap #2067
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi, is there a rough idea about a due date for milestone 2.4.1 and further? |
Hi @seb4web, |
Hi @RincewindsHat , |
I agree. At this point a release would be premature though, I made some rather significant changes and would like to finish some tasks beforehand to have something consistent. Sadly time and energy are rather limited. |
Moving the roadmap from the file in the repository to an issue/issues here.
It was not maintained and here it can be used for communication.
Follow up to #2066 .
Releases in the 1.3 series will be for development. Version 1.4.0 will
be the next full production release. I am not planning on dates right now,
but you can expect maintennence releases for 1.2.9 as well.
With that done, it's time to figure out what we are doing for release
1.3 development. I have a few ideas. Maybe others do as well.
DOCUMENTATION:
We pretty much have decided that we will doing something along
the lines of a literate programming model. So far, we have site
documentation in DocBook. I have some ideas here, which I will
discuss in a separate thread.
OPTION PROCESSING:
I believe we can remove reverse compatibility for non-Getopt
option specifications. For example, 'check_ping 1 2 3 4 -p 2'
would not be supported anymore. Support for this is a hack,
and making it portable is bug-prone. We should also review
standardization of our options -- the current list is a little
ad hoc, it should be nailed down. Details in a separate thread.
Also,
should be fine, but if the getopt in use does not natively support it,
things like
should be trapped and result in a call to one of the usage macros
(which print a message and then exit
STATE_UNKNOWN
).This means that the call_getopt() function can go away. It's an
inconsistent mess and I'd love to ditch it. I only created it to
satisfy people that wanted reverse compatibility and did not have
GNU getopt.
But I would like to urge that all standard plugins contain
validate_arguments(). I think this will help convey the idea that
validations should be done, even if we don't insist on the specific
extent that each plugin must do that validation.
This is the set of standard options I envision:
Reserved:
Recommended, but not reserved:
I am suggesting that port always be
-P
(uppercase) -- we arecurrently inconsistent in that regard.
I am also adding
-q
for silent running. This is totally selfcentered--I am planning to use a plugin in a cron script, and I
don't want nightly emails.
As has been the case, ranges are specified with colons, like
i:j
and list are specified with commas like
i,k
and may contain rangesif it makes sense to do so. Perhaps it would be good to build a
standard list/range processing function for this task.
Programming:
I would like to follow the GNU guidelines and remove all fixed
length character assignments, at least to the extent possible,
from the C-based plugins. To that end, I have made strscpy and
friends in utils.c -- I'd like to deploy them. I have comments
that there is a lot of duplicated code, and techniques used that
should be cleaned up. Details in a separate thread.
Remote checks:
I have a proposal in hand to incorporate ssh check into spopen()
so that remote machine checks can be seamless. A nice idea, but
complex enough to require discussion. Another thread.
I also have a wish list, and I'm sure I've forgot some items. I'll
list mine, please respond with other items that can be put into the
sourceforge task manager:
The text was updated successfully, but these errors were encountered: