[Debian GNUstep maintainers] Administrativia (list, repo)

[Yavor Doganov]

I find a few things in the mailing list setup annoying (in decreasing
order of importance):

1) All attachments are discarded.  This is painful when sending a
   patch when the list is in the loop.  If there's a Debian bug in the
   To: or CC: fields, you can still pick up the patch via the BTS, but
   that's one extra step that could be avoided, IMHO.

2) The automatically added presubj [Debian GNUstep maintainers] is
   rather long and not very useful, I think.  There are already List-*
   headers.  I noticed that a release team member was manually
   deleting it, presumably because it made the discussion hard to
   follow on debian-release.

3) Commit notifications?  We can set up an additional -commits list
   for that, but I think the traffic here is not very high so it's
   probably OK to have discussions + bugs + commit notifications at
   one place (provided that Alioth supports notifications for Arch
   repositories, of course).

For 1) and 2), the list admins can act if there are no objections.  3)
is directly related to the repo issue:

It seems to me that only I'm using the Arch repository.  I admit it
took me some time to get familiar with tla-buildpackage and all the
whisles when Hubert had set it up (although I've used Arch before, I
never used it for Debian packaging), and I'd understand that it's more
a burden than convenience for most people.  If it helps, I can update
the wiki page to include my setup, I find it easy enough to keep up my
workflow.

The problem is that with the recent uploads, I have a hard time
merging Gürkan's changes while *still recording* them as a separate
debian release (i.e. no history of the changes is lost, but one cannot
checkout a particular actual debian release with `tla buildcfg
configs/debian/<package>/<version>'.  In short, some archives in the
repo are close to a mess, particularly GNUstep core.

Either we keep using it and taking advantage of merging properly each
others' changes, or we find some other solution (another VCS, another
development process, another ...).  We ought to do something about
that.