Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] new grimoire lead todo

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] new grimoire lead todo
  • Date: Fri, 30 Mar 2007 09:46:54 -0700

On Thursday 29 March 2007 17:28:36 Jeremy Blosser wrote:
<snip>
> > 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.

Sounds fine to me. They can always post to the bug they'll work on it and
hope
others keep that in mind (not that using the Assigned field would guarantee
this either ;)).

<snip>
> > > 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?

It will be in the Grimoire Guru Handbook.

<snip>
> 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.

Then we'll use the posted wiki for assignments/volunteers to do these tasks.
Not every day needs to be filled, but it would be nice. :)

> > 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.

Once a week is likely (as you stated earlier) more than we'd need, so this
should be fine.

<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.

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?

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | http://counter.li.org/ #196285

Attachment: pgpnlwfjUR8ZK.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page