Public SourceMage Discussion List

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

Let's please remember to trim replies, people are complaining.

On Mar 29, Eric Sandall [eric AT sandall.us] wrote:
> On Thursday 29 March 2007 10:07:58 Jeremy Blosser wrote:
> > I'm not sure how the branch commands change for git 1.5, I haven't dug 
> > into
> > that yet.
> 
> In 1.5.x all the steps above are the same, but after you push you want to
> do a `git pull` so your clone knows about the new origin/stable-rc-0.9.

Ok.  I wasn't sure how the namespace handled new branches created locally
but that makes sense.

> I'm used to Ibiblio, where adding/removing takes time, so I tend to leave 
> people there hoping they come back. :) If they are no longer around or no 
> longer participate in it, then they should be removed.

Well, for these you'll have direct access to add/remove.

> > Are we going to implement any kind of scheduled job to make sure if things
> > don't get done in that week they get reassigned back?  The problem we have
> > is that people have good intentions that fall through and things get lost.
> > Often.
> 
> We could setup a cron job with bug_cli to check for Codex bugs not
> assigned to sm-grimoire-bugs and reassign them back if no activity has
> occurred in a week.

"Could", yes.  I'll be reassigning everything back to sm-grimoire-bugs soon
so I can nuke the section aliases.  After that I'd like them to stay there;
that's how the other components work, and they do work.  If you decide to
make the policy that people can take bugs themselves, please have this
script working ahead of telling people they can do that.  We need to scale
back and be conservative first and reallow things *after* we have working
safeguards in place to avoid past problems.

> > >   * Once a bug is fixed in test, mark it as FIXED and request 
> > > integration
> > > via flags to affected grimoires.
> >
> > Please define "affected grimoires"... you aren't suggesting requesting
> > integration to stable for every bug that exists in stable, are you?
> 
> Every bug that affects how a package works (so not description changes ;)), 
> yes. The gatekeepers may always deny the request.

I don't think it's good use of gatekeeper time to make them deny things
that shouldn't have been requested.  We should have policy that says what
will or won't be allowed, and things that obviously won't be allowed
shouldn't get requested.

> > >     - Request verification if the bug is more complicated than "update 
> > > to
> > > version X.Y.Z" or "missing dependency on foo" and mark CLOSED once it's
> > > VERIFIED, otherwise mark CLOSED now.
> >
> > Please establish a time period we wait for verification before we just 
> > mark
> > it CLOSED so it doesn't sit open forever.  Also a process to make sure 
> > that
> > timeline is enforced.
> 
> I would say a week is definately long enough.

Are you putting together a wiki page with these things?

> > >     - Mark all bugs CLOSED once they have reached the tarball. If the 
> > > bug
> > > still exists it may be REOPENED.
> > >   * Gatekeepers check for integration requests at least once a day.
> > >   * Integrators check for approved integrations at least once a day.
> >
> > Sorry, but I want a schedule here with names and assigned days.  Not just
> > "everyone expects at least one person will look daily".  This doesn't mean
> > people can't miss one of their days, but it does mean each person knows
> > which days they are supposed to cover and if someone misses it's less
> > likely the next is missed as well (or the next, or the next).  If people
> > want to volunteer to have access or authority they should also volunteer 
> > to
> > be on the schedule.  Your PL is tired of doing this every day himself
> > because it goes weeks between otherwise.
> 
> My issue with this is finding volunteers to do it daily, and they might get 
> burned out.

People are more likely to get burned out if they find they are the only one
actually doing it and feel they have to do it every day.  Giving them an
assigned day or two makes it not their problem any other day.

We either have enough people to cover getting it done daily, or we don't.
If we do, we should make explicit who does what when so people understand
the process and what their actual committment is and so we can assess slip
ups.  If we don't have enough people, we should still be explicit so we
aren't pretending it's going to get done when it isn't.

> I'm willing to do integration requests every day except the weekends 
> (usually 
> gone for wedding planning or out with friends all weekend). The 
> integrations 
> I'd be willing to do Wednesday and Thursday (the other days I'm not home 
> until after 7PM at the earliest). Volunteers for the other days are welcome 
> to add themselves to http://wiki.sourcemage.org/Stable/Integration_Schedule.

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.

> > >   * Tarballs are only regenerated outside the normal 6 hour period 
> > > (test)
> > > or once a week (stable-rc/stable, if any integrations have been made) 
> > > for
> > > security updates or BLOCKER/CRITICAL bugs.
> >
> > I wouldn't expect anything to go to stable that wasn't critical, so I 
> > don't
> > think a "normal" weekly tarball for stable exists...
> 
> That's fair enough, but what should we consider critical? I consider 
> missing 
> dependencies critical (and SECURITY_PATCH, obviously ;)), but then I also 
> consider installed file locations very important. I like a clean, working 
> system and expect our users to want the same. The locations, however, most 
> likely can wait for the next stable run in two weeks.
> 
> Considered critical:
> * Dependency changes
> * SECURITY_PATCH
> * Fixing broken configs (e.g. apache)
> 
> Any others?

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.

Attachment: pgpKRfdZO8ipG.pgp
Description: PGP signature