Re: meeting 2008-03-19 - version numbers

[Mark Wielaard <mark at klomp dot org>]

Hi Phil,

On Wed, 2008-03-19 at 15:59 +0000, Phil Muldoon wrote:
> Andrew Cagney wrote:
> >
> > a) move frysk forward to 0.8.x, from 0.0.x
> >
> > This is to signal that we consider all our tools are minimally at 
> > alpha (key functionality is present but more to come); and for many 
> > tools they are actually beta/release quality (e.g., fstack, fcore, 
> > fcatch).  As fhpd and frysk mature we can move to 0.9 and 1.0.
> >
> There was quite a bit of discussion about this in the meeting.  My 
> biggest issue was messaging to the user/community why we have decided to 
> do this change. What is our reason for changing from 0.0.1* to 0.8. Is 
> it a saner system? Are we signaling we are much more stable? In all 
> aspects or just some? Anyway ...
> 
> My questions, (mercifully rendered ;) down to several points:
> 
> - I've no objection to this. It moves us to a saner versioning system.  But:

No real objection here either. Any versioning/naming system is really
fine with me. As long as we try to push out regular releases with
updated news entries so people know what they can expect to have
improved/changed.

> - Discussion: How/should we maintain all the tools at a similar level of 
> quality, and progression. Is moving to 0.9 going to mean the that the 
> UI  is in step with fcore, fhpd, and all the others?

Clearly different tools are at different maturity levels, lets not worry
too much about this till we are truly thinking of a 1.0 release. Lets
just mention in the release notes what works/doesn't work for now. If
you are worried about version number inflation or giving the wrong
impression about stability to our users then lets do either release
names or release versions based on the date/month. Or just start at
0.4.x or something low to better reflect where we think frysk stands
maturity wise.

> - Discussion: What are the criteria for moving major version numbers: ie 
> 0.9, 1.0 and so on? Stability only? Are we going to gate version number 
> on features? What's the release number to feature road-map? (there was a 
> long discussion about feature embargo here which is something to really 
> avoid).

I think it is way too early for feature based releases. Lets just do
regular time based releases for now.

> - Discussion: What current tools now merit the alpha (feature complete, 
> known bugs exist), beta (feature complete, no known bug exist)  and 
> released state?

Probably the focus should be on ftrace, fstack, fcore, fcatch, then
fhpd, then the rest of the f* utils and finally the gui. But lets not
stretch ourselves too thin.

> - Discussion: Wildcard. Because the tools are of varying maturity, which 
> differs from the maturity of the ui, which differs from the maturity of 
> the frysk-core, should a move to 3 (or 4 with -devel) rpms be 
> considered. Right now I believe we have one srpm/spec file that produces 
> 3 sub-packages.

Splitting at least the core, utilities, maybe fhpd and the gui would be
good to show our users they are on separate development tracks. Being
able to build frysk without the gui parts at least would be good thing
seeing how little development goes into the gui these days. It would
help packagers because then they don't have to deal with java-gnome
dependencies.

> (I know a lot of these questions were asked and answered in the meeting, 
> I'm just asking them here as question to answer for the the mailing list 
> crowd)

Thanks. The meetings are often a bit too long to keep focused. Having
this archived on the list is a good thing imho.

> > b) move to regular (monthly?) patch-level releases; e.g., 0.8.1, 
> > 0.8.2, ...
> I've no objections to this. But:
> 
> - What release schedule? Weekly? Monthly?

Monthly/Bi-Monthly seems like the time needed to really work on new
stuff. Anything shorter means there is only time for (emergency)
bugfixes.

> - How will we be smoke testing the results to ensure sanity (ie the last 
> patch pushed screwed some stuff up). Our test cases can catch a lot of 
> this?  What is the release checklist?

This is a good question. A good idea would be to make sure each manpage
includes an example section for each utility and make sure the release
master at least runs each example by hand to make sure there are no
embarrassing bugs on first run for our users.

> - Because we are moving to a more formal release deadline, how do 
> development practices  change, if at all?

I would suggest to just declare a commit stop for a couple of days
around the release. Later on we can create proper release branches, but
git makes it easy to do development without having to push to mainline
all the time anyway.

> - What is our release matrix. Fedora 8 now, and Rawhide. But will it 
> then be F8, F9 and rawhide all in sync? Will the release be to rawhide 
> first, then a monthly push from rawhide to Fedora *?

I would suggest decoupling the distro packaging from the actual release
process. Even though the same people might also do the packaging for
fedora, debian, etc. It is probably a good idea to at least run the
testsuite and smoke tests on the latest releases of the most popular
distros (or just what any of the developers have available). If possible
include test results in the release notes so packagers know what to
expect (or tests sometimes rely heavily on the compiler/kernel, so it
would be good to get packager feedback on the test results).

> - How can we detect regressions in stability and features

Well if the unit tests are pretty complete, and the smoke tests well
defined... :)

> Overall I'm really happy to see this. There's lots to think about.

Cheers,

Mark