Re: FWD: [Bug#528733: O: svn-buildpackage -- helper programs to maintain Debian packages with Subversion]

[Andreas Tille <andreas@an3as.eu>]

On Sun, May 17, 2009 at 04:05:13PM +0900, Charles Plessy wrote:
> 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.

While I do not see (and never have seen) a problem in using a "foreign"
VCS to maintain Debian Med packages I just want to make clear that I did
not intended to actually use Debian Science Git repository but rather
to adopt the philosophy to provide SVN and Git as Debian Science is
doing.  Just to clarify this in case my previous mail was not well
formulated.

> I see only two potential drawbacks:

I see the same - that's why I did not tried to propose this.  IMHO
setting up an additional Git repository for Debian Med is not that
hard for several people here.

> For the workflow, I would like to propose one more Blend-centered rather than
> repository-centered.

Fully ACK.

> 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?

That's a good idea and I'd warmly welcome it if somebody would take
over the implementation.  I personally do not feel really fit for this
task.  Perhaps moving this point to Debian Blends list might make sense.
(Blends list in CC but Reply-To not yet set.)

> 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.

I'm perfectly fine with this approach.
 
> 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?

Well, I do not think that it is hard.  But I'm currently testing
new code (about 25% of the Blends webtools code rewritten) on my
harddisk.  I did not opened a branch in Blends SVN because I have
the feeling it is rather my own code and it does not yet work -
so there is not much to test for others.  Once this is finished
you get easy access to all available data in UDD and what was
a problem before - for instance obtaining VCS field would have
been required to read Sources.gz files in addition - becomes
very cheap.  So waiting for about two or three weeks and than
asking again would be a good idea - at least I hope to get it
implemented until then.
 
> 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.

Full ACK.
 
> 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.

I *defintely* feel responsibility for all packages regardles who
is mentioned in the Maintainer field - that's a basic idea. 
 
> Have a nice sunday,

Same to you (all)

      Andreas. 

-- 
http://fam-tille.de