Re: FWD: [Bug#528733: O: svn-buildpackage -- helper programs to maintain Debian packages with Subversion]
Hi all,
just a few thoughts:
Le Fri, May 15, 2009 at 01:41:52PM +0200, Andreas Tille a écrit :
>
> So I would consider it as valid approach to follow the style of Debian Science
> to provide SVN and Git as options. This leaves enough room for experimenting
> and enables me to stay with SVN as long as my bandwidth at home became
> acceptably fast to pull large upstream code chunks (which is in my eyes the
> worst thing in Git - but this is my personal problem).
Currently our SVN repository is world-writable for all DDs. I do not remember
if it is the same for Debian Science's SVN and Git repositories. If they were,
maybe we could consider hosting our Git-managed packages there. I see only two
potential drawbacks:
1) Write access for -guest accounts is still managed through Alioth project
membership. I do not know if the possibility is available or not. Given the
“peripherality” of our packages, I would advocate to host them with the most
open permissions. If you are intersted, I can enquire the Alioth admins about
this.
2) I do not know how is the flexibility of email commit alerts for git
packages. If all repositories of the same Alioth project send diffs to the same
mailing list, then there is some interest to keep things separate. Otherwise,
where the repositories are does not matter so much, and it is tempting to use
an already existing place rather than managing a new one.
For the workflow, I would like to propose one more Blend-centered rather than
repository-centered. I have played a little with “mr”, a tool for managing
multiple repositories, and it seems that we could do something interesting with
it. How about generating one “mr” configuration file per metapackage, that
would allow to checkout all the source packages its task file lists? The ones
managed by Debian Med would be checked out with authentification (write
permissions), while the others would be checked out read only, unless they are
from a notoriously open team, in particular the Debian Perl team. The packages not
yet released but listed in the task file would be checked out as well, since there
is already the plan to put their VCS information in the tasks files.
Here is a small example:
# For this to work, one needs to configure a default login name for svn.debian.org in .ssh/config.
#
# Us
[debian-med/biofox]
checkout = svn checkout svn+ssh://svn.debian.org/svn/svn/debian-med/trunk/packages/biofox/trunk/ biofox
[debian-med/bioperl]
checkout = svn checkout svn+ssh://svn.debian.org/svn/svn/debian-med/trunk/packages/bioperl/trunk/ bioperl
# writable for all DDs, low-NMU
[pkg-perl/libalgorithm-munkres-perl]
checkout = svn checkout svn+ssh://svn.debian.org/svn/pkg-perl/trunk/libalgorithm-munkres-perl/ libalgorithm-munkres-perl
[pkg-perl/libarray-compare-perl]
checkout = svn checkout svn+ssh://svn.debian.org/svn/pkg-perl/trunk/libarray-compare-perl/ libarray-compare-perl
# Other repositories, checked out read-only
[others/pondus]
checkout = svn checkout svn://svn.debian.org/python-apps/packages/pondus/trunk/ pondus
Andreas, do you think it would be easy to generate such a file for each task?
For the bandwidth issue, as discussed earlier, unless we refactor our
Subversion repository to let people check trunks only without the tags,
checking out all the sources in Git may not be significantly heavier. Also,
the proposed workflow centered on Blend tasks gives some granularity that is
not available with the Subversion solution.
Using mr, we keep the possibility of doing broad commits if we want. However, I
am not sure it it is possible to easily revert them other than going in each
repository one by one. This would be one of the net losses of the change of
workflow. The net gain – but this is subjective – would be the change of
philosophy, where we feel responsability for all the packages we recommend in
our Blend, not only the ones we package by ourselves.
Have a nice sunday,
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
Reply to: