Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On 13 November 2013 17:39, Andrew Starr-Bochicchio a.star...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:33 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: Though since we're talking about it, the one stop gap fix that would make me happy would be if all Ubuntu Developers could trigger the equivalent of the local 'requeue_package.py --full' command that UDD admins can run. Some history might get lost, but at least out of date branches could be made usable. This seems to have been the topic that has generated the most interest. It seems to be a bit of an overkill to have a vUDS session on it, especially if we don't have the right people in the room. So maybe we can try to hammer out the requirements here? Currently you need shell access to Jubany in order to run the command. [0] I know that this request has come up in the past, but my Google-fu is failing me now. Adding the (seemingly dormant) UDD list to the conversation in hopes of catching the right person. [0] https://bugs.launchpad.net/udd/+bug/713719 I requeue packages from time to time, upon request. But I don't keep a track of packages for which full requeue doesn't help. Nor have a good way to process such requests. Maybe a request wiki page? I'd subscribe to it, and would comment which one requeued and whether that fixes / not fixes the branch. Regards, Dmitrijs. -- 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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Wed, Nov 13, 2013 at 03:32:38PM -0500, Barry Warsaw wrote: On Nov 13, 2013, at 11:32 AM, Steve Langasek wrote: But I think it would be more interesting to get a permanent fix for this bug: https://bugs.launchpad.net/udd/+bug/714622 This accounts for the problem people have mentioned, that core packages are much more likely to have failed imports. The importer badly needs fixed to not throw up its hands when the revision ID of a tag has changed; it should only care about this when the branch contents are wrong. This single bug accounts for just under half of all importer failures, and is a failure scenario that the importer *could*, with sufficient smarts, resolve automatically. This may be controversial, but (except for trying to fix error conditions), I think we should disallow all developer pushes to UDD branches and only let the importer write to them. It's simply too error prone otherwise, and there's no good reason for it. I disagree 100%. To me, this is the only reason to *have* UDD branches. If we're never going to push to the branches, then the whole thing is a futile exercise. Being able to use bzr blame / bzr diff to traverse history at per-upload granularity is not sufficiently interesting to justify the effort of supporting UDD. As long as there are other VCS branches for core packages that are richer and more authoritative with finer-grained history, UDD branches will continue to be confusingly redundant. If we've resigned ourselves to the notion that they will never be a suitable replacement for maintainer branches, then we should kill UDD off entirely instead of continuing to invest time and hardware resources in giving developers a poor VCS experience that requires you to play a game of 20 questions to figure out the right place to get the package's source. One possible reason for developers to push to UDD branches is to share the code with other people, or to avoid the lag in importer runs. The reason for pushing to the UDD branches is so that changes to the package are grouped logically, and you can use the branch history as a useful forensic tool, or as a source for cherry-picking changes. Having UDD branches that exist but are *not* an authoritative source for this information is actively harmful. At the time UDD was conceived. this was considered an acceptable temporary downside on the path to a full branch-based workflow. Now that it's clear that having imports of full upstream history into UDD is not on the horizon, we should work out what to do to avoid continuing to provide UDD as a bad service. Of course the former can be easily handled by pushing to a personal branch. The latter? Oh well, I can live with that for error-free branches. ;) This error is not with the branches, but with the importer for imposing unnecessary constraints on the branches. In nearly all of the cases where that bug hits us, the branch *contents* are identical to what the importer would have generated, which means the importer should accept the ID change and move on. In cases where the contents don't match, the importer should win and move the branch aside - in fact, it's supposed to already do this. But if we no longer have anyone who can fix this importer problem, then we should admit defeat and scrap UDD altogether. A long time ago I decided never to push UDD branches and always let the importer update them. I've never regretted that or encountered problems with that discipline. That works ok for packages that are only touched once in a blue moon. But making this a policy means that UDD is no longer useful for core packages like upstart, and all our rich branch history is going to go somewhere else. This doesn't solve the problem that people are actually complaining about, namely that UDD branches are not useful for packages that are actively maintained - it merely codifies it, and exacerbates the related problem that UDD branches only sometimes provide a useful workflow for outside contributors. -- 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-distributed-devel mailing list ubuntu-distributed-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-distributed-devel
Patch pilot report [2013-11-13]
During my sponsoring shift I took some time to clean up obsolete items (such as MPs which were already uploaded, but not marked so, argh). Reduced the queue from 52 to 30. https://code.launchpad.net/~dannf/ubuntu/trusty/flash-kernel/lp1247601/+merge/193701: upload https://code.launchpad.net/~hjd/ubuntu/trusty/multipath-tools/bug1231182/+merge/192794: merge https://code.launchpad.net/~mitya57/ubuntu/trusty/sphinx/1.2b3+dfsg-2ubuntu1/+merge/192315: upload https://code.launchpad.net/~xnox/system-service/python3/+merge/192805: review, test, broken https://code.launchpad.net/~smartboyhw/ubuntu/trusty/ubuntustudio-default-settings/fix-bug-1242417/+merge/192209: upload https://code.launchpad.net/~droetker/ubuntu/saucy/bumblebee/fix-for-1250745/+merge/194996: reject https://code.launchpad.net/~jibel/ubuntu/trusty/python-jsonschema/lp1248727_enable_autopkgtest/+merge/194236: upload https://code.launchpad.net/~jamesodhunt/ubuntu/saucy/sysvinit/force-reload-configuration-for-broken-inotify/+merge/180690: discuss better solution with James 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: Handling of layout/input methods in Unity: what should we do for the LTS?
Hi Sebastien, On Tue, 12 Nov 2013 16:02:11 +0100 Sebastien Bacher sebastien.bac...@canonical.com wrote: - we stop using our new keyboard indicator/get back to an UI which is not what our design document recommend What does it mean? * Someone will write indicator patch for IBus 1.5. * We use IBus embedded icon on Unity. * We switch back to IBus 1.4. * We switch to Fcitx from IBus. * or another idea? Regards, -- AWASHIRO Ikuya ik...@fruitsbasket.info / ik...@oooug.jp / iku...@gmail.com GPG fingerprint: 1A19 AD66 C53F 2250 3537 1A9D 3A53 2C1D 20AB CC8A -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Handling of layout/input methods in Unity: what should we do for the LTS?
Hi, Le 13/11/2013 13:40, AWASHIRO Ikuya a écrit : What does it mean? * Someone will write indicator patch for IBus 1.5. Did we loose our indicator in the ibus 1.4-1.5 transition? We should add it back in that's the case, yes * We use IBus embedded icon on Unity. * We switch back to IBus 1.4. Those are not likely to happen no * We switch to Fcitx from IBus. That's a topic that is going to be discussed at vUDS next week: http://summit.ubuntu.com/uds-1311/meeting/21984/desktop-1311-default-imf-review/ Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Handling of layout/input methods in Unity: what should we do for the LTS?
Le 12/11/2013 17:55, Gunnar Hjalmarsson a écrit : Possibly a solution worth exploring for the Unity LTS. Hey Gunnar, Thanks for the suggestion. I would prefer avoiding trying a new solution though, especially during a LTS cycle. We have basically 2 options we experimented with, it would make sense to just go with one of those... Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Handling of layout/input methods in Unity: what should we do for the LTS?
On Tue, Nov 12, 2013, Sebastien Bacher wrote: * keep pushing forward to try to solve those issues (e.g move the keygrabbing to compiz, look at where we stand there). That should give us a mostly working system, but: - it means increasing changes before a LTS, which has potential to create new issues - we are not sure that applications are going to be fixed before the LTS, and how much of an annoyance that's going to be for our users - we are spending more efforts on trying to fix things for Unity7/xorg, for a problem that is going to go away with Unity8/Mir (things are going to work differently under Mir/wayland) How will the Mir/Wayland approach look like? Could we leverage it for Unity 7? * roll back to what we had until 13.04 We can't ship Unity 8 in the desktop for 14.04 due to the dependency on Mir, so since we picked the ship known good / stable stack in 14.04 desktop approach, it would be consistent to pick the good / stable old way of switching keyboard layouts and handling shortcuts -- unless it's a lot of work to rollback, in comparison to moving to the new world. From a risk point of view, the second option seems like the safest one, but from an efforts point of view this depends on how much work it is to produce an Unity 8 image with a new keyboard layouts / shortcuts solution + finding a solution for Ubuntu Desktop. -- 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: Handling of layout/input methods in Unity: what should we do for the LTS?
Le 13/11/2013 17:49, Loïc Minier a écrit : How will the Mir/Wayland approach look like? Could we leverage it for Unity 7? I expect the approach in the new world to be similar to the recent work. It should be easier under Mir/Wayland since we are not going to have to fight with X grabs and xkb limitations there (e.g Mir should be watching for those events and sending the signal to do the action associated to the keybinding). That's a topic that should be discussed with the Mir/Unity8 though ... do you know if that's on the roadmap for this cycle (handling of external keyboards and layouts/input methods/keybindings on the desktop)? unless it's a lot of work to rollback, in comparison to moving to the new world. Well, we are almost done with the work we have been doing. The issue is that we are hitting the problems I listed, especially the ones with apps like libreoffice that require to fix the applications. I expect applications are not going to be an issue in touch because there is less legacy and the ones newly written or using the standard toolkits shouldn't have those issues. Rollback is not that much work in any case. From a risk point of view, the second option seems like the safest one, but from an efforts point of view this depends on how much work it is to produce an Unity 8 image with a new keyboard layouts / shortcuts solution + finding a solution for Ubuntu Desktop. The solutions are going to be different in both setups (since the input stack used is not the same), it also depends on the input method framework we are going to use (there is still the ongoing ibus or fcitx discussion, with a session at vUDS next week) Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Fri, Nov 8, 2013 at 1:33 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: Though since we're talking about it, the one stop gap fix that would make me happy would be if all Ubuntu Developers could trigger the equivalent of the local 'requeue_package.py --full' command that UDD admins can run. Some history might get lost, but at least out of date branches could be made usable. This seems to have been the topic that has generated the most interest. It seems to be a bit of an overkill to have a vUDS session on it, especially if we don't have the right people in the room. So maybe we can try to hammer out the requirements here? Currently you need shell access to Jubany in order to run the command. [0] I know that this request has come up in the past, but my Google-fu is failing me now. Adding the (seemingly dormant) UDD list to the conversation in hopes of catching the right person. [0] https://bugs.launchpad.net/udd/+bug/713719 -- Andrew Starr-Bochicchio Ubuntu Developer https://launchpad.net/~andrewsomething Debian Developer http://qa.debian.org/developer.php?login=asb PGP/GPG Key ID: D53FDCB1 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On 13 November 2013 17:39, Andrew Starr-Bochicchio a.star...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:33 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: Though since we're talking about it, the one stop gap fix that would make me happy would be if all Ubuntu Developers could trigger the equivalent of the local 'requeue_package.py --full' command that UDD admins can run. Some history might get lost, but at least out of date branches could be made usable. This seems to have been the topic that has generated the most interest. It seems to be a bit of an overkill to have a vUDS session on it, especially if we don't have the right people in the room. So maybe we can try to hammer out the requirements here? Currently you need shell access to Jubany in order to run the command. [0] I know that this request has come up in the past, but my Google-fu is failing me now. Adding the (seemingly dormant) UDD list to the conversation in hopes of catching the right person. [0] https://bugs.launchpad.net/udd/+bug/713719 I requeue packages from time to time, upon request. But I don't keep a track of packages for which full requeue doesn't help. Nor have a good way to process such requests. Maybe a request wiki page? I'd subscribe to it, and would comment which one requeued and whether that fixes / not fixes the branch. Regards, Dmitrijs. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
Hi all, On Wed, Nov 13, 2013 at 9:39 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:33 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: Though since we're talking about it, the one stop gap fix that would make me happy would be if all Ubuntu Developers could trigger the equivalent of the local 'requeue_package.py --full' command that UDD admins can run. Some history might get lost, but at least out of date branches could be made usable. This seems to have been the topic that has generated the most interest. It seems to be a bit of an overkill to have a vUDS session on it, especially if we don't have the right people in the room. So maybe we can try to hammer out the requirements here? Yes, that would be nice. For example, I think the only reason preventing me from doing a qt4-x11 merge is the non-working UDD branch for that package. -- Dmitry Shachnev -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Wed, Nov 13, 2013 at 07:17:56PM +, Dmitrijs Ledkovs wrote: On 13 November 2013 17:39, Andrew Starr-Bochicchio a.star...@gmail.com wrote: On Fri, Nov 8, 2013 at 1:33 PM, Andrew Starr-Bochicchio a.star...@gmail.com wrote: Though since we're talking about it, the one stop gap fix that would make me happy would be if all Ubuntu Developers could trigger the equivalent of the local 'requeue_package.py --full' command that UDD admins can run. Some history might get lost, but at least out of date branches could be made usable. This seems to have been the topic that has generated the most interest. It seems to be a bit of an overkill to have a vUDS session on it, especially if we don't have the right people in the room. So maybe we can try to hammer out the requirements here? Currently you need shell access to Jubany in order to run the command. [0] I know that this request has come up in the past, but my Google-fu is failing me now. Adding the (seemingly dormant) UDD list to the conversation in hopes of catching the right person. [0] https://bugs.launchpad.net/udd/+bug/713719 I requeue packages from time to time, upon request. But I don't keep a track of packages for which full requeue doesn't help. Nor have a good way to process such requests. Maybe a request wiki page? I'd subscribe to it, and would comment which one requeued and whether that fixes / not fixes the branch. I would suggest using https://bugs.launchpad.net/udd/ itself for tracking this. But I think it would be more interesting to get a permanent fix for this bug: https://bugs.launchpad.net/udd/+bug/714622 This accounts for the problem people have mentioned, that core packages are much more likely to have failed imports. The importer badly needs fixed to not throw up its hands when the revision ID of a tag has changed; it should only care about this when the branch contents are wrong. This single bug accounts for just under half of all importer failures, and is a failure scenario that the importer *could*, with sufficient smarts, resolve automatically. -- 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: Handling of layout/input methods in Unity: what should we do for the LTS?
On Wed, Nov 13, 2013, Sebastien Bacher wrote: That's a topic that should be discussed with the Mir/Unity8 though ... do you know if that's on the roadmap for this cycle (handling of external keyboards and layouts/input methods/keybindings on the desktop)? (I don't know whether this is on the roadmap) -- 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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Nov 13, 2013, at 11:32 AM, Steve Langasek wrote: But I think it would be more interesting to get a permanent fix for this bug: https://bugs.launchpad.net/udd/+bug/714622 This accounts for the problem people have mentioned, that core packages are much more likely to have failed imports. The importer badly needs fixed to not throw up its hands when the revision ID of a tag has changed; it should only care about this when the branch contents are wrong. This single bug accounts for just under half of all importer failures, and is a failure scenario that the importer *could*, with sufficient smarts, resolve automatically. This may be controversial, but (except for trying to fix error conditions), I think we should disallow all developer pushes to UDD branches and only let the importer write to them. It's simply too error prone otherwise, and there's no good reason for it. One possible reason for developers to push to UDD branches is to share the code with other people, or to avoid the lag in importer runs. Of course the former can be easily handled by pushing to a personal branch. The latter? Oh well, I can live with that for error-free branches. ;) A long time ago I decided never to push UDD branches and always let the importer update them. I've never regretted that or encountered problems with that discipline. 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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Nov 13, 2013, at 11:32 AM, Steve Langasek wrote: But I think it would be more interesting to get a permanent fix for this bug: https://bugs.launchpad.net/udd/+bug/714622 This accounts for the problem people have mentioned, that core packages are much more likely to have failed imports. The importer badly needs fixed to not throw up its hands when the revision ID of a tag has changed; it should only care about this when the branch contents are wrong. This single bug accounts for just under half of all importer failures, and is a failure scenario that the importer *could*, with sufficient smarts, resolve automatically. This may be controversial, but (except for trying to fix error conditions), I think we should disallow all developer pushes to UDD branches and only let the importer write to them. It's simply too error prone otherwise, and there's no good reason for it. One possible reason for developers to push to UDD branches is to share the code with other people, or to avoid the lag in importer runs. Of course the former can be easily handled by pushing to a personal branch. The latter? Oh well, I can live with that for error-free branches. ;) A long time ago I decided never to push UDD branches and always let the importer update them. I've never regretted that or encountered problems with that discipline. 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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Wed, Nov 13, 2013 at 03:33:59PM -0500, Barry Warsaw wrote: On Nov 13, 2013, at 11:32 AM, Steve Langasek wrote: But I think it would be more interesting to get a permanent fix for this bug: https://bugs.launchpad.net/udd/+bug/714622 This accounts for the problem people have mentioned, that core packages are much more likely to have failed imports. The importer badly needs fixed to not throw up its hands when the revision ID of a tag has changed; it should only care about this when the branch contents are wrong. This single bug accounts for just under half of all importer failures, and is a failure scenario that the importer *could*, with sufficient smarts, resolve automatically. This may be controversial, but (except for trying to fix error conditions), I think we should disallow all developer pushes to UDD branches and only let the importer write to them. It's simply too error prone otherwise, and there's no good reason for it. One possible reason for developers to push to UDD branches is to share the code with other people, or to avoid the lag in importer runs. Of course the former can be easily handled by pushing to a personal branch. The latter? Oh well, I can live with that for error-free branches. ;) A long time ago I decided never to push UDD branches and always let the importer update them. I've never regretted that or encountered problems with that discipline. Cheers, -Barry Hmm, so if we can't planned changes to UDD branches and have to use a separate user-owned branch for that, then what's the use of the UDD branch? It sounds to me like it'd then be much easier for me to just maintain my own branch on the side and upload from there, ignoring UDD entirely, which surely isn't what we want there. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com 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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
Quoting Stéphane Graber (stgra...@ubuntu.com): On Wed, Nov 13, 2013 at 03:33:59PM -0500, Barry Warsaw wrote: On Nov 13, 2013, at 11:32 AM, Steve Langasek wrote: But I think it would be more interesting to get a permanent fix for this bug: https://bugs.launchpad.net/udd/+bug/714622 This accounts for the problem people have mentioned, that core packages are much more likely to have failed imports. The importer badly needs fixed to not throw up its hands when the revision ID of a tag has changed; it should only care about this when the branch contents are wrong. This single bug accounts for just under half of all importer failures, and is a failure scenario that the importer *could*, with sufficient smarts, resolve automatically. This may be controversial, but (except for trying to fix error conditions), I think we should disallow all developer pushes to UDD branches and only let the importer write to them. It's simply too error prone otherwise, and there's no good reason for it. One possible reason for developers to push to UDD branches is to share the code with other people, or to avoid the lag in importer runs. Of course the former can be easily handled by pushing to a personal branch. The latter? Oh well, I can live with that for error-free branches. ;) A long time ago I decided never to push UDD branches and always let the importer update them. I've never regretted that or encountered problems with that discipline. Cheers, -Barry Hmm, so if we can't planned changes to UDD branches and have to use a separate user-owned branch for that, then what's the use of the UDD branch? It sounds to me like it'd then be much easier for me to just maintain my own branch on the side and upload from there, ignoring UDD entirely, which surely isn't what we want there. Let's say three of us are working together on the next release of package foo. While ironing out a new feature, we want to stash a low prio bugfix to go into the same release. This happens quite often, and a UDD branch that we can write to is a nice place to stash these. Otherwise, yes, we simply need an out-of-band shared tree. Of course then the importer has to deal with differences. When I first started looking at UDD, it took me awhile to realize that there was no way to feed a tag to the UDD branch to say 'now build source packages and push from that to the archive' :) I would have expected that, plus an error message on dput if there is a conflict in the udd branch. -serge -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
Le 13/11/2013 21:43, Stéphane Graber a écrit : Hmm, so if we can't planned changes to UDD branches and have to use a separate user-owned branch for that, then what's the use of the UDD branch? That's a good question ... what's the goal of UDD? Having an history of the changes that is easy to query? Make possible to stage changes without uploading? Have an easy way to integrate into launchpad for reviews (by using the merge requests)? Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Nov 13, 2013, at 03:43 PM, Stéphane Graber wrote: Hmm, so if we can't planned changes to UDD branches and have to use a separate user-owned branch for that, then what's the use of the UDD branch? It sounds to me like it'd then be much easier for me to just maintain my own branch on the side and upload from there, ignoring UDD entirely, which surely isn't what we want there. We're all familiar with workflows where landings to the master branch are guarded by robots like Jenkins or Tarmac. I think of this exactly the same way, with the 'bot being the importer. -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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Nov 13, 2013, at 09:54 PM, Sebastien Bacher wrote: That's a good question ... what's the goal of UDD? Having an history of the changes that is easy to query? Make possible to stage changes without uploading? Have an easy way to integrate into launchpad for reviews (by using the merge requests)? Yes, merge proposals, sponsoring, collaborative branches, etc. Also, local version control while you're developing changes, being able to better manage upstream or Debian merges, etc. In my previous 'bot analogy, there's one difference: your local commits won't show up as a side line-of-development once the importer lands your changes. That'll make the git fast-forward fans happy though. :) -Barry -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Wed, Nov 13, 2013 at 04:19:19PM -0500, Barry Warsaw wrote: On Nov 13, 2013, at 03:43 PM, Stéphane Graber wrote: Hmm, so if we can't planned changes to UDD branches and have to use a separate user-owned branch for that, then what's the use of the UDD branch? It sounds to me like it'd then be much easier for me to just maintain my own branch on the side and upload from there, ignoring UDD entirely, which surely isn't what we want there. We're all familiar with workflows where landings to the master branch are guarded by robots like Jenkins or Tarmac. I think of this exactly the same way, with the 'bot being the importer. -Barry Sure, except that for those projects, there's an incentive to push a MP and wait for the bot to process it as otherwise the change won't land. For UDD, if we can't commit to the branch, then there's zero benefit in even using it as the source branch as I could just as well use apt-get source, which will get me the current package from the archive (which UDD doesn't necessarily give me...), then apply changes and push that. Not having commit rights to the UDD branch would make UDD a simple archiving service and based on its current state, a pretty bad one at that. To clarifiy my position, I really like UDD and I think that kind of VCS integration is what we want for the distro, but it's never been working reliably enough to gain sufficient momentum. In a perfect world, I'd have a VCS repository containing branches for all Ubuntu series and pockets, for the various Debian releases and for the upstream code, making any rebase/cherry-pick trivial and having LP trigger builds on either a special signed commit or a signed tag. Also in that perfect world, the inner workings of our upload process would be tied to that, so that it wouldn't be possible for the branch to be out of sync with the archive. This could be achieved by either making this the only way to upload or making the legacy upload path, commit to the branch and export from there prior to processing. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com 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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Nov 13, 2013, at 04:28 PM, Stéphane Graber wrote:
For UDD, if we can't commit to the branch, then there's zero benefit in
even using it as the source branch as I could just as well use apt-get
source, which will get me the current package from the archive (which
UDD doesn't necessarily give me...), then apply changes and push that.
For simple package changes, you could have a point, but I rarely encounter
simple package changes specifically in Ubuntu. Usually I'm merging a new
upstream, or Debian version, and then local version control is often a
godsend. Sometimes the merge goes badly, or you have conflicts, or it's not
enough to get a working Ubuntu package. I can do the merge, commit that local
change, and then do further commits locally as I refine the package to build
and work properly. I can diff between revisions, revert changes, etc.
E.g. all the benefits of version control. I can create side branches of my
main branch to try things out, then merge them back into my main branch. All
this is especially useful if you are working on a package over some span of
time.
apt-get source is like performing without a net. Let's say you head down the
wrong path while updating a package. It's very difficult to backup and try
again, take side travels for experimentation, etc. Oh, and chdist is nice,
but I prefer having ubuntu:series{,-proposed}/package branches.
Not having commit rights to the UDD branch would make UDD a simple
archiving service and based on its current state, a pretty bad one at
that.
To clarifiy my position, I really like UDD and I think that kind of VCS
integration is what we want for the distro, but it's never been working
reliably enough to gain sufficient momentum.
In a perfect world, I'd have a VCS repository containing branches for
all Ubuntu series and pockets, for the various Debian releases and for
the upstream code, making any rebase/cherry-pick trivial and having LP
trigger builds on either a special signed commit or a signed tag.
Also in that perfect world, the inner workings of our upload process
would be tied to that, so that it wouldn't be possible for the branch to
be out of sync with the archive. This could be achieved by either making
this the only way to upload or making the legacy upload path, commit
to the branch and export from there prior to processing.
I'll agree with you there. I'd love to live in this world. :)
-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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Wed, Nov 13, 2013 at 04:38:17PM -0500, Barry Warsaw wrote:
On Nov 13, 2013, at 04:28 PM, Stéphane Graber wrote:
For UDD, if we can't commit to the branch, then there's zero benefit in
even using it as the source branch as I could just as well use apt-get
source, which will get me the current package from the archive (which
UDD doesn't necessarily give me...), then apply changes and push that.
For simple package changes, you could have a point, but I rarely encounter
simple package changes specifically in Ubuntu. Usually I'm merging a new
upstream, or Debian version, and then local version control is often a
godsend. Sometimes the merge goes badly, or you have conflicts, or it's not
enough to get a working Ubuntu package. I can do the merge, commit that local
change, and then do further commits locally as I refine the package to build
and work properly. I can diff between revisions, revert changes, etc.
E.g. all the benefits of version control. I can create side branches of my
main branch to try things out, then merge them back into my main branch. All
this is especially useful if you are working on a package over some span of
time.
apt-get source is like performing without a net. Let's say you head down the
wrong path while updating a package. It's very difficult to backup and try
again, take side travels for experimentation, etc. Oh, and chdist is nice,
but I prefer having ubuntu:series{,-proposed}/package branches.
Well, to be fair my fallback process when not doing UDD is:
- pull-lp-source package series
- cd */
- bzr init bzr add bzr commit -m current
- Do whatever changes, commit when needed, revert, ...
- bzr bd -S
- dput
Which based on what you described about commitless UDD seems pretty much
identical with the significant improvement that I don't have to grab the
whole branch on top of that :)
I could also push and share that temporary branch with others and
there'd be no downside to this since I wouldn't be able to merge that
branch back into the UDD one anyway.
At least for me, UDD without commit rights, would mean lost granularity
in some changes I'm doing in the archive, for example for some of the
edubuntu packages I've had dozens of commits before an actual upload,
and I quite enjoy having that present in the UDD history, loosing that
ability would be loosing much of UDD's benefits.
Not having commit rights to the UDD branch would make UDD a simple
archiving service and based on its current state, a pretty bad one at
that.
To clarifiy my position, I really like UDD and I think that kind of VCS
integration is what we want for the distro, but it's never been working
reliably enough to gain sufficient momentum.
In a perfect world, I'd have a VCS repository containing branches for
all Ubuntu series and pockets, for the various Debian releases and for
the upstream code, making any rebase/cherry-pick trivial and having LP
trigger builds on either a special signed commit or a signed tag.
Also in that perfect world, the inner workings of our upload process
would be tied to that, so that it wouldn't be possible for the branch to
be out of sync with the archive. This could be achieved by either making
this the only way to upload or making the legacy upload path, commit
to the branch and export from there prior to processing.
I'll agree with you there. I'd love to live in this world. :)
-Barry
--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Wed, Nov 13, 2013 at 03:32:38PM -0500, Barry Warsaw wrote: On Nov 13, 2013, at 11:32 AM, Steve Langasek wrote: But I think it would be more interesting to get a permanent fix for this bug: https://bugs.launchpad.net/udd/+bug/714622 This accounts for the problem people have mentioned, that core packages are much more likely to have failed imports. The importer badly needs fixed to not throw up its hands when the revision ID of a tag has changed; it should only care about this when the branch contents are wrong. This single bug accounts for just under half of all importer failures, and is a failure scenario that the importer *could*, with sufficient smarts, resolve automatically. This may be controversial, but (except for trying to fix error conditions), I think we should disallow all developer pushes to UDD branches and only let the importer write to them. It's simply too error prone otherwise, and there's no good reason for it. I disagree 100%. To me, this is the only reason to *have* UDD branches. If we're never going to push to the branches, then the whole thing is a futile exercise. Being able to use bzr blame / bzr diff to traverse history at per-upload granularity is not sufficiently interesting to justify the effort of supporting UDD. As long as there are other VCS branches for core packages that are richer and more authoritative with finer-grained history, UDD branches will continue to be confusingly redundant. If we've resigned ourselves to the notion that they will never be a suitable replacement for maintainer branches, then we should kill UDD off entirely instead of continuing to invest time and hardware resources in giving developers a poor VCS experience that requires you to play a game of 20 questions to figure out the right place to get the package's source. One possible reason for developers to push to UDD branches is to share the code with other people, or to avoid the lag in importer runs. The reason for pushing to the UDD branches is so that changes to the package are grouped logically, and you can use the branch history as a useful forensic tool, or as a source for cherry-picking changes. Having UDD branches that exist but are *not* an authoritative source for this information is actively harmful. At the time UDD was conceived. this was considered an acceptable temporary downside on the path to a full branch-based workflow. Now that it's clear that having imports of full upstream history into UDD is not on the horizon, we should work out what to do to avoid continuing to provide UDD as a bad service. Of course the former can be easily handled by pushing to a personal branch. The latter? Oh well, I can live with that for error-free branches. ;) This error is not with the branches, but with the importer for imposing unnecessary constraints on the branches. In nearly all of the cases where that bug hits us, the branch *contents* are identical to what the importer would have generated, which means the importer should accept the ID change and move on. In cases where the contents don't match, the importer should win and move the branch aside - in fact, it's supposed to already do this. But if we no longer have anyone who can fix this importer problem, then we should admit defeat and scrap UDD altogether. A long time ago I decided never to push UDD branches and always let the importer update them. I've never regretted that or encountered problems with that discipline. That works ok for packages that are only touched once in a blue moon. But making this a policy means that UDD is no longer useful for core packages like upstart, and all our rich branch history is going to go somewhere else. This doesn't solve the problem that people are actually complaining about, namely that UDD branches are not useful for packages that are actively maintained - it merely codifies it, and exacerbates the related problem that UDD branches only sometimes provide a useful workflow for outside contributors. -- 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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
On Nov 13, 2013, at 04:51 PM, Stéphane Graber wrote: Well, to be fair my fallback process when not doing UDD is: - pull-lp-source package series - cd */ - bzr init bzr add bzr commit -m current - Do whatever changes, commit when needed, revert, ... - bzr bd -S - dput For my UDD branches, I always branch them into a shared repository, under the assumption that if I've grabbed the package once, the next time I'll have most of the revisions already downloaded, so the branching is quicker. I guess pull-lp-source essentially fills the roll of `chdist apt-get series blah` although the former has a bit more flexibility in how you specify the exact branch you want. Which based on what you described about commitless UDD seems pretty much identical with the significant improvement that I don't have to grab the whole branch on top of that :) Could be, although I have to type less :). I could also push and share that temporary branch with others and there'd be no downside to this since I wouldn't be able to merge that branch back into the UDD one anyway. For out-of-date branches, I think they'd be roughly equivalent. For up-to-date branches, not getting the UDD branch means you wouldn't be able to merge propose, which also makes sponsoring more difficult (patches/debdiffs are like dead things, branches are alive! :). At least for me, UDD without commit rights, would mean lost granularity in some changes I'm doing in the archive, for example for some of the edubuntu packages I've had dozens of commits before an actual upload, and I quite enjoy having that present in the UDD history, loosing that ability would be loosing much of UDD's benefits. I'm a little unclear if you mean that you do pushes to the parent UDD branch for each of those commits. Doesn't that mean that the UDD branch won't mirror the contents of the source package? If so, is that a good thing? Or maybe you only push once the package is dput'd. I am concerned about workflows where the UDD branch is not a reflection of the contents of the source package, modulo short importer lag. It's too bad there's no way to capture those non-pushed intermediate commits in the source package you upload, such that the importer would apply them, and they would be preserved in the master UDD branch. -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: Giving developers access to requeue package imports [Was: Ubuntu Platform developers BOF session?]
Barry Warsaw [2013-11-13 15:33 -0500]: This may be controversial, but (except for trying to fix error conditions), I think we should disallow all developer pushes to UDD branches and only let the importer write to them. It's simply too error prone otherwise, and there's no good reason for it. This sounds like admitting defeat like these branches are too complicated to handle. (I couldn't agree more for patches, but for non-patch packaging changes I don't). So what's the point in having that then? You have the exact same granularity as the by-upload changes that we already have in soyuz, except for triplicating the time and bandwidth to get a package and still having to deal with the quilt mess. With that, we lose the important capability of several people contributing to the next upload, or staging changes which aren't important enough by themselves to upload. One possible reason for developers to push to UDD branches is to share the code with other people, or to avoid the lag in importer runs. Of course the former can be easily handled by pushing to a personal branch. No. It's hard enough to teach people to look at trunk, we can't expect developers to search for any existing branch out there before they do an upload. A long time ago I decided never to push UDD branches and always let the importer update them. I've never regretted that or encountered problems with that discipline. That's what I do for sponsoring and SRUs (the former because few people ever get the patch stuff right, and the latter because UDD is broken for SRUs), but I primarily considered that a workaround, not an intended workflow. 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
