Distributed development toolset (Re: ArchiveReorganisation and sponsoring)

Philip Wyett philwyett at gmx.com
Sun Aug 31 22:40:36 BST 2008


On Sun, 2008-08-31 at 21:08 +0100, Matt Zimmerman 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.
> 
> > >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.
> 
> -- 
>  - mdz
> 

Indeed, the deb package system and tools along with working out of
version control can easily coexist and personally I do prefer version
control at the top level. When a package has multiple changes and one
change is specified with version control revision in the changelog
comment it came from it makes it far easier and dare I say quicker to go
back and diff around the change and see what was going or pre and post
the change. Far easier than pulling files from here there and everywhere
then beginning the process of seeing where changes are and on LP when
you here the magic words 'does it work on the latest release' makes me
cringe. :-) From version control and knowing the revision/branch tag I
can pull and build a lot quicker to actually test if it does work with a
latest version rather than chasing round LP which has a massive learning
and click curve to find anything!

Maybe a trial set of maybe half a dozen packages that are in Ubuntu
version control presently could be used as a test bed to see how much of
an effect it does make over the development and package processes.

Regards

Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20080831/f8bffaf7/attachment.pgp 


More information about the ubuntu-devel mailing list