RFC: GNOME Packaging Project

[Gregory Leblanc <gleblanc cu-portland edu>]

Hi folks!  GNOME 1.4 is out, and we should all be back and at least
partly recoverd from GUADEC, so it's time to do some more GNOME stuff.
This message is a proposal for a GNOME packaging project.  I'm looking
for comments on the idea of the project itself, and on the
implementation as I've proposed it.  
Let's start with why we need a "GNOME Packaging Project".  
- First and foremost reason is so we can do better beta testing.  I
have a P-III 800MHz computer, with 256MB of ram as my desktop machine.
I cannot compile the GNOME 1.4 release in less than a full day on this
machine, and I'm very familiar with how to compile these packages.  We
lose 1 day per beta tester if they have to compile from scratch, which
adds up very quickly.  More time than that gets lost if they have any
compile problems, or a slower machine (think how that would feel on
Telsa's "Almost a Pentium" 266MHz computer).  We also lose a great many
potential beta testers (and probably users) because they just don't have
time to compile all of GNOME.
- Second, we need examples of how we'd like things packaged.  They
should show how to break things into different packages for "user only"
vs "developer" packages.  Maintained packages will help out the
distributions that are already maintaing their own packages, so they
can see which things change from one release to the next (files
added/moved, new configure options, etc).
- Third, it will allow distributions to add GNOME.  Writing a proper
spec file, or creating a good debian/ directory takes quite a bit of
time, and can be hard to do if one doesn't have a lot of expierence with
it.  Having some packages already available will give new distributions
a good place to start.
- Fourth, a completely "un-branded" GNOME is nice to have.  GNOME
packaged directly from CVS won't have any Ximian, Red Hat, Eazel, Sun,
or other company logos, because those are things those "VAR"s can add to
their distribution of GNOME to make it theirs.
- Fifth, working packages could enable GNOME to do additional "testing"
cycles beyond the release team planned cycles.  The Nautilus and
Evolution projects have done this already, and it's worked out great.
They're able to ensure the CVS versions continue to compile, and it
gives them a hugely broad testing base, compared with what they'd have
if people needed to compile from CVS.  Frequent builds also mean people
can test if their bug has been fixed in the latest build, making the bug
fixing process much less painful.

Now that I've covered why this project is needed, it's time to cover
some details on the project itself.
Scope: The GNOME Packaging Project (GPP) will have three primary goals.
They are listed here from most important on down, but please don't take
that to mean that the last goal isn't something important.
- First, the GPP should provide automated packaging instructions (ok, so
I made that term up, but it means things like spec files, and dpkg
debian directories) for the major packaging systems.  To start with,
this should include RPM spec files, and dpkg debian directories, as
these are the most widely used package formats.  Hopefully we'll get
volunteers to package things for some of the other breeds of *nix out
there, so that we don't seem so Linux centric.
We need to get these into the modules in GNOME CVS, and we need to make
them well integrationed with the package.  By well integrated I mean
that when the program author changes the version of gnome-libs that's
required, this is automatically reflected in the automated packaging
instructions, and other things along these lines.  
- Second, the GPP should provide binary packages for both stable and
unstable releases of GNOME packages.  This means that when a new version
of a gnome package is released, we grab it, and compile it on whatever
machines we have available.  It also means building packages for major
release cycle betas, such as the GNOME 1.4 beta/release candidate
releases.  Having these binaries available is -critically- important in
order to do any reasonable level of testing.
- Third, the GPP should look to provide regular and frequent builds of
GNOME from CVS.  These should be akin to the hourlies and nightlies that
Nautilus and Evolution provide, respectively.  This becomes rather easy
if we have good dependancy tracking, and good automated packaging
instructions, although it's still intensive on computing resources.

Now it's time to get down to what resources we're going to need in order
to get this done.  We'll need volunteers who know a bit about RPM, dpkg,
and other software packaging systems in order to get the automated
packaging instructions whipped into shape.  This has already been worked
on quite a bit, but needs to get finished/polished, and then put back in
CVS in the appropriate modules, and integrated with those modules.  
We'll also need to have somewhere to build binaries for a few different
platforms.  This means a fast machine, with plenty of ram and drive
space.  Ideally an SMP machine with SCSI drives and a good controller,
so that it doesn't get bogged down by lots of disk use.  There are some
other technical issues, but nothing that we can't overcome.

Now you know what we need, why we need it, and what resources it'll take
to get this done.  I'm looking for thoughts on what I may have missed in
writing this, and for some feedback on the idea itself (since I'm going
to get that anyway).  Finally, I'd like some support from the people
maintaining the GNOME modules in CVS in the form of timely review of
patches, so that we can get the first part of this project done as
quickly as possible.  Thanks,

    Greg


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers