From: Phil Muldoon <pmuldoon@redhat.com>
To: Andrew Cagney <cagney@redhat.com>
Cc: frysk <frysk@sources.redhat.com>
Subject: Re: meeting 2008-03-19 - version numbers
Date: Wed, 19 Mar 2008 16:00:00 -0000 [thread overview]
Message-ID: <47E13868.7060507@redhat.com> (raw)
In-Reply-To: <47E12D0D.1020309@redhat.com>
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:
- 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?
- 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).
- Discussion: What current tools now merit the alpha (feature complete,
known bugs exist), beta (feature complete, no known bug exist) and
released state?
- 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.
(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)
>
> 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?
- 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?
- Because we are moving to a more formal release deadline, how do
development practices change, if at all?
- 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 *?
- How can we detect regressions in stability and features
Overall I'm really happy to see this. There's lots to think about.
Regards
Phil
next prev parent reply other threads:[~2008-03-19 16:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-19 15:11 Andrew Cagney
2008-03-19 16:00 ` Phil Muldoon [this message]
2008-03-26 11:53 ` Mark Wielaard
2008-04-01 21:13 ` Sami Wagiaalla
2008-03-19 16:00 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E13868.7060507@redhat.com \
--to=pmuldoon@redhat.com \
--cc=cagney@redhat.com \
--cc=frysk@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).