[pkg-horde] Organisation of the Debian Horde team

[Lionel Elie Mamane]

(If someone disagrees with what I write, please speak up. When I write
"we will do it like this", understand it as "I propose this as policy,
if nobody disagrees, will consider it adopted".)

On Mon, Dec 19, 2005 at 10:15:44AM -0200, Jose Carlos Medeiros wrote:

> Please give me a resume.

I proposed to Ola to have a rather informal / loose team for
maintaining of the Horde packages; he liked the idea and you didn't
object, so I implemented it.

We have an alioth project. It is used mostly to get the present
mailing list and a GNU Arch repository. GNU Arch is a "better" version
control system. You probably know CVS, well GNU Arch fulfils the same
role, only much better.

A good GNU Arch tutorial is at
http://www.gnu.org/software/gnu-arch/tutorial/arch.html and there is a
wiki with documentation, tips and tricks on http://wiki.gnuarch.org/ .
I also sent examples (the actual commands I used to do actual stuff)
to this list.


We want to avoid the situation where every team member relies on the
others doing $STUFF and thus $STUFF doesn't happen. We thus wanted to
have one official maintainer for each package (not the same one for
each package) who feels responsible for it and the others are there to
help out. By convention, we put this person first in the "Uploaders:"
field.


So that everyone stays up-to-date on what happens, we put this list in
"Maintainer". So the list gets bug mail, testing migration notices,
... People go into "Uploaders". (DDs in the team not in Uploaders for
one package should feel free to add themselves to it and make an
upload. Non-DDs cannot upload but can commit fixes to the repository
and nag the DDs to do an upload.)


> Where can I put new packages ?  Alioth or  Ola ?

Commit them to the repository; Ola or I (or you, Laurent! :-> ) will
make uploads if you tell us you think the package is in an uploadable
state and we agree.


For each package, create a sid branch and an upstream branch. The sid
branch is our main line of development (what we upload to sid), the
upstream branch for tracking the pristine upstream sources. In time,
we will have a sarge branch (and an etch branch) for security uploads
to sarge and all that.


About the GNU Arch naming scheme: For example horde--sid--3:

 - horde is the "category". We put the (upstream) package name there,
   without -h3 suffix. (horde, imp, accounts, passwd, ...)

 - sid is the "branch". "upstream" or a debian release codename

 - 3 is the "version". Version here doesn't mean a specific snapshot
   of the development, but a development line. Think "sub-branch" if
   you want. For horde we'll have horde--*--2 and horde--*--3, for
   example: we maintain horde2 and horde3 packages in parallel. (same
   for imp: imp--*--3 an imp--*--4


We use tla_load_dirs to keep track of upstream in the upstream
branch.


When committing changes, put distribution to "UNRELEASED" in
debian/changelog (like I just did). When preparing a package for
upload, put it to "unstable" and complete the "-- " line with your
name, email and date as usual (and commit that change).


We don't intend to put .orig.tar.gz tarballs in the repository. We
just build with them in the right place and that's it.

> And,  Do I need to change control as below ?

That's the idea, yes. For the reasons explained before in this email.

> ah,, my email to packages, is   debian at psabs.com.br

I've corrected it.

-- 
Lionel