Re: Arch archive setup

[Andreas Rottmann]

Andreas Rottmann <address@hidden> writes:

> Hi!
>
> I will play around a bit with tla build-config & friends to see how a
> more modularized setup may look like and how it will work. I'll try to
> reach these goals:
>
> * Fine-grained modularization at the arch level: Each module will live
>   in it's own category. I've someting like this in mind:
>
>    - guile-gnome-common: Common build infrastructure (yet to be determined)
>    - guile-gnome-core: The GLib/GObject bindings (perhaps this should be named
>         -glib to follow upstream)
>    - guile-gnome-gtk:  GTK+2, Pango, Gdk, Glade
[...]

In each category, I will setup a dev-0 branch, wich will carry current
development version (similiar to CVS HEAD). I think it will be best to
use taglines throughout the project. 

I will import 'from scratch' (i.e. not tag to my current archives), so
this will be an self-contained archive. My current archive uses
explicit tagging with tla auto-generated IDs (which contain my email
address) instead of UUIDs, so the taglines would be ugly, which is
another reason to start from scratch. 

[ Wingo: It would be really nice to know about your state wrt. syncing
  with my tree, since we need an agreed-upon source base to start
  with. ]

I also intend to make the archive signed.

I also would like to flesh out the archive layout a bit before I go
ahead an create it. After thinking about it a bit, it tend to think it
would be best to follow upstream wrt. to naming and category
boundaries. Since the archive itself will be guile-gnome only, we can
drop guile-gnome from the category names.

I tought of something like this (taking the glib category as an
example):

glib--dev--0: Development goes on primarily here. This akin to CVS HEAD.
glib--release--0.5: Tag-based branch[0] for releases of the current unstable 
series.

[0] http://regexps.srparish.net/tutorial-tla/symbolic-tags.html#Symbolic_Tags

We need to have two concurrent development lines; ATM, we only need
one wich is targetted at GNOME 2.4/GTK+ 2.2.X and we will probably
simply switch that over to GNOME 2.5/GTK+ 2.4 once that is
released. When we become part of the GNOME bindings release set, and
in general, we will want to support the GNOME unstable release before
it is released as stable, so we can ship (relativly) stable and
complete bindings at the time GNOME goes stable. This opens two
possibilties; either:

glib--dev--0:       As above
glib--main--0.6:    Branched from dev-0 when GLib 2.4 is released. Development 
                    for the GLib 2.4 series goes on here.
glib--release--0.5: Tagged from dev--0 for the 0.5.X unstable release series
glib--release--0.6: Tagged from main--0.6 for the stable series

or:

glib--main--0.5:    All development on the 0.5 series goes on here
glib--main--0.6:    Branched from main--0.5 when GLib 2.4 is released. 
Development 
                    for the GLib 2.4 series goes on here.
glib--release--0.5: Tagged from main--0.5 for the 0.5.X unstable release series
glib--release--0.6: Tagged from main--0.6, as above


With the latter the main--0.5 branch would have a dead end, since
development on the next unstable series would go on in main--0.7,
whereas stable stuff goes on in main--0.6. This makes main--0.6
basically unecessary (simply put stable stuff into main--0.5, you can
see from the tags in release--0.6 that this is indeed 0.6
development). I prefer the former approach, since it is how the CVS
model for GNOME works[1]. I and Rob have also chosen this model for
g-wrap, FWIW.

[1] http://developer.gnome.org/dotplan/for_maintainers.html

Tanks for reading all this,
      Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!