Distributed development toolset (Re: ArchiveReorganisation and sponsoring)
Scott Kitterman
ubuntu at kitterman.com
Sun Aug 31 21:25:26 BST 2008
On Sun, 31 Aug 2008 21:08:30 +0100 Matt Zimmerman <mdz at ubuntu.com> wrote:
>(subject changed since this has very little to do with the previous thread)
>
>On Sun, Aug 31, 2008 at 03:46:30PM -0400, Scott Kitterman wrote:
>> On Sun, 31 Aug 2008 19:30:11 +0100 Matt Zimmerman <mdz at ubuntu.com> wrote:
>> >On Mon, Sep 01, 2008 at 01:41:53AM +0900, Emmet Hikory wrote:
>> >> There is also currently a bug about awkward workflows for
>> >> sponsoring in Launchpad (3), and it may be that as mentioned there,
>> >> the proposed solution is to encourage revision modifications using the
>> >> branch merge request review workflow, towards eventual implementation
>> >> of NoMoreSourcePackages (4). While this may well be suitable for
>> >> packages belonging to a specific maintenance team, who may have
>> >> branches for those source packages with which they work already
>> >> available, some outstanding bzr bugs (5) make this painful for
>> >> universe, where the sponsor may have never seen the package
>> >> previously, and may never intend to look at it again.
>> >
>> >This is where I think we should be headed. I realize there are some
issues
>> >with it at present, but as we start to use Bazaar more, we'll be in a
better
>> >position to put more effort into resolving them.
>>
>> Do keep in mind that there are developers that do not use Bazaar at all.
>> For me, as a community developer, the fun factor associated with learning
>> VCS +1 is very low. To the extent I'm pushed into learning a new, Ubuntu
>> unique toolset, it will probably translate fairly directly into less
>> contribution from me. This is particularly true since this move away
from
>> the Debian standard toolset does not appear to solve any problems I'm
>> actually having.
>
>This isn't a move away from the Debian toolset; it's building on it. I'm
>confident that, in time, building better tools will make it easier and more
>efficient to contribute, not less. There will be stumbling blocks along
the
>way, but they are just that. It's nothing a bit of patience and a sense of
>adventure can't cure.
Right, well Launchpad seems to have fully absorbed whatever energy I had
for adventures in tools.
>> >With update-manager, on a fast connection, a lightweight checkout takes
>> >about 10 seconds vs. apt-get source at about 4 seconds. That's not bad
>> >at all, and Bazaar hints that it might be even faster once the branch
>> >format is upgraded to the latest.
>>
>> Except for the small minority of packages that are routinely touched by a
>> lot of people, I don't see any advantage that would cause me to be
>> satisfied with waiting any additional amount of time.
>
>Revision control has been a best practice for software development for over
>20 years, and for good reason. The fact that Debian and Ubuntu don't use it
>in a consistent or standard fashion has always been an unfortunate wart in
>our development process, and fixing it is something to look forward to.
We have a very good revision control system with a capable and stable
toolset in our archive. Admitedly it's not very reversion friendly, but it
generally does the job.
IMO the question isn't version control or not, but is the benefit
associated with another layer of complexity and granularity worth it. I
believe that ouside of a core of packages that are routinely touched by
many people (I'd guess this is at most 2 ot 3 percent of the archive) the
benifit is at best undemonstrated.
Scott K
More information about the ubuntu-devel
mailing list