Introduction to Ubuntu Distributed Development

[Adrian Perez]

Those were the layers I was talking about, many pitfalls. Honestly, I'd
just use bzr (and a good moment to say I've used it and use it
ocasionally), instead of such a layer. 
Also I pointed you to an example, git.debian.org, and they have pointed
you to other more important: upstream. 
As I said I have no statistics to confirm, but how many upstream teams
are using bzr and how many are using git. How's bzr going to allow you
in the future to maintain both upstream sources and debian patches in
the way the git workflow will allow soon/is allowing already? No bzr has
submodules or sub-tree merges I'm aware of.
I'd really rather work than spending hours talking, so I'm going back to
a new upstream version, and expect this thread will make someone react.
If they do, please let me know about it, I'm in for any coding (and I
won't start another war about ubuntu being python-monopolized :) ). 
I personally agree that, but I'm not totally against, Canonical is
making some decisions for us, I'm just over-accustomed to debian, I'm
just saying that the community could have been part of that decision and
I suspect that wasn't (honestly, I wasn't around by then). 

I was personally trying to get azureus to be tracked in launchpad and
there were many many issues, only master branch, etc. There is room for
improvement in many places, so the today's implementation isn't perfect.

No more args, Ubuntu rocks anyways.

On Thu, 2009-12-17 at 12:47 -0600, Dustin Kirkland wrote:
> On Thu, Dec 17, 2009 at 10:40 AM, Scott James Remnant <scott at ubuntu.com> wrote:
> > On Thu, 2009-12-17 at 10:55 -0500, Adrian Perez wrote:
> >
> >> I think Git is better suited than Bzr for the job, and I don't make to
> >> make it personal.
> >>
> > If you think Git is better suited, please demonstrate it by building up
> > an equivalent infrastructure that has been built up around bzr, so fair
> > side-by-side comparisons can be performed.
> >
> >> It's true that there's an infrastructure set up, but I think the idea of
> >> voting is letting the community decide for itself, and don't impose us a
> >> tool which might not be the preferred choice for most of our developers.
> >>
> > Right now, that vote would be:
> >
> >  ( ) continue using the existing apt-get source infrastructure, and
> >     contribute by sending debdiffs around; merge from Debian by hand,
> >     etc.
> >
> >  ( ) use the new bzr infrastructure, contribute directly to revision
> >     control branches, merge using native merge support
> 
> There's also, as James mentioned, the git-bzr and hg-bzr projects.
> 
> If there are people that really, really want to issue git commands (it
> certainly sounds like there are), instead of bzr commands, I can
> understand that.  If you're in this camp, please consider contributing
> to the translation-layer projects, such that you can happily work in
> your git world with git commands, but when you're ready to push your
> work, push it through the translation layer, and let it land in the
> Launchpad/Bazaar backed repositories, which are currently
> well-integrated tools.
> 
> :-Dustin


-- 
Best Regards,

Adrian Perez <adrianperez-deb at ubuntu.com>
Ubuntu Developer

GPG Key ID: 8A9A3084
GPG Key Fingerprint: 99E8 E74E 7B4F 93AE F32A  5523 9973 0D5C 8A9A 3084
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20091217/f20bfeea/attachment-0001.pgp