Re: RANT!!! (was Re: ORBit and gint64 Re: ORBit gmake fails)

[Todd Graham Lewis <tlewis mindspring net>]

On 23 Jul 1998, Tom Tromey wrote:

> I think the basic problem is that the CVS repository is in a
> continuous state of change.  It's not like the glib version number is
> incremented with every checkin.
(...)
> The problem is that it is actually hard to determine when you should
> send out such a message.  This is particularly true when you are
> working on some layer that is removed from the basic infrastructure.
> For instance, I certainly don't read every single Gtk+ commit message.
> So it's possible I would inadvertantly use some new API without
> realizing that it is new, and hence not know to send out a "you must
> rebuild Gtk+" message.

Yeah, I can see that.

> Does this address your concerns?  I feel like I'm missing something,
> but I don't understand what it is.

I think it's an expectation issue.  Maybe gnome has just grown so big
that this sort of stuff happens.  I do know that I don't like this entire
class of problems because it causes a lot of friction for those working
out of CVS; wasted time fixing non-problems, tons of questions to the
mailing list, etc.  I also fear what this sort of episode does to casual
developers out there.  Maybe we're still in the Real-Men-Only stage of
development(r).

Despite my frustration, though, you do raise a valid example of when
this sort of thing can happen, and I can't think of any way to solve
the case which you bring up.

The answer is to stop developers from _having_ to use CVS.  If we had
much more frequent releases, then people could do development off of
the rpm/dpkg/tgz versions which would be made free of these problems.
I could see getting one of these out the door every week or two, and
that is one area where I could actually help out a lot.  If it were a
simple matter of (dpkg -i * | rpm -U * | rm -rf /opt/gnome; tar zxvf *),
then more casual developers could stay up to date much more easily.

Slashdot bonus: Gnome announcements could be posted and read much more
regularly.

I think that the important part would be testing each package against
its parents (packages it depends on) across a range of versions, so that
people don't have to upgrade the entire suite (witness certain developers'
on this list penchant for binary-incompatible minor-number releases.)  If
you did this, then people could upgrade the pieces that they really need,
and they would see much more friendly messages like:

	gnome-foo requires glib >= 3.1415, whereas you only have 3.14.
	Please upgrade glib.

Rather than:

	syntax error in libORB/foo.c after my_butt_is_long();

This would require actually incrementing version numbers and all other
sorts of Miguel-level authorization; it would also require that everyone
get all of their changes casually debugged and checked into the tree
before 3PM every Friday when whoever (I'd be happy to give it a go)
did their checkout and began building the packages.  I do think that it
would help things for developers who can only put in <10 hours / week,
and that's a not-insignificant portion of the potential developer pool
out there.

How crazy am I?

--
Todd Graham Lewis                                     (800) 719-4664, x2804
******Linux******         MindSpring Enterprises      tlewis@mindspring.net