Re: Collision branches
I didn't want to leave this thread entirely dangling: I haven't looked into these collisions yet, but it is on our priority list for the future. m -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: ubuntu: branches lacking history with upstream branches
On Thursday, September 22, 2011 06:42:48 PM Jelmer Vernooij wrote: > > This would more closely mirror how > > > > packages are managed in Debian. However, I'd still want > > `bzr branch ubuntu:gtimelog` to give me the full source. I wonder if > > nested branches are the answer here. One trick would be that I'd only > > want the source from the upstream branch based on a particular > > tag. E.g. I might have unreleased changes in lp:gtimelog, but I want to > > base ubuntu:gtimelog (and the source package built from it) to work off > > the 0.7.0 tag or some such. > > The practice of versioning debian/ only mostly seems to happen if the > VCS used is SVN. Even then, there are a couple of teams that import the > full upstream source into SVN. > > I think I've seen more Git repositories that include the full source > than repositories that don't. For Kubuntu we use /debian only bzr repositories. No one seems interested in going to full source. Scott K -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: ubuntu: branches lacking history with upstream branches
Hi Barry, On 09/22/2011 05:14 PM, Barry Warsaw wrote: On Sep 22, 2011, at 07:08 PM, Martin Pool wrote: lp:indicator-power is one example, and the desktop team actually maintain an unofficial packaging branch that does share history: lp:~ubuntu-desktop/indicator-power/ubuntu At the moment, gtimelog is another. What I've done recently is to first do a release from trunk, i.e. lp:gtimelog, push the new tarball to Launchpad and PyPI, then in ubuntu:gtimelog, I do `bzr merge-upstream` and build the Ubuntu release from that. It's not perfect, but it works. One problem seemed to be a weird lag in the debian/watch url between what I was seeing in my browser, where the 0.7.0 release was visible, but uscan took a while before it saw the new tarball. I didn't quite understand that, but wasn't in a desperate hurry to push the new Ubuntu version anyway, so I just waited a bit. It would certainly be more useful to have ubuntu:gtimelog share history with lp:gtimelog, but I think it would be best in that case if ubuntu:gtimelog only version controlled the debian directory. Why would this be better than actually having all of the history there? It seems to me like that would mostly just add extra overhead because you have to fetch two branches rather than one. I use "bzr merge-upstream" to merge new upstream versions into the packaging branches of bzr, samba4, heimdal and various other projects . See for example the ubuntu:bzr branch (although that seems to be out of date at the moment). This would more closely mirror how packages are managed in Debian. However, I'd *still* want `bzr branch ubuntu:gtimelog` to give me the full source. I wonder if nested branches are the answer here. One trick would be that I'd only want the source from the upstream branch based on a particular tag. E.g. I might have unreleased changes in lp:gtimelog, but I want to base ubuntu:gtimelog (and the source package built from it) to work off the 0.7.0 tag or some such. The practice of versioning debian/ only mostly seems to happen if the VCS used is SVN. Even then, there are a couple of teams that import the full upstream source into SVN. I think I've seen more Git repositories that include the full source than repositories that don't. Cheers, Jelmer -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: ubuntu: branches lacking history with upstream branches
On Sep 22, 2011, at 07:08 PM, Martin Pool wrote: >lp:indicator-power is one example, and the desktop team actually >maintain an unofficial packaging branch that does share history: >lp:~ubuntu-desktop/indicator-power/ubuntu At the moment, gtimelog is another. What I've done recently is to first do a release from trunk, i.e. lp:gtimelog, push the new tarball to Launchpad and PyPI, then in ubuntu:gtimelog, I do `bzr merge-upstream` and build the Ubuntu release from that. It's not perfect, but it works. One problem seemed to be a weird lag in the debian/watch url between what I was seeing in my browser, where the 0.7.0 release was visible, but uscan took a while before it saw the new tarball. I didn't quite understand that, but wasn't in a desperate hurry to push the new Ubuntu version anyway, so I just waited a bit. It would certainly be more useful to have ubuntu:gtimelog share history with lp:gtimelog, but I think it would be best in that case if ubuntu:gtimelog only version controlled the debian directory. This would more closely mirror how packages are managed in Debian. However, I'd *still* want `bzr branch ubuntu:gtimelog` to give me the full source. I wonder if nested branches are the answer here. One trick would be that I'd only want the source from the upstream branch based on a particular tag. E.g. I might have unreleased changes in lp:gtimelog, but I want to base ubuntu:gtimelog (and the source package built from it) to work off the 0.7.0 tag or some such. -Barry -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Re: ubuntu: branches lacking history with upstream branches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/22/2011 11:08 AM, Martin Pool wrote: > pitti mentioned to me today the issue of ubuntu-namespace branches > that ought to be related to an upstream bzr branch, but that > actually aren't. > > lp:indicator-power is one example, and the desktop team actually > maintain an unofficial packaging branch that does share history: > lp:~ubuntu-desktop/indicator-power/ubuntu > > It seems clear it will save confusion to fix this up. Making the > branch correct for people actively working on it is probably the > most important thing. I agree, if someone is actively working on a packaging branch, then the package importer work should be based off of that. I personally don't know whether package-importer should be able to push to lp:~ubuntu-desktop/indicator-power/ubuntu, vs pushing to just lp:ubuntu/indicator-power, but sharing the history of the other one. Certainly PI isn't helping anyone if they aren't going to use what it gives. > > * I think in general we just rebind the branch alias to the branch > that should be official? I guess we need a losa to do that? * The > package importer might need to be told to reset those branches. * > Perhaps we should document when/how we do this. * Perhaps we can > get something closer to self service for people who do hit it, or > systematically prevent it in the importer? > > Martin > ATM, I think some sort of manual process is ok. If we find it happening a lot, then automating it would make sense. John =:-> -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk57AvEACgkQJdeBCYSNAAMgEACfVX2WWXLg+Eqw9igzo6pS61Ef MxsAoJgoX2jCCHBn1uZIFfaA+n6uYqEU =iW8b -END PGP SIGNATURE- -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
ubuntu: branches lacking history with upstream branches
pitti mentioned to me today the issue of ubuntu-namespace branches that ought to be related to an upstream bzr branch, but that actually aren't. lp:indicator-power is one example, and the desktop team actually maintain an unofficial packaging branch that does share history: lp:~ubuntu-desktop/indicator-power/ubuntu It seems clear it will save confusion to fix this up. Making the branch correct for people actively working on it is probably the most important thing. * I think in general we just rebind the branch alias to the branch that should be official? I guess we need a losa to do that? * The package importer might need to be told to reset those branches. * Perhaps we should document when/how we do this. * Perhaps we can get something closer to self service for people who do hit it, or systematically prevent it in the importer? Martin -- ubuntu-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
