Re: build-from-branch into the primary archive
On Mon, 7 Mar 2011 13:56:19 -0800, Steve Langasek steve.langa...@ubuntu.com wrote: Maybe 'bzr debrelease', to avoid polluting the namespace too much? This should be implemented on top of 'dch' and support the -D option to specify an upload target; we definitely shouldn't have bzr-builddeb encoding its own notion of the default upload target, it's bad enough to have *one* package that doesn't get updated for this as part of the release. :) Too late, sorry :-) I wonder if it would be possible to use dch for all the places this information is currently needed. Thanks, James -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
[sorry for the late reply] On Tue, Feb 22, 2011 at 11:01:10AM -0500, Barry Warsaw wrote: On Feb 21, 2011, at 11:14 AM, Steve Langasek wrote: For that matter, if DEBCHANGE_RELEASE_HEURISTIC=changelog were the default, there would be an explicit mark this ready for upload step that typically consists of 'dch -r debcommit -r', which creates exactly the same tag as 'bzr mark-uploaded'. FWIW, 'dch -r debcommit -r' is a bit of black magic that doesn't seem well-covered in the documentation. Or, perhaps more accurately, it wasn't stressed enough to make it onto my radar before this thread. Maybe it would be more discoverable as 'bzr release' instead of 'bzr mark-upload' or 'dch -r debcommit -r'? Maybe 'bzr debrelease', to avoid polluting the namespace too much? This should be implemented on top of 'dch' and support the -D option to specify an upload target; we definitely shouldn't have bzr-builddeb encoding its own notion of the default upload target, it's bad enough to have *one* package that doesn't get updated for this as part of the release. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Martin Pitt martin.p...@ubuntu.com writes: Colin Watson [2011-02-24 0:11 +]: 'debcommit -r' is already a superset of 'bzr mark-uploaded'. The latter just sets a tag corresponding to the head version in debian/changelog. I know; I meant that if bzr mark-uploaded gets changed to do more magic than just tagging, e. g. poke Launchpad to please build this, then debcommit -r should call mark-uploaded so that this happens. Whatever we chose to tell launchpad to build *this* I think *this* should be identified by a revision ID. Tags provide a way to refer to revision IDs, but with a drawback: you can delete a tag or associates it with a different revid later. Using the revid also means we can unambiguously tell, after the fact, this build comes from this revid (a UUID by definition) which also allows things like: - this build has already been done, - this build has failed, - this build can be copied from this ppa to the archive, - etc. I also think that whoever decides that a build is needed knows this at *commit* time. I don't understand the packaging process well enough to say: this should be done this way at this point but I thought I should mention the problem about using a tag to carry this information anyway. Now, when I say revid, I'm talking about an implementation detail, there are various ways to associate the revid with anything that is more user friendly. As long as it's a property of the source packaging branch, it can be used to find the revid. So a specific revision property can work (a boolean saying: build this), a field in any file in debian dir will work too. Whatever works, as long as it can't be changed for a given revision. Vincent -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Thu, 2011-02-24 at 09:20 +0100, Martin Pitt wrote: Steve Langasek [2011-02-19 11:48 -0800]: That sounds reasonable to me. How do you gpg sign a tag in bzr? I've never seen any information about this in the UDD documentation. Neither have I, I'm eager to learn whether and how that works as well. But I think it's a prerequisite to maintain the current GPG strength security. bzr sign-my-commits (unsurprisingly!) adds a GPG signature to all the commits you've made in the branch, and there's an option exposed in the bzr configuration capplet in bzr-gtk to always sign your commits. I'm not aware of any way of signing a tag, although simply requiring all top-level commits to the Ubuntu branch be GPG-signed would probably be sufficient. Chris signature.asc Description: This is a digitally signed message part -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Colin Watson [2011-02-24 0:11 +]: 'debcommit -r' is already a superset of 'bzr mark-uploaded'. The latter just sets a tag corresponding to the head version in debian/changelog. I know; I meant that if bzr mark-uploaded gets changed to do more magic than just tagging, e. g. poke Launchpad to please build this, then debcommit -r should call mark-uploaded so that this happens. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Steve Langasek [2011-02-19 11:48 -0800]: That sounds reasonable to me. How do you gpg sign a tag in bzr? I've never seen any information about this in the UDD documentation. Neither have I, I'm eager to learn whether and how that works as well. But I think it's a prerequisite to maintain the current GPG strength security. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On 24/02/11 00:09, Colin Watson wrote: On Thu, Feb 17, 2011 at 03:03:08PM -0500, Barry Warsaw wrote: On Feb 17, 2011, at 10:33 AM, Steve Langasek wrote: How do we distinguish commits that ought to be built from those that don't? One way is to say we'll rebuild on things that add a new debian changelog (with a higher version.) Some people commit changes with a series target of 'unreleased' and we could then just actually assemble the package when that flips to be a real series. Either there needs to be a separate adjunct branch that gets pushed to *from* lp:ubuntu/$package to trigger builds, or this needs to only build when a new version (previously unknown to the archive) has been tagged on the branch. A lot of time has been spent on socializing the idea that we can use the existing lp:ubuntu branches to stage changes, and upload to the archive for building only when we're ready; to have some branches diverge from this behavior and start building for the archive for each commit, even if someone has nominated the branch in question for some sort of whitelist, would result in a number of wrongly published packages. I think the 'bzr mark-uploaded' interface, which sets the appropriate version tag, is the natural fit for this. Observing my recent use, I think there are two things that together indicate that a particular source branch revision is ready to be uploaded. First, the changelog entry's series is correct (i.e. natty, -proposed, etc.), *and* the version number does not have a ~ in it. I'm with others on this who find tagging a more explicit and safer interface. ~ in changelogs isn't going to be a sufficient heuristic: $ grep-aptavail -FVersion \~ -nsPackage | wc -l 1386 Even if you exclude cases where ~ is part of the upstream version (a common way to indicate a pre-release): $ grep-aptavail -rFVersion '.*-.*\~' -nsPackage | wc -l 39 ~ was introduced so that it could be used in real versions in the archive - it wasn't meant as just an unreleased marker. Cheers, Yes, I've been following this convention where: $UPSTREAM-VERSION~bzr$(bzr revno)-0ubuntu1 == Upstream snapshot, before version is released. $UPSTREAM-VERSION-0ubuntu1 == Upstream released version. $UPSTREAM-VERSION+bzr$(bzr revno)-0ubuntu1 == Upstream released version, plus some some commits - but not yet near new upstream version. For projects that maintain a 'fixes' branch for a released version: 's/+bzr/+fixes/' On another note, might it be a good idea to add build-from-branch support initially as PPA functionality? This enables people to trial it on /any/ package, identify goofs, make mistakes, try and break it, then give reasoned feedback without any concern of destabilizing the real archive. Perhaps create a project called build-from-branch and use a convention of lp:build-from-branch/$LPID, where I could then propose a merge from lp:~davewalker/build-from-branch/$SOMETHING (or push directly), and every user which requests to trial it gets a PPA called their LPID under ~build-from-branch-testers or similar. It would be /nice/ if every bzr push to LP required the topmost commit to GPG signed or at least present who pushed a commit to a branch based on SSH key. I find it somewhat odd that i can: bzr branch lp:~someoneelse/+junk/their-scratching-area bzr push lp:somewhere-serious ... and the result appears that ~someonelese pushed their rough code somewhere serious, which to the best of my knowledge cannot be linked to myself without someone grepping logs. I feel the UI should at least present that it was me that pushed their commit somewhere. This concern becomes more important when pushing bzr to archive becomes involved. Kind Regards, Dave Walker -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Wed, Feb 23, 2011 at 8:03 PM, Martin Pitt martin.p...@ubuntu.com wrote: Barry Warsaw [2011-02-22 17:22 -0500]: That's definitely a problem. :) Because of the team nature of Ubuntu development, I think in general uploaders should have push rights to the UDD branches. They do already. computer-janitor uses a custom branch, though, which is owned by ~computer-janitor-hackers. I. e. people who can upload the package can't commit to the branch. You could bless that branch as the UDD branch, then package upload rights will let people push to the branch. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 23, 2011, at 01:24 AM, Micah Gersten wrote: Couldn't bzr import-dsc have helped here? Probably so. In this specific case, I was making other changes so it was just as easy to merge the branch and continue working. But I probably should have been more diligent and merged the dsc for the uploaded version first. Cheers, -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On 02/23/2011 04:31 PM, Barry Warsaw wrote: On Feb 23, 2011, at 01:24 AM, Micah Gersten wrote: Couldn't bzr import-dsc have helped here? Probably so. In this specific case, I was making other changes so it was just as easy to merge the branch and continue working. But I probably should have been more diligent and merged the dsc for the uploaded version first. Cheers, -Barry You could have branched at the original revision, merge the dsc, then rebase your new changes on top of the dsc version :) Micah -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Mon, Feb 21, 2011 at 09:47:15PM -0800, Steve Langasek wrote: On Tue, Feb 22, 2011 at 03:57:16PM +1100, Martin Pool wrote: On 22 February 2011 13:59, Scott Kitterman ubu...@kitterman.com wrote: The alternative of adding a specialized field in debian/control for packages that should generally only be uploaded from branch so that anyone who tries to dput the package gets some kind of warning (as discussed elsewhere in the thread) would, I think, deal with this case adequately while preserving the option to upload via dput should it REALLY be necessary in some case. There seem to be two variables here: does a package upload just give a warning, or does it block; and secondly is this configured in the package metadata itself or in Launchpad. On the first point I think we absolutely want to have it start out with just a warning. To be more accurate, we will actually start out with no warnings at all, and probably only turn them on when people feel that particular teams are over the hump of wanting to use it all the time. Regarding where it is done, I see no problem with doing it in debian/control. If it's configured in the package itself we would have the option to give a warning at the time people run dput rather than later sending mail back from Soyuz complaining about it. If you're going to put it in debian/control, then I think a Vcs-Bzr: field pointing at a UDD branch already encodes this information - 'apt-get source' already warns about it, we might as well have dput warn on the same thing. Someone would have to make sure they point to the right place though. I'd say about 80% of the packages I've looked at they are plain wrong. -apw -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 19, 2011, at 08:21 PM, Loïc Minier wrote: (We usually don't but lp:ubuntu URLs in Vcs-Bzr because it's kind of implicit that we have this branch in every package, but there is not way to tell whether the UDD branch is in use or not; listing it explicitly when it's used solves this) One other quick note. With bzr 2.3, lp:ubuntu branches can also be referenced by ubuntu:series/package urls. series can be 'maverick' or 'm' and can be omitted for the latest series. E.g. to get Natty's version of python-numpy, just say: % bzr branch ubuntu:python-numpy Maverick's version via: % bzr branch ubuntu:m/python-numpy Cheers, -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 21, 2011, at 11:14 AM, Steve Langasek wrote: For that matter, if DEBCHANGE_RELEASE_HEURISTIC=changelog were the default, there would be an explicit mark this ready for upload step that typically consists of 'dch -r debcommit -r', which creates exactly the same tag as 'bzr mark-uploaded'. FWIW, 'dch -r debcommit -r' is a bit of black magic that doesn't seem well-covered in the documentation. Or, perhaps more accurately, it wasn't stressed enough to make it onto my radar before this thread. Maybe it would be more discoverable as 'bzr release' instead of 'bzr mark-upload' or 'dch -r debcommit -r'? -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tue, Feb 22, 2011 at 09:18:31AM +, Andy Whitcroft wrote: Regarding where it is done, I see no problem with doing it in debian/control. If it's configured in the package itself we would have the option to give a warning at the time people run dput rather than later sending mail back from Soyuz complaining about it. If you're going to put it in debian/control, then I think a Vcs-Bzr: field pointing at a UDD branch already encodes this information - 'apt-get source' already warns about it, we might as well have dput warn on the same thing. Someone would have to make sure they point to the right place though. I'd say about 80% of the packages I've looked at they are plain wrong. Wrong /and pointed at a UDD branch/? As I said, it's very unlikely that you'll have stale information here when the field points at a UDD branch. Stale data is usually because the field wasn't changed when merging from Debian. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tue, Feb 22, 2011 at 11:14:56AM -0500, Scott Kitterman wrote: One point I don't understand is why people insist they need to leave work in progress on the official branch? bzr is a DVCS, so why don't people make their own branch and then only push to the official branch when it is, in fact, ready for upload. Because it's not work in progress, it's changes that are per se correct and ready for upload that may not justify an upload yet (or may not be uploadable at the time due to freezes, etc). They're pushed to the official branch to indicate that they should be included in the next upload, whenever that is. If we did it that way, then pushing to the official branch could be limited to people who could upload the package, build from branch could be triggered by the push, and there'd be no problem with dput uploads overwriting work in progress. So where, in this plan, do you intend to stage merges of work when several people are working on the package in parallel? Where should I push upload-ready but insufficient changes, to ensure they're picked up by whoever does the next upload? I'm not opposed to the idea of having merge branches and deployment branches - in fact I suggested something like this earlier in the thread, only with the existing UDD branches as the merge branches rather than the deployment branches - but this model definitely requires that we have both and that they're well-documented and we're (largely) consistent in their use. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tuesday, February 22, 2011 11:51:02 am Steve Langasek wrote: On Tue, Feb 22, 2011 at 11:14:56AM -0500, Scott Kitterman wrote: One point I don't understand is why people insist they need to leave work in progress on the official branch? bzr is a DVCS, so why don't people make their own branch and then only push to the official branch when it is, in fact, ready for upload. Because it's not work in progress, it's changes that are per se correct and ready for upload that may not justify an upload yet (or may not be uploadable at the time due to freezes, etc). They're pushed to the official branch to indicate that they should be included in the next upload, whenever that is. OK. That makes sense. If we did it that way, then pushing to the official branch could be limited to people who could upload the package, build from branch could be triggered by the push, and there'd be no problem with dput uploads overwriting work in progress. So where, in this plan, do you intend to stage merges of work when several people are working on the package in parallel? Where should I push upload-ready but insufficient changes, to ensure they're picked up by whoever does the next upload? I'm not sure what the best place would be. I'm not opposed to the idea of having merge branches and deployment branches - in fact I suggested something like this earlier in the thread, only with the existing UDD branches as the merge branches rather than the deployment branches - but this model definitely requires that we have both and that they're well-documented and we're (largely) consistent in their use. I think separating merge branches and deployment branches has the potential to avoid a number of problems, particularly the problem of dput uploads over- writing work in progress. It may, however, cause more problems than it solves since there would need to be a canonical location to stage merges that people would have to look at. My suspicion is that would still be better since people who are ignoring UDD won't cause problems and the odds of people who are actively participating in UDD following a new convention are better than the odds for people who aren't. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tue, 2011-02-22 at 10:41 -0500, Barry Warsaw wrote: On Feb 19, 2011, at 08:21 PM, Loïc Minier wrote: (We usually don't but lp:ubuntu URLs in Vcs-Bzr because it's kind of implicit that we have this branch in every package, but there is not way to tell whether the UDD branch is in use or not; listing it explicitly when it's used solves this) One other quick note. With bzr 2.3, lp:ubuntu branches can also be referenced by ubuntu:series/package urls. series can be 'maverick' or 'm' and can be omitted for the latest series. E.g. to get Natty's version of python-numpy, just say: % bzr branch ubuntu:python-numpy Maverick's version via: % bzr branch ubuntu:m/python-numpy Cool! I didn't know about that. Forgive me for not digging through the docs, but I am curious about one thing. At the moment, if a Vcs-Bzr tag does exist and one is using UDD, is one ever told about this? My workflow right now is: First I check to make sure the package is in sync in UDD (anybody have a good one liner for this? I just look at the package overview right now which is not very efficient) mkdir ~/pkg/$package cd ~/pkg/$package bzr init-repo bzr cd bzr bzr branch lp:ubuntu/series/$package series cd series -- make changes -- bzr bd -S dput ppa:whatever file.dsc sbuild -A -d series-arch file.dsc If all of that works I debcommit, push, and propose merging.. but I'm wondering at what point I might have been reminded of the Vcs-Bzr tag so I can go look there. I'm always reminded of it by 'apt-get source'. I know I've missed the existence of a branch before by not noting this very fact. Ideally bzr branch ubuntu:something would do the check and remind me at that point if the branch is different. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 22, 2011, at 11:14 AM, Scott Kitterman wrote: One point I don't understand is why people insist they need to leave work in progress on the official branch? bzr is a DVCS, so why don't people make their own branch and then only push to the official branch when it is, in fact, ready for upload. If we did it that way, then pushing to the official branch could be limited to people who could upload the package, build from branch could be triggered by the push, and there'd be no problem with dput uploads overwriting work in progress. I work that way, but independent dputs are still a problem. In a recent computer-janitor case, the changelog entry for the dput didn't show up in the source branch. So I see 2.1.0-0ubuntu1 but no 2.1.0-0ubuntu2. I had to merge the actual change manually into the trunk branch, then bump the version to 2.1.0-0ubuntu3 with a note about why -0ubuntu2 is skipped. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 22, 2011, at 09:23 AM, Clint Byrum wrote: Cool! I didn't know about that. There's also debian-lp: prefix for Debian series branches in Launchpad (for various reasons, we can't use just debian:). Note however, that the series must be spelled out for debian-lp: -- there are no abbreviations. At the moment, if a Vcs-Bzr tag does exist and one is using UDD, is one ever told about this? Not by Bazaar afaik. My workflow right now is: First I check to make sure the package is in sync in UDD (anybody have a good one liner for this? I just look at the package overview right now which is not very efficient) See step 0 in https://wiki.ubuntu.com/DistributedDevelopment/Documentation/GettingTheSource for best known practice. There's an open bug in udd on better warnings when the package branch is out of date due to import failures. mkdir ~/pkg/$package cd ~/pkg/$package bzr init-repo bzr cd bzr bzr branch lp:ubuntu/series/$package series cd series -- make changes -- bzr bd -S dput ppa:whatever file.dsc sbuild -A -d series-arch file.dsc I do things very similarly, though usually I'm sbuild'ing before I dput to my PPA. If all of that works I debcommit, push, and propose merging.. but I'm wondering at what point I might have been reminded of the Vcs-Bzr tag so I can go look there. I'm always reminded of it by 'apt-get source'. I know I've missed the existence of a branch before by not noting this very fact. Ideally bzr branch ubuntu:something would do the check and remind me at that point if the branch is different. Yep. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Martin Pool [2011-02-21 16:17 +1100]: It seems like 'mark-uploaded' is causing a certain amount of friction at the moment: cases where it's not run and the branch therefore gets out of sync with the upload, and also just that it's an additional step that weighs people down. Right now, debcommit -r already does what mark-uploaded does; is there a reason why debcommit -r couldn't also (or instead) call bzr mark-uploaded? That would keep the workflow without an additional step for people who already use the UNRELEASED/dch -r/debcommit -r schema, and just introduce one extra step for the others. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tue, Feb 22, 2011 at 09:57:35PM +0100, Martin Pitt wrote: Andy Whitcroft [2011-02-22 9:18 +]: Someone would have to make sure they point to the right place though. I'd say about 80% of the packages I've looked at they are plain wrong. Really? I found maybe two in the last half year, which I fixed at once when pushing/uploading. In the desktop team we certainly take a lot of care to keep Vcs-Bzr: correct. Do you have some examples where they are wrong? The usual case for this is a package that has a Vcs-* field for the Debian packaging, gets modified in Ubuntu directly in the archive without pushing a new VCS branch anywhere, and doesn't get the Vcs-* fields updated to indicate that they don't represent the Ubuntu package history. As a first approximation: $ zcat ~/ubuntu/dists/natty/*/source/Sources.gz \ | grep-dctrl -r -FVersion ubuntu -a \ \( \( -FVcs-Bzr . -a \! -FVcs-Bzr launchpad \) -o -FVcs-Git . \ -o -FVcs-Svn . -o -FVcs-Cvs . \) \ -sPackage,Version,Vcs-Bzr,Vcs-Git,Vcs-Svn,Vcs-Cvs | grep -c Package 1037 $ 1037 source packages in natty with an ubuntu version number and some kind of Vcs-* field set not pointing at launchpad. Almost all of these fields contain stale data for Ubuntu's purposes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tue, Feb 22, 2011, Barry Warsaw wrote: I work that way, but independent dputs are still a problem. In a recent computer-janitor case, the changelog entry for the dput didn't show up in the source branch. So I see 2.1.0-0ubuntu1 but no 2.1.0-0ubuntu2. I had to merge the actual change manually into the trunk branch, then bump the version to 2.1.0-0ubuntu3 with a note about why -0ubuntu2 is skipped. But this was actually a case of me not being able to commit to the Vcs branch! :-) What I usually do in these cases is copy the changelog to bzr myself, to reconcile -- Loïc Minier -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 22, 2011, at 10:29 PM, Loïc Minier wrote: But this was actually a case of me not being able to commit to the Vcs branch! :-) That's definitely a problem. :) Because of the team nature of Ubuntu development, I think in general uploaders should have push rights to the UDD branches. What I usually do in these cases is copy the changelog to bzr myself, to reconcile -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Barry Warsaw [2011-02-22 17:22 -0500]: That's definitely a problem. :) Because of the team nature of Ubuntu development, I think in general uploaders should have push rights to the UDD branches. They do already. computer-janitor uses a custom branch, though, which is owned by ~computer-janitor-hackers. I. e. people who can upload the package can't commit to the branch. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On 02/22/2011 02:20 PM, Barry Warsaw wrote: On Feb 22, 2011, at 11:14 AM, Scott Kitterman wrote: One point I don't understand is why people insist they need to leave work in progress on the official branch? bzr is a DVCS, so why don't people make their own branch and then only push to the official branch when it is, in fact, ready for upload. If we did it that way, then pushing to the official branch could be limited to people who could upload the package, build from branch could be triggered by the push, and there'd be no problem with dput uploads overwriting work in progress. I work that way, but independent dputs are still a problem. In a recent computer-janitor case, the changelog entry for the dput didn't show up in the source branch. So I see 2.1.0-0ubuntu1 but no 2.1.0-0ubuntu2. I had to merge the actual change manually into the trunk branch, then bump the version to 2.1.0-0ubuntu3 with a note about why -0ubuntu2 is skipped. -Barry Couldn't bzr import-dsc have helped here? Micah -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Mon, 21 Feb 2011 16:17:50 +1100, Martin Pool m...@canonical.com wrote: It seems like 'mark-uploaded' is causing a certain amount of friction at the moment: cases where it's not run and the branch therefore gets out of sync with the upload, and also just that it's an additional step that weighs people down. Right, because it does not have a visible effect now. If it were to trigger a build (and given a different name) then I don't think it would be seen as extra weight. From some discussions, it seems like a promising way to trigger building would be by the presence of a changelog entry that has an incremented version number and that has a real target series. (As mentioned in the LEP point you quote.) To me this has the advantage that the decision 'please publish this' is visible in the diff etc in what seems like an obvious place for the packaging workflow. It's also something that can be easily be tweaked by editing. It also seems attractively minimal in that something targeted at 'unreleased' or without a whole new changelog entry just cannot be built, so we can pun that with _should_ not be built. bzr mark-uploaded sets a bzr tag which is editable and transparent, but probably not quite so much so as file content. Are there are problems with doing this? The only concern I have is that this would be changing the security model of the archive to some extent. Instead of GPG signed instructions to publish, we would have somewhat implicit SSH-key signed, or cookie/oauth signed (in the case of a Land it! button on merge proposals.) I don't know whether that is a change we want to make. If it isn't then we either need to use GPG with bzr in some arrangement, or have an out-of-band GPG signed instruction to build. Thanks, James -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Quickly and shortly due to out of time: I do not see a reason to deal with branches lp:ubuntu/$package if I need to upload source via dput, as well. It does not makes sense - duplicating a work. If Bazaar can create a source from my uploaded branch without dput, then it is fine. Summarizing, I am waiting for modern Bazaar. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Monday, February 21, 2011 09:36:50 pm Martin Pool wrote: On 18 February 2011 08:25, Andy Whitcroft a...@canonical.com wrote: Push to upload implies that it is practicle to move all packages into bzr. For large packages such as the kernel, libreoffice, X etc, where those are not in python that would imply we have to extract the intended state out of that and then commit it into another VCS just to trigger the upload? I would tend more to think of dput as the 'assembler' way of uploading, with pushing to a build branch being the 'best' way to do things. Generally you should not need to force a new way on people. If the new way is better people will switch and use it. Removing the old way should not be needed to achieve your goals should it? Right, we're not intending to force this on people. We want to offer it as an option for people that want to try it out. If there are reasons why people find it either doesn't work or isn't a good tradeoff for some packages, we'd like to work out why and then address that. Divergence between branches and uploads is a a problem that crops up in various places, including the documentation and keeping the package importer in sync. Ultimately we hope that developer groups will choose to say that particular packages must only be uploaded in branches to avoid people accidentally making things inconsistent, and we will give them a policy knob to express that. We don't have exclusive maintainers in Ubuntu, so I don't see how enforcing this on a per package basis is compatible with the Ubuntu maintainer philsophy. It also sounds very much like forcing it on people. The alternative of adding a specialized field in debian/control for packages that should generally only be uploaded from branch so that anyone who tries to dput the package gets some kind of warning (as discussed elsewhere in the thread) would, I think, deal with this case adequately while preserving the option to upload via dput should it REALLY be necessary in some case. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On 02/21/2011 11:57 PM, Martin Pool wrote: Regarding where it is done, I see no problem with doing it in debian/control. If it's configured in the package itself we would have the option to give a warning at the time people run dput rather than later sending mail back from Soyuz complaining about it. If it's in debian/control, then you can't drop the Ubuntu delta unless Debian adopts the Ubuntu-specific header. Putting it in LP would keep it persistent, but might make it harder to discover. -- Luke Faraone;; Debian Ubuntu Developer; Sugar Labs, Systems lfaraone on irc.[freenode,oftc].net -- http://luke.faraone.cc PGP fprint: 5189 2A7D 16D0 49BB 046B DC77 9732 5DD8 F9FD D506 signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Tuesday, February 22, 2011 12:47:15 am Steve Langasek wrote: On Tue, Feb 22, 2011 at 03:57:16PM +1100, Martin Pool wrote: On 22 February 2011 13:59, Scott Kitterman ubu...@kitterman.com wrote: The alternative of adding a specialized field in debian/control for packages that should generally only be uploaded from branch so that anyone who tries to dput the package gets some kind of warning (as discussed elsewhere in the thread) would, I think, deal with this case adequately while preserving the option to upload via dput should it REALLY be necessary in some case. There seem to be two variables here: does a package upload just give a warning, or does it block; and secondly is this configured in the package metadata itself or in Launchpad. On the first point I think we absolutely want to have it start out with just a warning. To be more accurate, we will actually start out with no warnings at all, and probably only turn them on when people feel that particular teams are over the hump of wanting to use it all the time. Regarding where it is done, I see no problem with doing it in debian/control. If it's configured in the package itself we would have the option to give a warning at the time people run dput rather than later sending mail back from Soyuz complaining about it. If you're going to put it in debian/control, then I think a Vcs-Bzr: field pointing at a UDD branch already encodes this information - 'apt-get source' already warns about it, we might as well have dput warn on the same thing. Apt-get source already warns on any vcs fields (including Debian ones), so I think if you're going to depend on those, then it won't be very effective. I think the idea of some kind of UDD specific 'are you sure' sort of option is reasonable. Failing to consult non-UDD branches doesn't have the same effect. It may result in things getting out of sync, but it doesn't result in history in the VCS getting over-written. Scott K P.S. I see those warning all the time and I confess I almost never look at the VCS. I don't recall it having been a poblem and I don't expect I'll change. I suspect I'm not alone in this. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Martin Pool [2011-02-17 18:02 +1100]: https://dev.launchpad.net/LEP/BuildFromBranchIntoPrimary How do we distinguish commits that ought to be built from those that don't? A very common workflow for packages is to commit the actual changes to the package while keeping the upload target as UNRELEASED. Once you want to upload it, you do dch -r to flip the upload target to natty (or maverick-proposed, etc.), and commit that change with debcommit -r, which will also tag the revision with the package version number. In order to fulfill the at least as secure requirement, we'd need to additionally GPG-sign that release commit. So IMHO a package should be built on each commit which has a tag and a GPG signature. Thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Saturday, February 19, 2011 08:47:04 am Martin Pitt wrote: Scott Kitterman [2011-02-17 6:51 -0500]: 1. From the LEP: Disabling dput uploads is not a nice to have. While we shouldn't disable it in general, ever (see my other reply), I'd highly welcome disabling dput on a per-package basis. I waste a lot of time cleaning up behind people who just upload one of my packages without committing their changes to bzr. Except, as you know, they aren't yours. I don't think we want to change the Ubuntu philosophy on package maintainers. Perhaps it would be possible to streamline the fixup process with additional automation so it wouldn't be a problem for you? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Sun, Feb 20, 2011 at 8:21 AM, Loïc Minier loic.min...@ubuntu.com wrote: On Sat, Feb 19, 2011, Scott Kitterman wrote: Perhaps a reasonable middle ground would be some new X-USE-UDD field (pick a better name please) in debian/control and a changet to dput that would either ask an are you sure y/N question or require -f to upload. That way it could be set without needed any changes on the launchpad end. Actually I liked Steve Langasek's approach of putting the UDD branch in Vcs-Bzr when the UDD branch is used to stage UNRELEASED changes (We usually don't but lp:ubuntu URLs in Vcs-Bzr because it's kind of implicit that we have this branch in every package, but there is not way to tell whether the UDD branch is in use or not; listing it explicitly when it's used solves this) Perhaps making the resolution behaviour when someone uses dput better would be sufficient to avoid this sort of extra configuration? -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
Hi Martin, On Thu, Feb 17, 2011 at 06:02:38PM +1100, Martin Pool wrote: I'd like to do a new feature in Launchpad to help Ubuntu, which is to allow packages to be built directly from source package branches. This would address one of the messy parts of source package branches at the moment, which is the need to upload the package, mark it uploaded, and also push the branch. This will build on things that seems to be quite popular and successful with ppa building from recipes, and help us simplify some redundantc Most of what we need to do this already exists, so I'm hoping that we'll be able to get it up quite quickly. I would like to start on this soon by just offering it as an adjunct to regular dput uploads, for a limited set of packages. For packages in that set, when someone commits to the branch, a part of Soyuz will automatically assemble a source package and queue it for building. This will let people try it out while still having the option to keep using regular dput uploads. We have a Launchpad Enhancement Proposal (LEP) about this at https://dev.launchpad.net/LEP/BuildFromBranchIntoPrimary. I'd appreciate hearing of * any problems you can spot in this * any missing constraints or likely snags we ought to consider * anyone or any packages who'd like to be first to try it I see discussion in the LEP of how to determine when to build from the branch: How do we distinguish commits that ought to be built from those that don't? One way is to say we'll rebuild on things that add a new debian changelog (with a higher version.) Some people commit changes with a series target of 'unreleased' and we could then just actually assemble the package when that flips to be a real series. Either there needs to be a separate adjunct branch that gets pushed to *from* lp:ubuntu/$package to trigger builds, or this needs to only build when a new version (previously unknown to the archive) has been tagged on the branch. A lot of time has been spent on socializing the idea that we can use the existing lp:ubuntu branches to stage changes, and upload to the archive for building only when we're ready; to have some branches diverge from this behavior and start building for the archive for each commit, even if someone has nominated the branch in question for some sort of whitelist, would result in a number of wrongly published packages. I think the 'bzr mark-uploaded' interface, which sets the appropriate version tag, is the natural fit for this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
I think this could be a great feature. It might also allow us to have a more fine-grained control over who can upload/push new packages, although I agree with others that we have to think carefully about how those permissions are expressed. On Feb 17, 2011, at 10:33 AM, Steve Langasek wrote: How do we distinguish commits that ought to be built from those that don't? One way is to say we'll rebuild on things that add a new debian changelog (with a higher version.) Some people commit changes with a series target of 'unreleased' and we could then just actually assemble the package when that flips to be a real series. Either there needs to be a separate adjunct branch that gets pushed to *from* lp:ubuntu/$package to trigger builds, or this needs to only build when a new version (previously unknown to the archive) has been tagged on the branch. A lot of time has been spent on socializing the idea that we can use the existing lp:ubuntu branches to stage changes, and upload to the archive for building only when we're ready; to have some branches diverge from this behavior and start building for the archive for each commit, even if someone has nominated the branch in question for some sort of whitelist, would result in a number of wrongly published packages. I think the 'bzr mark-uploaded' interface, which sets the appropriate version tag, is the natural fit for this. Observing my recent use, I think there are two things that together indicate that a particular source branch revision is ready to be uploaded. First, the changelog entry's series is correct (i.e. natty, -proposed, etc.), *and* the version number does not have a ~ in it. For example, I'm right now working on some computer-janitor fixes. It's trunk actually *is* the source branch. When I merged in pitti's and lool's merge proposals, I change the version number to `whatever~ppa0` first for local testing, then for dput upload to my PPA. Once I'm done with testing, I remove the ~ppa suffix, do a final commit and push, then `bzr bd -S` and dput the results to the real archive. So I think 1) a valid series; and 2) a non-~ version number are enough to indicate (for me) that the tip is ready to be built and uploaded. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 17, 2011, at 06:51 AM, Scott Kitterman wrote: 1. From the LEP: Disabling dput uploads is not a nice to have. It's a misfeature that violates (AIUI) one of the core assumptions given to Ubuntu developers when this project was started: That we are free to ignore it. I find it very troubling that it's listed as a goal of any kind (the discussion about being able to enforce the use of merge proposals convinces me this is not accidental). Are you saying that you want to preserve dput as an upload option forever? Do you see a future where dput *isn't* the interface for uploading a new package? Let's assume that all the current blockers are fixed, e.g. source packages are fast to download, etc. I think at some point there should be only one way to do it. 2. From my recollection of recent mail list discussions: I recall an issue where an existing branch can be made official, but the owner of the branch could retain access to the branch even if they didn't have upload rights for the package. This must be fixed before build from branch is enabled in the main archive. Agreed. I wonder how this push-to-official-branch can work with package sets, and whether making upload-rights equivalent to push-rights helps provide a finer grained control over who can upload what packages. That's assuming you think better control over upload rights is a good thing. Being in a (hopefully short-term) limbo, I do. :) 3. From my earlier experiments with UDD: I recall issues with the md5sum of the generated tarball matching upstream in preference to matching Debian. Debian is (mostly) our immediate upstream and needs to be the preferred source (it may be reasonable to provide an option to pull from upstream in cases it's preferred). That's for cases where Debian uses a different tarball, for example, because upstream's has non-free elements to it. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 17, 2011, at 02:16 PM, Bilal Akhtar wrote: Some (only *some*) packages need extra build deps just to run bzr builddeb -S . Since that command will be run on buildds having all build-deps installed (please correct me if I am wrong), building and uploading a package would eat up more resources, since the buildds would need to be called twice: once for packaging the source from the branch and once per arch for building it . This is true. debian/control cannot express the difference between dependencies needed to build the source package and those needed to build the binary packages. The real fix I think would be in the format of debian/control to handle these (admittedly few, but always annoying) cases. In the meantime, build-from-branch needs a workaround for that case. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Feb 17, 2011, at 06:09 PM, Robert Ancell wrote: Awesome feature. I'm happy to volunteer gcalctool to use this. I'd volunteer computer-janitor too. It might be a little weird though in that it's source branch *is* its trunk. -Barry signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On Thursday, February 17, 2011 03:08:15 pm Barry Warsaw wrote: On Feb 17, 2011, at 06:51 AM, Scott Kitterman wrote: 1. From the LEP: Disabling dput uploads is not a nice to have. It's a misfeature that violates (AIUI) one of the core assumptions given to Ubuntu developers when this project was started: That we are free to ignore it. I find it very troubling that it's listed as a goal of any kind (the discussion about being able to enforce the use of merge proposals convinces me this is not accidental). Are you saying that you want to preserve dput as an upload option forever? Do you see a future where dput *isn't* the interface for uploading a new package? Let's assume that all the current blockers are fixed, e.g. source packages are fast to download, etc. I think at some point there should be only one way to do it. Perhaps at some point, but that's not in the foreseable future. I know many people view it differently, but I still find the UDD experience substantially inferior to the way I've always done things. The main benefit that is realizable from UDD for me, we already have (the history to see when a change was introduced). We do have it as a project value to make it easy for Debian developers who are interested in their packages in Ubuntu to be able to work on them in Ubuntu. If the ability to do traditional uploads were to be removed, that would raise a toolset barrier to entry for this class of developer that I think we should consider carefully before taking on. 2. From my recollection of recent mail list discussions: I recall an issue where an existing branch can be made official, but the owner of the branch could retain access to the branch even if they didn't have upload rights for the package. This must be fixed before build from branch is enabled in the main archive. Agreed. I wonder how this push-to-official-branch can work with package sets, and whether making upload-rights equivalent to push-rights helps provide a finer grained control over who can upload what packages. That's assuming you think better control over upload rights is a good thing. Being in a (hopefully short-term) limbo, I do. :) My main concern is to ensure build-from-branch doesn't give someone the right to put a package in the archive that doesn't already have it. 3. From my earlier experiments with UDD: I recall issues with the md5sum of the generated tarball matching upstream in preference to matching Debian. Debian is (mostly) our immediate upstream and needs to be the preferred source (it may be reasonable to provide an option to pull from upstream in cases it's preferred). That's for cases where Debian uses a different tarball, for example, because upstream's has non-free elements to it. There are a variety of reason why this would be the case, but except for the handful of packages where Ubuntu is effectively upstream of Debian, I see no reason not to prefer Debian as a tarball source over upstream and many, many cases where this is a good thing. It's not always predictable which packages will have a different md5sum, so I don't think this is something that can be papered over for later on the basis that it doesn't affect certain packages. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: build-from-branch into the primary archive
On 02/17/2011 12:08 PM, Barry Warsaw wrote: On Feb 17, 2011, at 06:51 AM, Scott Kitterman wrote: 1. From the LEP: Disabling dput uploads is not a nice to have. It's a misfeature that violates (AIUI) one of the core assumptions given to Ubuntu developers when this project was started: That we are free to ignore it. I find it very troubling that it's listed as a goal of any kind (the discussion about being able to enforce the use of merge proposals convinces me this is not accidental). This particular proposal is only about adding a new route, not about replacing anything. The folks working on UDD certainly hope that their work will be a compelling alternative to traditional packaging techniques, so much so that people will want to switch. But, there's still a fair bit of work needed on the bits and pieces that make up UDD before it is a compelling alternative. Right now, it's an advantage to add UDD as an option, but would be a huge disadvantage to disable any existing tools. Down the road a bit, we may see more people using UDD, and if not the UDD developers will want to figure out why not: Are the tools inadequate? Are new contributors using UDD more and existing contributors sticking to traditional techniques because the process of changing tools would slow them down more than any advantage they might gain from the new tools? What additional features or changes in features might swing the balance so UDD is a net positive even with the cost of change? Even further down the road, there are some reasons why the community of developers (and the Tech Board) may want to consider some form of revision control across the entire archive: it provides a little more of a safety net, easier rollbacks of extensive changes with unintended side effects, and easier ways of building test branches of the entire archive to preview risky changes. It's not time for those conversations yet. The UDD folks are focused on the compelling alternative story, and that's where they should be focused (scope-creep is a killer of good ideas). But plant the possibilities in the back of your mind as something to talk about at some point. Are you saying that you want to preserve dput as an upload option forever? Do you see a future where dput *isn't* the interface for uploading a new package? Let's assume that all the current blockers are fixed, e.g. source packages are fast to download, etc. I think at some point there should be only one way to do it. It's important to separate interface from implementation here. If the community decides to move toward revision control on the whole archive, dput could easily be kept as an interface, just changing the implementation (and maybe adding a few new flags or config options) so it works with the archive's revision control system. Allison -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
