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]
Other format: [Raw text]

Re: your gcc 3.1 release date is a joke


> Please don't whack the user.  It is not his fault he expected it, it
> is our fault.

In the GNAT world, we never ever give even a hint of schedules for public
versions of GNAT. People keep asking us for rough estimates, but we are
adamant in never giving schedules. Why not? Because all work on public
releases (including work on the FSF version) has lower priority than
funded work for our customers, which can at any point preempt the work
in getting public versions out. We don't apologize for this attitude
at all, since it's what keeps ACT financially viable, and the having    
a strong ACT is in the long term very important for everyone in the
Ada community, including students, hobyists, free software builders   
and others using the public versions.

We figure that the only way you get even estimates of time schedules is
by being a paying customer, and if you really need hard deadlines, then
specific contracts need to be negotiated.

The GCC development is largely done by volunteers who ultimately mostly
have the same kind of priorities on their time, so despite best intentions,
they may not be able to follow through with commitments on time.

So perhaps what is needed on this list is a constant reminder that any
schedules announced are for the benefit of *developers* and are for the
purposes of coordinating work. They are never commitments, or even 
suggestions of time schedules that outside users can rely on. 

My own feeling is that reliability is more important than getting something
out quickly. People who want the latest and greatest can always grab snap
shots and fiddle (and even help by reporting errors). 

I think Mike goes a bit far in saying it is "our fault". It is not a fault
to delay the release until it is in good shape, it is by far the best thing
to do. 

Again going back to GNAT, we often get ferocious criticism for not rushing
public versions out of the door more rapidly, but we just let it bounce
off. We know that the great majority of users of the public version of
GNAT appreciate being able to get a high quality Ada compiler for their
research work etc, and are happy to wait till something is in good shape.

It seems to me that the community of GCC users breaks into several groups.

1. Those who want to play with the absolutely latest version of the technology
and don't mind if it comes with some instability. They have access to the
snapshots.

2. Non-commercial users, who want something reasonably reliable, for
example for working on Free Software projects of their own. We do not do this
segment a favor by rushing out new versions before they are ready. They will
do fine using the previous reliable release, and working around problems.

3. Those who are using the technology for commercial purposes, and need and
rely on scheduled releases, reliable fixing of problems etc, and are willing
to pay for those services. For this group, companies like Redhat, ACT, etc
exist and compete in the market like any other commercial companies. We hope
they will contribute to the open development effort as well as benefit from
it, and for the most part that seems to work well.

4. Those who are using the technology for commercial purposes, and need and
rely on scheduled releases etc, but who are not willing to pay anything. To
such people we say "you get what you pay for", and we should be sure not to
let the loud shouting and grumbling that is presented in lieu of effort or
financial support affect us. In particular, we do not need to adjust our
priorities in response, and most importantly, we must avoid getting 
discouraged or depressed by what seems to be unjustified criticism.      

It seems to me that Mark Mitchell does a remarkable job of managing the
release and the procedures he follows serve the needs of audiences 1-3
just fine. Managing releases is a very difficult job under the best of
circumstances. Doing it when you are relying on volunteer help is really
difficult!

Robert


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