From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1523 invoked by alias); 26 Mar 2008 11:53:13 -0000 Received: (qmail 1467 invoked by uid 22791); 26 Mar 2008 11:53:04 -0000 X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,BAYES_50,SARE_NOEMBARRASS X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 11:52:37 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.63) (envelope-from ) id 1JeUBF-00078K-MB; Wed, 26 Mar 2008 12:52:34 +0100 Subject: Re: meeting 2008-03-19 - version numbers From: Mark Wielaard To: Phil Muldoon Cc: Andrew Cagney , frysk In-Reply-To: <47E13868.7060507@redhat.com> References: <47E12D0D.1020309@redhat.com> <47E13868.7060507@redhat.com> Content-Type: text/plain Date: Wed, 26 Mar 2008 11:53:00 -0000 Message-Id: <1206532353.3553.46.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q1/txt/msg00182.txt.bz2 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