This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GCC 3.0 Release Criteria


> Date: Tue, 2 May 2000 23:44:03 +0200
> From: Marc Espie <espie@quatramaran.ens.fr>
> Cc: egcs@egcs.cygnus.com

The name of the list has changed, you'll want to update your alias file.

> In article <20000501122203U.mitchell@codesourcery.com> you write:

> This means that, if I find a show-stopper bug in OpenBSD-gcc 3.0, I
> dutifully report it, you will be able to just forge on and say `oh,
> to hell with it, it's not a widely used platform anyway. We can
> always fix it in two years time.'

I think we're on the same page, but the wording may be more inflaming
than necessary.  The process is roughly, people sign up to support
what they want to support, how they want to support it.  They test,
bug fix, and enhance as they see fit.  In the time up to a release,
people do all the things they normally do.  If it doesn't work before
a release process is started, then that _is_ a good indication that it
won't work after the release process completes.  If _anything_ doesn't
work about OpenBSD now, then _now_ is the time to fix it.  As the
release process continues, the opportunities to fix problems vanish,
at Mark's discretion.  If something remains unfixed, it _is_ because
someone didn't care enough to donate the work to make it work.  If you
want it to work, you have to donate the work (or find someone else
that will do that for you, and make the commitment to you).  Mark's
job isn't to commit to doing endless amounts of work, though, Mark,
feel free to do this, you already have a great start on it.  :-) His
job really should be more of coming up with recommended testing
strategies (and he has), soliciting volunteers for assessing and
assuring the minimum requirements he sets, soliciting work items that
people want to commit to for the release, soliciting work items that
remain to be done (he'll do this in time) that people want time to
finish, and so on.  Burried in here, I think is the notion that _if_
some party wants to sign up for task X, then Mark should be willing to
add X to the task list, and list their name next to it.  Doesn't mean
their work is approved, or that it gets in, or that the release will
be held for that work, just means that they will try to do X.  For
example, it should be possible for me to sign up to do vxworks support
and testing if I want.  Doesn't mean someone will do it for me, or
that it will get done (if I flake out).  In the case of OpenBSD, if no
one has signed up to do the work you're interested in, that's
unfortunate, but beyond our control.  If you want to, you can sign up
to do it, if you can't fulfill the obligation, again, beyond our
control.  What I think Mark should resist is adding endless amounts of
work that people don't sign up for.

Work doesn't happen, without someone stepping forward and doing it.
The FSF doesn't commit to doing work, as the FSF technically doesn't
have the resources to do work.  Various people donate what they choose
to, they sign up for tasks, as they see if.  If you want someone to
commit to doing X, _you_ need to solicit such a person.  Mark can
offer to help solicit people (seems reasonable), but he doesn't
guarantee it will happen, nor that he can find someone, in general.

Sorry for the long winded reply, and pardon me if you already know
much of the above, others might not.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]