Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] detailed QA stable grimoire and ISO proposal

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Seth Alan Woolley <seth AT positivism.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] detailed QA stable grimoire and ISO proposal
  • Date: Mon, 2 May 2005 20:16:58 -0700

On Mon, May 02, 2005 at 07:41:24PM -0700, Andrew wrote:
> Will the stable-rc grimoire branch be published? Or will it be available
> on a by request only basis or only to those with access to the repository?

I want it to be _very_ published with caveats noted of course. All
power users/tweakers should use it. Developers can continue to use test
and devel directly. Insane people can continue to use test directly.
(I use devel directly on my server but might shift to test directly if
we follow this process).

>
> Will there be a schedule for grimoire and/or iso releases? Eg, a new
> stable grimoire release about once a month. Test isos once a week
> (autogenerated from stable-rc) and stable isos shortly after stable
> grimoire releases (so also once a month).

I don't think a schedule is in the works -- the proposal below assumes
doing things on a weekly basis though. I'd like to, say, always do the
large branching updates on a saturday (when I have free time). When a
week has gone by and there are no bugs that make it _worse_, it goes in.
stuff from stable can be pulled in to stable-rc to make it work if test
is too badly broken, for example, but I intend for it to only get better
(of course, the bugs found after stable-rc is tested will prevent this),
so at first, I think I might put a maximum testing time of four release
candidates, so we at least get something out each month until our
process settles down.

>
> You mentioned in the previous thread about a tag in bugs for needing to
> be fixed in stable. I can easily add that if it will be helpful, (Eric
> and Adam can too). You can query for it using the boolean charts at
> the bottom, add the following to query for them.
> "flag" "contains string" "<name of flag>" AND
> "flag" "contains string" "+"
> At least, that works for me with iso bugs that are using flags.

Yes, that would be helpful. Thanks a bunch. Can you limit it only to
certain people who can add that tag? If not, We can just make it so
that you have to comment that you changed the flag when you do change it
so I don't have to go into bug activity and figure out who set it for
every bug before integrating.

Also, I'd like to delegate the inter-stable integrates to stable to
certain people who like to be really skeptical and have some free time
on their hands (preferably people who are already developers, but if you
pass some pretty strong background checks, I might turn a new developer
away at it). I like to delegate, but I don't want them approving every
request to stable just because. Good reasons needed.

Seth

>
> -Andrew
>
>
> On Mon, May 02, 2005 at 06:51:15PM -0700, Seth Alan Woolley wrote:
> > === stable grimoire updating process ===
> >
> > We have three main grimoires, devel, test, and stable:
> >
> > * devel contains all spells plus works-in-progress, identified by a
> > WIP file in them.
> >
> > * test contains all spells that should work but haven't had gauranteed
> > testing. The guru's intent is that, yes, this spell, to the best of
> > my knowledge, will work as well as the previous versions. If not,
> > it goes in devel with a WIP.
> >
> > * stable should have been well-tested.
> >
> > For our purposes, those are our axiomatic definitions of each grimoire.
> > To resolve debates about what should be in whatever grimoire, those are
> > our definitions. I have final say, of course, besides GL and PL, who
> > out-rank me in this matter.
> >
> > To get between devel and test grimoire, we have gurus, each guru is
> > responsible for their own decisions here. Final call goes to the
> > grimoire team lead (I have no place here) if there is any debate.
> >
> > To get between test and stable grimoire, immediately after each stable
> > release, the test grimoire shall be immediately forked off into a
> > "stable-rc" grimoire. RC means "Release Candidate". Prometheus and
> > other testers should be testing stable-rc grimoire to make sure one can
> > update from stable to stable-rc safely and relatively painlessly. What
> > I mean about "painlessly" follows:
> >
> > * Version updates that break apis shouldn't do too much damage here,
> > but
> > there's only so much we can do about that. This should be documented.
> >
> > * Any known issues about updating should be documented prior to the
> > stable release and packages as "release notes".
> >
> > * All bugs that exist in stable-rc grimoire but not stable grimoire
> > should be fixed before release. If they show up afterwards, we must
> > either wait until the next release to fix that or if it is of a high
> > enough priority, they should be integrated into stable.
> >
> > * Disputes about what goes into stable are decided by any person I
> > delegate, myself, GL, and PL, in that order.
> >
> > If that's good enough, I'd like comments and volunteers for people to
> > run on prometheus on stable-rc grimoire when I've fixed it up a bit.
> >
> > === stable grimoire versioning ===
> >
> > To better track issues, the stable grimoire should have versions. They
> > will be done like so:
> >
> > There will be three parts to the stable grimoire version:
> >
> > * MAJOR VERSION: This shall be "0" at first, and changed only for
> > major ISO releases.
> >
> > * MINOR VERSION: This shall be incremented, starting at "0", for each
> > stable release between ISO releases.
> >
> > * REVISION: This shall be incremented whenever security updates or
> > major bugfixes are integrated into stable grimoire between QA
> > declares
> > the release official. It starts at zero.
> >
> > Each version number shall reset all inferior version numbers when they
> > are incremented.
> >
> > We will start at 0.0.0 stable release (I know, cool). When a security
> > update is applied, it shall be 0.0.1. When a stable-rc is made stable,
> > it will be 0.1.0, and a security update on that would be 0.1.1, and so
> > on, until the next ISO is released, which will make it 1.0.0.
> >
> > === ISO release process ===
> >
> > To better follow ISO development, the ISO process itself will be
> > recreated for each stable grimoire release. If there are any major
> > issues with the ISO after one week of testing, it will continue with -rc
> > status. So all ISOs will have -rc designation at first. When no known
> > bugs exist for the ISO, it will be released as -rc still and aliased as
> > a major stable ISO after one week of community testing with no
> > additional bug reports and a release notes list of issues that are
> > acceptable to the QA TL, the ISO TL, and the PL, the PL of course able
> > to override any decision here.
> >
> > Lately I've been working on trying to get the ISO build process
> > documented and somewhat usable by filing an enormous amount of bugs
> > against the proj3 branch (which is our current devel branch). When
> > that's sane enough, I'll integrate it into the grimoire release process
> > as I mention in the paragraph above. (I spent all weekend on this, so I
> > apologize for not jumping on the stable grimoire release process like I
> > should have that warranted the questions to the grimoire in a previous
> > thread). FYI, the build process is distinct from future work on the
> > next-generation installer, of course (being worked on somewhat
> > separately).
> >
> > So again, any comments?
> >
> > Seth
> >
> > --
> > Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
> > Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737 F2FF 7A3F 6D3C 00BA 3AF3
> > Quality Assurance Team Leader; Security Team Member, Leader Emeritus
> > Linux so advanced, it may as well be magic http://www.sourcemage.org
> > Elected Coordinating Committee Member, Secretary, and Finances Chair
> > Pacific Green Party of Oregon - Peace - http://www.pacificgreens.org
>
>
>
> > _______________________________________________
> > SM-Discuss mailing list
> > SM-Discuss AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>
>
> --
> __________________________________________________________________________
> |Andrew D. Stitt | astitt at sourcemage.org |
> |irc: afrayedknot | afrayedknot at t.armory.com |
> |aim: thefrayedknot or iteratorplusplus | acedit at armory.com |
> |Sorcery Team Lead | ftp://t.armory.com/ |
> --------------------------------------------------------------------------
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
>

--
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Key id 00BA3AF3 = 8BE0 A72E A47E A92A 0737 F2FF 7A3F 6D3C 00BA 3AF3
Quality Assurance Team Leader; Security Team Member, Leader Emeritus
Linux so advanced, it may as well be magic http://www.sourcemage.org
Elected Coordinating Committee Member, Secretary, and Finances Chair
Pacific Green Party of Oregon - Peace - http://www.pacificgreens.org

Attachment: pgpMtZxoJpWED.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page