Public SourceMage Discussion List

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

Sorry for a drive-by reply, but I don't have much to say on this anyway.

On Jan 04, David Kowis [dkowis AT shlrm.org] wrote:
> Alexander Tsamutali wrote:
> >> I'd like to have a freeze on the grimoire when we come up to release
> >> time. No commits to test until we've finished fixing the bugs that have
> >> to be fixed. That's it. No exceptions. "Real" software processes work
> >> this way. You've a feature freeze and then you work on the release.
> >> Anything spiffy or unneccesary is omitted, or put off until later. We
> >> don't do that. We're pretty lax.
> > 
> > That's exactly what i proposed here:
> > https://lists.ibiblio.org/sympa/arc/sm-discuss/2007-January/015995.html
> > Can we adopt such process?
> 
> Close to what I'm thinking of. Except let's not just limit it to QA
> leads or anything. Anyone can commit to stable-rc at this time, perhaps
> they operate through submitting patches through the leads, or a group of
> volunteers, so that it's guaranteed to be peer-reviewed. But we
> completely lock down the test grimoire, it's frozen. stable-rc gets it's
> bugs fixed, and the release is pushed out to stable.

option 1) people work on what they want to work on, regardless of other
          concerns

option 2) people work based on a list of goals that need to be done,
          regardless of what they want to work on

Pick one.  If you have enough resources you usually have enough people that
both get done without forcing one or the other, but we don't have enough
resources for that to happen.  We may not have enough resources for either
to really get done.

Historically we've explicitly used option 1.  There's no real question
that's a big reason we're where we're at right now.  Not that I think we
should necessarily change that, or even could if we would -- a distro that
attracts people who do things their own way is not going to see good
results trying to tell its devs where to spend their time.  The question is
mostly if we are ok being at where our chosen model leads, or if we need to
be schizophrenic about our chosen model vs. some people's desired results.

> >> On the other end of the spectrum, we could simply drop stable-rc and
> >> stable, since no one works on them anyway. I don't like this idea, but
> >> it would be the opposite of what I described in the previous paragraph.
> > 
> > We cannot drop stable releases, never.
> 
> I know, this was just showing the opposite end of the spectrum.

Well, if we don't have resources to honestly provide a stable release in a
timely manner, we either should fess up that it's going to be debian-style
stale (but stable) or if we hate that too much we should just drop it and
stick to a bleeding edge grimoire that we can actually try to keep working
on.

Bottom line for me: we can either keep trying to be something we simply
don't have resources to be and yell at each other when it doesn't happen or
we can just do the work we can do and live with that.  The fact that the
current stable release attempt is still apparently stalled at least in part
over that init.d issue speaks volumes on what we're currently actually
capable of accomplishing toward a stable release.  That is in no way an
issue that requirse a rocket scientist to fix, yet no one apparently has
time to look at it.  What's the point of arguing about process holding us
back if we can't marshal the manpower to fix a basesystem bug that's been
open that long?  It's even 99% diagnosed, it "just" needs fixing.
Obviously I haven't had time, but I find it hard to belive *no one else*
has had time either.  I don't care if you think you're not qualified, I
expect that if init.d in test was broken such that machines wouldn't boot
in common configurations someone would have stepped up and figured out how
to fix it by now.

Attachment: pgp5VMcflar0g.pgp
Description: PGP signature