On Wed, 4 Apr 2007, David Nolan wrote:
> Well, I was hoping that Jim was going to respond to this, but since he
> hasn't I will.
Yeah yeah, I'm here, just busy :)
I'll commit to polishing up what needs to be polished (including any docs,
the ancient web page, and RPM packaging for FC6 and SLES10) so that we
can spank 1.2.0 on the butt and send it on its way by the end of April.
I'll also tap the SuSE people on the shoulder and ask them to update
the package they ship, and maybe I can get the Fedora folks to include
it, especially considering that RedHat uses mon internally.
> Don't get me wrong, I'm not upset with Jim over this. He's only one
> man
Yes, and I've been busy at a new place now. I'm working for Unisys in their
Linux development group, and mon development is officially part of my
job, to the point that attention to it is one of my 2007 objectives :)
> I think there are several people on the list who would be interested
> in contributing code & documentation and collaborating on an actual
> release of the current version. What can we do to make this better?
> We could migrate the website into a wiki and grant trusted list
> members access to the wiki
I'm all over the wiki stuff. In fact, I'd actually rather re-do the whole
mon web page in a wiki, and put all the docs into it. I've already been
in touch with some folks and it's likely we'll be able to do this
as mon.wiki.kernel.org.
> more distributed version control system (maybe mercurial?)
...or maybe git!
> make it easier for individuals to submit change sets and get them
> incorporated. But we also need to figure out a way to streamline the
> process of signing off on "official" versions.
Agreed. Let's talk about a process and write something up that we can all
contribute to and agree upon. We can start with something like this:
-versioning is "major.minor.subminor". if minor is even it's a
stable release, otherwise it's a development release.
-a devel version which becomes a candidate for the next stable will
be released with a "subminor" > 100, and named "-devel.tar.gz".
if it can stand up to scrutiny for more than a few weeks, then
it will be called the next "minor" release.
-documentation or web page updates, though valuable, will not
hold up minor releases :)
-we'll call the current trunk major release "2".
-official packaged releases will be made to "xyz" first, whether
it be kernel.org or sourceforge or wherever.
-two people will have the perms to push out releases to the various
locations, and that will be done by either, after a consensus
is reached.
-the contrib archive will be maintained by the above two and a third as
well
How's that for starters?
_______________________________________________
mon mailing list
mon@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon
