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

[Tom Tromey <tromey cygnus com>]

>>>>> "Martin" == Martin Hess <martinh@scruznet.com> writes:

Martin> 1) Automate initial checkout and configuration. This is to
Martin> provide a single button first time checkout and configuration
Martin> for those who want to get started. This can be a package, a
Martin> perl script or whatever.  What is important is that a newbie
Martin> can just compile and run without going through a long learning
Martin> curve. This means that any dependencies on external tools and
Martin> libraries must be taken care of by this script.

configure does take care of these dependencies, sort of.  But I think
our experience is that people will try to build with arbitrarily weird
configurations, e.g. missing the X headers and libraries.

I don't think we'll ever get to the point where a newbie can build
Gnome with no problems at all.  Newbies should use RPM.  (I assume
here we're talking about "real newbies", and not hackers who are new
to Gnome.)

I do think we can get to the point where Gnome will configure on
basically any reasonable (<- weasel word) system with no problems.
This works for hundreds of other packages after all.

Martin> 2) Integration group. Only some small set of developers
Martin> checkin to the cvs trunk. Everyone else works off their own
Martin> branch from the trunk.  The integration group is responsible
Martin> for merging branches into the trunk and checking in.

As I see it, the problem with this plan is that it doesn't mesh very
well with the nature of free software development.  Who wants to spend
time integrating?  It sounds like a lot of pain and no fun -- and in
open development like this there is no lever (i.e., paycheck) that you
can use to force people to do boring, repetitive tasks.


More fundamentally, I don't see integration as a very big problem.
The people who work on Gnome most frequently don't have any problems
here at all (I'm not in that group, but I also don't have problems
with it, since I've found a style of work that suits what I do).

That is, we have to examine what the goal is here.  As I understand
it, from Todd's original "rant", the problem is that the Gnome
developer with little free time invariably spends it updating and
rebuilding Gnome.  This is a function both of the size of Gnome
(meaning primarily the number of dependencies) and also the rate of
change.


Given the above, it seems clear that we should look for a solution
which doesn't really change how frequent developers work (it ain't
broke for them), while allowing less-frequent developers to work more
effectively.

Todd's idea of more frequent "semi-stable" releases would do this.
Maybe there are other possibilities.


Note that you don't have to wait for somebody to do this!  You can
easily do it yourself by just checking stuff out and setting it up.
This would be a great way for somebody to volunteer without committing
a lot of time.

Tom