CVS question for gnome2.2. Which modules, which tags?
- From: Darryl Rees <rees netnam vn>
- To: gnome-love gnome org
- Cc: gnome-list gnome org
- Subject: CVS question for gnome2.2. Which modules, which tags?
- Date: Wed Jan 1 11:46:13 2003
During the lead up to the gnome 2.0 release, most (but not _all_) gnome
cvs modules converged over time to using a gnome-2-0 branch. I'm sure
the same is happening for gnome-2-2. Without poring over mailing lists,
is there somewhere on the gnome website where the following information
is kept up-to-date?
- which modules are officially anointed as part of the gnome desktop,
which modules are part of gnome fifth-toe, etc, for each release point.
- which modules are 'under consideration' for officially sanctioned
release, or what status they are at generally
- which cvs branches are appropriate for the current and soon-to-be
released stable releases.
eg problems
- rhythmbox is on gnomecvs (I think there was other gstreamer stuff here
until recently?), but gstreamer - which it depends on - is on
sourceforge. I believe gstreamer is 'close' to being assimilated into
gnome proper, and the set of gstreamer apps fill an important in the
gnome suite.
- rosegarden on gnomecvs has not been modified in years, and is now a
kde app
- lots of modules under gnomecvs that have been 'forgotten', have never
worked or not worked in years (ie. pre 1.4). ie. the old wheat and chaff
problem.
I know the standard answer to these kinds of questions is 'go and use
xxxx build script and don't worry about it' - I like to roll my own
buildscripts (which have their own little advantages), but also this
seems like a very basic thing that should be well documented somewhere.
Rooting through the various mailing lists to discover this kind of thing
is very time-consuming, I'm hoping it is documented somewhere that is
accessible, clear, and up-to-date.
I often wonder if a modified sourceforge type of interface wouldn't be a
better way of organizing the gnome development effort - imposing some
structure, distributing responsibility (eg for keeping documentation
up-to-date), making the development effort more transparent, etc. The
current website & cvs repository is a bit structurally incoherent, and
hard to become familiar with if you are a new developer. For example,
there are a lot of tutorials and other documents on the website that are
soooo old and out of date, but it is difficult to even know if/how much
out of date they are (no dates, no history/revision info etc). Just a
thought.
Thanks in advance
Darryl Rees
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]