Distributed development toolset (Re: ArchiveReorganisation and sponsoring)

[Matt Zimmerman]

On Thu, Sep 04, 2008 at 12:27:04PM +0900, Emmet Hikory wrote:
>     I believe this is precisely the point.  For packages that receive
> 0-1 uploads to Ubuntu per cycle, and for which the Debian version is
> essentially clean, but it needs some change (e.g. create /var/run/foo
> at runtime rather than at unpack time) that hasn't been accepted back
> to Debian, the overhead of a VCS as well as processing the merge and
> upload seems extra.
> [...]
> Until that time, there's a marked difference in the use
> cases for people looking after specific packages with significant
> activity, and people looking over arbitrary packages to see if
> something ought be touched and perhaps doing an update for a package
> they expect never to touch again.
> 
>     One example where the overhead can be particularly painful is NBS
> processing.  It's fairly trivial to rebuild-test and upload a number
> of packages to use a new (API-compatible) version of a library.  Some
> of us have uploaded over 100 packages in a single day for this
> purpose.  Creating packaging branches for each of these packages to
> store the additional changelog entry, when one expects an automated
> sync to render the branch obsolete at the start of the next cycle
> feels like wasted overhead, and may in fact complicate the task of
> someone wanting to work on the package a couple cycles later, as the
> last posted branch will be fairly out-of-date, and it may take a while
> to determine that all posted commits are meaningless in the context of
> the introduction of new Ubuntu variation.  With the completion of the
> mooted tools, this is less likely to be "useless overhead", and more
> likely to be a seamless part of updating a package (or if it's not,
> either the tools still aren't complete or I've misunderstood the many
> descriptions of that which will be).
> 
>     I'm not arguing against VCS for packaging: I've seen it work very
> well for collaboration for some projects, and ensure that the quality
> of that added to the archive is maintained.  I'm just not sure that
> the tools are currently in a state where a focus on driving all
> packaging to use some specific VCS, and for branches to be published
> is a useful conversation[...]

The reasoning I hear in your message, and some of the others in this thread,
is that global revision control isn't a good idea because for some cases the
overhead of using it is seen to outweigh the benefits.  I'm a bit surprised
by this argument, but it is a valid position to take.

However, this chain of reasoning overlooks the fact that, in the proposed
working model, no one is forced to use it, any more than they are today.
For many of us, the benefits of using revision control in a standardized way
for all of the packages we touch far outweighs the overhead, even if others
don't use it.

As such, I believe it will be a net positive for the project for us to
pursue revision control for every package, and allow those who want to use
it to do so.  A sufficient number of us believe this would improve their
productivity, and the rest of us can safely ignore the changes.

As the tools improve, I'm confident that an increasing proportion of us will
see good value in revision control for Ubuntu development, and that it can,
in time, become a best practice.  However, there's no need to have an
argument about whether or not that is actually the case.  It's entirely
irrelevant to the question of whether the tools should be allowed to exist,
which is the one which seems to be being asked here.

Please do give feedback to people like James Westby who are actively
developing the tools, but there should be no reason to oppose this work
simply because it might not be useful to some people.  If you see such a
reason, it's a potential problem with the specification and should be
explicitly identified as such.

-- 
 - mdz