Distributed development toolset (Re: ArchiveReorganisation and sponsoring)

[Emmet Hikory]

Matt Zimmerman wrote:
> 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.
<...>
> 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.

    That's precisely the opposite of what I'm saying.  The part of my
message elided above said specifically that in the presence of global
revision control, there would no longer be a perception of overhead,
and that the argument that it is extra work would go away.  My
argument is against the assertion of global revision control on an
ad-hoc basis before the infrastructure is available to support it.  It
improves some workflows, but does not currently improve all workflows.
 There are some things that I do that would take significantly longer
without easy access to working VCS repositories.  There are other
things I do that would take significantly longer if I were to push
fresh packaging branches for each package touched.

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

    Indeed: for those that find benefit in working with revision
control systems, I suggest they should use them, especially if they
are expecting many changes to a package, as pointed out earlier in the
thread by Steve.  I just think it's premature to have a discussion
about whether everyone should be using version control for things at
this point, because of the state of the tools.  Once tools are in
place as described in the proposed model, those choosing not to use
revision control systems will have their work automatically imported
for the benefit of those who do, and those who do use version control
systems will likely have their work be made available in the format
expected by those who choose not to use such systems.  WIth these
tools in place, there is no point to argument over which is the
correct model.  Without these tools in place, we are having a
discussion about possible benefits and detriments of a system that
does not exist, and of which we may all have slightly different
understandings, which seems equally without value.

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

    Absolutely, and unquestionably.

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

    Again, I don't oppose the work to build tools, nor do I oppose the
work to import as much information as possible about the state of
packages into a version control system, and not even do I oppose the
introduction of tools that let such a version control system be used
to push changes directly into the archive without a sourceful upload.

    My opposition is precisely against 1) arguing (on either side)
about a set of tools that is not yet either fully designed or
available for appropriate review, 2) the assertion that everyone
should be using a version control system for all packaging work: at
the current levels of tool maturity, I believe it to provide benefit
for only a subset of activities, and 3) that there exists sufficient
homogeneity in the work performed by various groups of Ubuntu
Developers that it is safe to say that any given set of tools is now
or will be correct for all use cases.  I do not mean to say that you
personally are responsible for any of the assertions that I oppose,
but only intend to clarify my position.

    As previously stated many times by many people, the intended plan
is to provide facilities to let each developer choose a workflow that
works best for them.  As the tools mature, it is expected that they
will become useful to a wider number of developers.  I assert that
this ought be let happen, and that neither that the current state of
the tools is sufficient to improve some developers' workflow, nor that
the current state of the tools may impair other developers' workflow
should be considered for general discussion, except in terms of
identifying specific issues to the tool developers towards helping
them to improve the tools.  If at some point the tools meet everyone's
needs, this is perhaps a good thing, but it need not be a specific
goal, so long as they meet many people's needs and others may choose
not to use them.

-- 
Emmet HIKORY