Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Mar 30, Eric Sandall [eric AT sandall.us] wrote:
> On Thursday 29 March 2007 17:28:36 Jeremy Blosser wrote:
> > Are you putting together a wiki page with these things?
> 
> It will be in the Grimoire Guru Handbook.

No offense, but we haven't seen an update to that in a very long time.  I
know you *are* doing work on it actively now, but can you make a scratch
wiki grimoire policy page to hold these things/refer people to until the
handbook is there?  These questions come up pretty often during the release
cycles and not everyone remembers it all.

> > I added a "tarball generation" schedule as well; for my part I'll check 
> > for
> > a new tarball every Friday evening and make one if necessary.  I'll also 
> > be
> > available to fill-in if people need it either on specific days or for
> > specific requests if the right person isn't around and I am.
> 
> Once a week is likely (as you stated earlier) more than we'd need, so this 
> should be fine.

Someone should check daily for tarballs needed by security integrations, if
nothing else.  Ideally there is someone around when those integrations are
needed to make the tarball but that doesn't always happen.

> <snip>
> > This one is one more level removed even from the conversation about what
> > should get a patchlevel increase.  A high percentage of fixed bugs apply
> > to stable, but fixes should not get integrated to stable unless it's 
> > really
> > needed.  Pushing unnecessary things breaks the versioned model we have and
> > wastes time.  It's also not generally necessary when time is better spent
> > keeping releases happening often enough.  We need to prioritize, and
> > pushing a lot of stuff to stable out of cycle is not a good way to do 
> > that.
> > Not dealing with this is part of what got everything so broken before that
> > we didn't do any releases at all.
> >
> > IMO nothing should go to stable out of cycle that isn't a security fix or 
> > a
> > critically broken spell that doesn't have a simple workaround.  Critically
> > broken means it doesn't build or doesn't run.  Simple workaround means a
> > workaround that can be done with one or two lines and forgotten about.
> > Workarounds that have to be gone back and undone are not simple.  So, a
> > chmod is ok, moving config files around both for the broken version and
> > then for the fixed version later is not ok.  We also need something in
> > there around scope of the problem, including how many people it affects.
> >
> > Dependency changes shouldn't count if they're just a matter of a missing
> > required spell, because the admin can just cast that spell themselves; 
> > that
> > fits the definition of a simple workaround.  Complex missing dependencies
> > or missing dependencies in important packages may be another issue.
> 
> Given we can keep up a two week release cycle for stable, then I'll agree 
> to 
> this. ;) Since if we do it my way, the two week release cycle would bog 
> down 
> and probably not make it in two weeks.

Well, we don't have a two-week cycle now, we have closer to a four-week
cycle.  Between two or three weeks to do the release, and a week-or-so in
between.  Which I still think is plenty fast enough.

That brings up another question; I think all of you talked about making a
longer release cycle during the election.  What timeline are you thinking?
IMO the 4 week thing is working well; plannning to always branch the next
-rc on the 1st of the month makes it easy.  If we make it longer I don't
think it will actually buy us any more time; people already wait til the
few days before to do most of the work and the longer we go the more work
there is to do.

> Considered critical:
>   * SECURITY_PATCH
>   * Spells which won't compile and cannot be easily fixed (easily fixed 
> being: 
> one line edit, cast the proper dependency ahead of time, dispel package X, 
> etc.)
> 
> Sound fair?

I think it will probably need more definition than that as time goes on
but it's probably fine to start with.

Attachment: pgpUqmtZZjya0.pgp
Description: PGP signature