Re: TI-calculator packages team maintained in debian-edu or debian-science on alioth?
Hi Holger & Andi,
On Sat, Jun 15, 2013 at 10:55:47AM +0200, Holger Levsen wrote:
> Hi Andi,
>
> On Samstag, 15. Juni 2013, Andreas B. Mundt wrote:
> > I had a look at the debian-science alioth repository, they use a
> > subdirectory 'packages' for packaging [1].
In general I would (strongly) recommend to create some packaging policy
as it is written for Debian Science[1] and Debian Med[2] (in this case
Debian Science packaging policy is not as well maintained as I would
love it to be - well, all such documentation work needs time...)
> > So I suggest to follow
> > that convention and put the source packages in debian-edu/packages/
> > like:
> >
> > debian-edu/packages/libticables
> > debian-edu/packages/libtifiles
> > debian-edu/packages/libticonv
> > debian-edu/packages/libticalcs
> > debian-edu/packages/gfm
> > debian-edu/packages/tilp2
+1
> I'd rather have debian-edu/packages/tic/* - because for "normal" Debian Edu
> developers these package have little / less interest and they seem to be many,
> cluttering the packages view.
I noticed you quoted "normal" and IMHO exactly this is the weak point in
your whole argument. With "normal" you want to say status quo or so
because currently (at least to my knowledge - correct my if I'm wrong)
the Debian Edu team maintains rather packages that build up some
infrastructure than packages that are typical education applications.
If you drag this a bit into another corner Debian Edu packages things
that belong into Debian Enterprise scope. For sure the Debian
Enterprise team does not really exist and you have a very specific
interest in schools but I just want to make clear what I mean that you
are not actively working on educational applications as packaging team
which is very different to what Debian Science, Debian Med, DebiChem,
Debian GIS or Debian Multimedia (actually any other Blend) are doing.
This difference in your approach lets you call "normal" what others
would call "anomalous". There is no "good or bad" in this different
approaches - it is just different and now you are consider adopting a
strategy of teams that work different which might be worth thinking
twice about. That's why I would recommend discussing a policy document.
I personally would recommend adopting one of the existing packaging
policies. If I remember correctly Debian Med policy was once branched
from Pkg-Perl policy and Debian Science policy might have branched from
Debian Med policy later. I'm not sure - I was not initially involved of
any of these documents but they turned out as very reasonable tool
specifically if you want to attract newcomers.
> Similarily I would put the debian-edu-* packages
> into packages/core/ and slbackup, italc and others into some other subdir.
The subsectioning into subdirs might lead to the question where to put
packages that might fit into both subdirs and will end up with people
failing to find a package. I would not recommend to make a science out
of creating subdirectories. Moreover as I recently read[3] there is a
nice solution how to just list your own teams packages in Git[4]. This
should be sufficient to keep about 100 packages.
> > When taking a look at debian-science, I realized that the packages fit
> > also there (Data Acquisition/Hardware). What is the better fitting
> > team? Any oppinions on that topic?
We have several packages that do fit into different teams. The Debian
Med team shares interest in several packages that are maintained by
DebiChem and we never "fighted" about a location where the package
should be stored. Practically several members of both teams are also
in the other team and so there is some cross-exchange. The final
decision where a package is maintained is actually drawn by the fact,
to what team the initial packager is affected more deeply.
If you look into some packages inside the Debian Med repository you will
see that we even keep packages with no relation to our target at all -
but that are needed as precondition / dependencies for medical packages.
For us this has the practical consequence that we as a team will be
informed directly about problems with the package. If we would choose
the alternative and dump such stuff in the worst case to collab-maint it
would somehow be orphaned from the team and if the original packager for
whatever reason would not be able to care nobody would notice.
> collab-maint/ is another good option.
s/good/bad/
(see above)
> Every DD is automatically a member and
> any alioth user can become one easily.
If ACLs[5] are set properly any team VCS could (actually *should*) have
this feature. Admittedly this seems to take longer nowadays (pending
for Debian Multimedia > two monthes [6] :-() but this might be a
temporary thing bottleneck - for all other teams I know this was
implemented quite quickly and is a really good way to decrease the entry
barrier for newcomers to the team.
Honestly, if I were you I would try to drag all those maintainers of
education relevant packages into a common repository. We did the same
in Debian Med and this turned out to be a real success. There is only
one (stubborn ?) maintainer left "outside" (and his packages are
outdated and in a bad state :-().
Kind regards
Andreas.
[1] http://debian-science.alioth.debian.org/debian-science-policy.html
[2] http://debian-med.alioth.debian.org/docs/policy.html
[3] http://blog.brlink.eu/index.html#i64
[4] http://anonscm.debian.org/gitweb/?pf=debian-edu
[5] https://wiki.debian.org/Alioth/FAQ#How_do_I_give_write_permission_outside_my_Alioth_project_.3F
[6] https://alioth.debian.org/tracker/?func=detail&group_id=1&aid=314215&atid=200001
--
http://fam-tille.de
Reply to: