Re: proposal do disallow syncs of library packages from experimental without approval
Hello, On Wed, Oct 05, 2011 at 05:21:05PM -0700, Steve Langasek wrote: On Wed, Oct 05, 2011 at 04:17:43PM +0100, Iain Lane wrote: On Wed, Oct 05, 2011 at 03:55:54PM +0100, Colin Watson wrote: […] All three cases have in common that the packages were left alone for months. The third example could have been avoided if we could check build dependencies when syncing, and rejecting the sync when the b-d's are not fulfilled (although there should be an override option). I don't want to add extra archive-admin checking to the sync process; firstly, we're moving towards self-service syncs anyway, and secondly, as the libav example shows, syncs aren't really special here. More discipline for library upgrades would indeed be a good thing. The main problem seems to be library upgrades that don't really have anyone looking after them (and this is worst when it's Ubuntu-local or from Debian experimental; at least in unstable the Debian release team usually cares to some extent). IMO, we should make it clear that if you sync or merge a library from experimental then it is your responsibility to ensure that all reverse-dependencies are ported. Right: if you introduce a SONAME bump (or similar) you should care for it. This cycle the burden has fallen upon those who choose to care for the NBS list, and that's neither fair nor sustainable. Most of these uploads will have to go through binary NEW so that is a good opportunity to check with the uploader that they plan to address the ramifications of the uploads they introduce. I don't think this is something archive admins should be expected to do; it's not in keeping with the other kinds of archive consistency checks they're responsible for. It's also, in a sense, too late - by the time the package hits binary new, the source version is already in the archive, so we have to deal with the transition in one way or another. OK. It just seemed like a place where we could have said has this developer prepared for the transition they are starting?. I didn't think there would be any rejections at this stage, just some basic checks. Like Scott, I think this needs to be the responsibility of the developer starting the transition, and this is true regardless of the origin. I think the point of starting this thread is to get a consensus that this is the right way to handle transitions and to *raise awareness* of the issue, with a particular emphasis on experimental because pulling in a transition from experimental means we effectively have no backing from the Debian maintainers for getting it done in a timely manner (i.e., within an Ubuntu release cycle). I'm most definitely not saying that people shouldn't take responsibility for their transitions. That is pretty much the opposite of what I want, which is to socialise the idea that transitions aren't something that you can expect others to clean up after you for — you are responsible for seeing them through. I think a little bit of pushback will get the message out. And if it fails to then we can fetch the bigger hammers. Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] 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: proposal do disallow syncs of library packages from experimental without approval
On Thu, Oct 06, 2011 at 04:00:55PM +0200, Sebastien Bacher wrote: Le jeudi 06 octobre 2011 à 13:28 +0100, Iain Lane a écrit : You might not ever hear about it, but every time something is removed you are potentially letting people down. Right, but every time an annoying but in a software that 90% of our users run is not fixed because the time has been spent on a package used by a few users in universe how many users do we let down? Developers aren't interchangeable. If you don't have time yourself then it's perfectly reasonable to organise people to help out; you'll probably save about as much time that way because you won't have to field so many complaints. The problem is when people simply ignore and abandon the problem. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
On Thursday, October 06, 2011 03:27:13 PM Colin Watson wrote: On Thu, Oct 06, 2011 at 04:00:55PM +0200, Sebastien Bacher wrote: Le jeudi 06 octobre 2011 à 13:28 +0100, Iain Lane a écrit : You might not ever hear about it, but every time something is removed you are potentially letting people down. Right, but every time an annoying but in a software that 90% of our users run is not fixed because the time has been spent on a package used by a few users in universe how many users do we let down? Developers aren't interchangeable. If you don't have time yourself then it's perfectly reasonable to organise people to help out; you'll probably save about as much time that way because you won't have to field so many complaints. The problem is when people simply ignore and abandon the problem. +1 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: proposal do disallow syncs of library packages from experimental without approval
On Thursday, October 06, 2011 10:03:26 AM Matthias Klose wrote: On 10/05/2011 10:47 PM, Scott Kitterman wrote: On Wednesday, October 05, 2011 09:30:22 PM Sebastien Bacher wrote: To take an example I think porting universe GNOME2 applets to GNOME3 wouldn't be a good use of our time, we better spend the resources we have making sure our current desktop version is great. If some people want to work on porting the applications they care about, great, otherwise the source can be dropped and will come back once its upstream or somebody else pick it up and update the code. I think Gnome2 - Gnome3 is an exceptional case where that is particularly true. In general either all that's needed are rebuilds or digging for patches. I think if we're going to do a transition the developer needs to at least follow through and try to deal with Universe and file bugs where things fail. I don't think just fixing Main and then saying Meh, Universe, Whatever is appropriate. We do have more exceptional cases like compiler and linker changes, other major version changes which are better handled in that the proposed way forward is announced (apologies if I did miss it for Gnome2, I only did see the release goal getting gtk2 off the images). The removal of the GNOME2 applet related packages was done, which is fine, although I assume that some effort went into attempts to fix things before the removal of those packages. all that's needed are rebuilds is a lot to do, and it doesn't help if major changes are still done after the last test rebuild. This cycle's example is the change in gtk/gnome's pkg-config files moving libraries from the Libs to the Libs.private attribute, resulting in build failures (no, we don't know which ones are not yet detected, how many, etc, libgnomeprintui still not fixed). Such a change is appropriate before feature freeze, but not after. I'd like to challenge the general freeze exception for Gnome and KDE for the LTS, if changes like this are more or less blindly applied, even if these are found in upstream release candidates. KDE doesn't need any standing freeze exception now that we are basing exceptions on features and not version numbers. The KDE SC 4.X.0 release comes before feature freeze so upstream is only bug fixing after that. Any case from an upstream update that violated Ubuntu's feature freeze would also violate upstream's maintenance policy. 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: proposal do disallow syncs of library packages from experimental without approval
On Wed, Oct 05, 2011 at 04:08:31PM +0200, Matthias Klose wrote: During the oneiric development cycle we had syncs of library packages from experimental, introducing new sonames, and changing APIs in a way that other packages need to be ported to the new API, or if the port isn't trivial, need to be removed at the end of the cycle. This doesn't add much benefit to the distribution, compared to the work to clean up the distribution and forward port packages which otherwise don't require this kind of work (assuming the package is synced from Debian). Options to handle such syncs could be - Keep the don't care attitude, and just remove packages at the end of the cycle (although removal of non-leaf packages comes with a price too, and isn't seen as user friendly). - Get approval for a library sync from experimental, listing the rdepends, API changes, and estimate the effort to complete this library transition. - Don't sync packages from experimental. - Stage the required reverse-dependency changes in a PPA or similar in advance if at all possible. (I like that option) There were at least three libraries synced from experimental which required work up into the beta phase (I don't have numbers for the successful syncs and merges from experimental): - dcmtk, synced from experimental during the end of the natty cycle, requested MIR (bug 702026). Left alone until the end of the oneiric cycle, then turned out that the library wasn't even needed. Caused some grief in bug 779170. Unsure if the sync review would be a help, because in the end it was uploaded to unstable and the corresponding debian report is still open (debian 623145). - libevent, synced from experimental on 2011-07-08, the sync was requested in bug 796187. A large number of packages still had to be converted from libevent1 to libevent2, and finally we had to package libevent1 to not remove other packages. Issues were discussed in other distros too: http://comments.gmane.org/gmane.linux.redhat.fedora.devel/148007 - opal, synced on 2011-05-02, with unresolvable build dependencies, needed another version update and new versions of three packages during feature freeze (bug 836915). afaics, no discussion for the sync. libav was a merge from experimental rather than a sync, but it was troublesome too. All three cases have in common that the packages were left alone for months. The third example could have been avoided if we could check build dependencies when syncing, and rejecting the sync when the b-d's are not fulfilled (although there should be an override option). I don't want to add extra archive-admin checking to the sync process; firstly, we're moving towards self-service syncs anyway, and secondly, as the libav example shows, syncs aren't really special here. More discipline for library upgrades would indeed be a good thing. The main problem seems to be library upgrades that don't really have anyone looking after them (and this is worst when it's Ubuntu-local or from Debian experimental; at least in unstable the Debian release team usually cares to some extent). IMO, we should make it clear that if you sync or merge a library from experimental then it is your responsibility to ensure that all reverse-dependencies are ported. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
Hiya, On Wed, Oct 05, 2011 at 03:55:54PM +0100, Colin Watson wrote: […] All three cases have in common that the packages were left alone for months. The third example could have been avoided if we could check build dependencies when syncing, and rejecting the sync when the b-d's are not fulfilled (although there should be an override option). I don't want to add extra archive-admin checking to the sync process; firstly, we're moving towards self-service syncs anyway, and secondly, as the libav example shows, syncs aren't really special here. More discipline for library upgrades would indeed be a good thing. The main problem seems to be library upgrades that don't really have anyone looking after them (and this is worst when it's Ubuntu-local or from Debian experimental; at least in unstable the Debian release team usually cares to some extent). IMO, we should make it clear that if you sync or merge a library from experimental then it is your responsibility to ensure that all reverse-dependencies are ported. Right: if you introduce a SONAME bump (or similar) you should care for it. This cycle the burden has fallen upon those who choose to care for the NBS list, and that's neither fair nor sustainable. Most of these uploads will have to go through binary NEW so that is a good opportunity to check with the uploader that they plan to address the ramifications of the uploads they introduce. If people cannot be trusted to take care of their transitions (if, after a time of enforcing this additional social pressure the situation is still not improving enough) then the release team can step in and ask that such uploads be run through them first, in a similar-but-not-as-complicated role to that played by the Debian release team. As we rely quite heavily on Debian for QA anyway, we can probably only care for those transitions happening in Ubuntu first (as you said). Cheers, -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] PhD student [ i...@cs.nott.ac.uk ] 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: proposal do disallow syncs of library packages from experimental without approval
On Wednesday, October 05, 2011 04:17:43 PM Iain Lane wrote: Hiya, On Wed, Oct 05, 2011 at 03:55:54PM +0100, Colin Watson wrote: […] All three cases have in common that the packages were left alone for months. The third example could have been avoided if we could check build dependencies when syncing, and rejecting the sync when the b-d's are not fulfilled (although there should be an override option). I don't want to add extra archive-admin checking to the sync process; firstly, we're moving towards self-service syncs anyway, and secondly, as the libav example shows, syncs aren't really special here. More discipline for library upgrades would indeed be a good thing. The main problem seems to be library upgrades that don't really have anyone looking after them (and this is worst when it's Ubuntu-local or from Debian experimental; at least in unstable the Debian release team usually cares to some extent). IMO, we should make it clear that if you sync or merge a library from experimental then it is your responsibility to ensure that all reverse-dependencies are ported. Right: if you introduce a SONAME bump (or similar) you should care for it. This cycle the burden has fallen upon those who choose to care for the NBS list, and that's neither fair nor sustainable. Most of these uploads will have to go through binary NEW so that is a good opportunity to check with the uploader that they plan to address the ramifications of the uploads they introduce. If people cannot be trusted to take care of their transitions (if, after a time of enforcing this additional social pressure the situation is still not improving enough) then the release team can step in and ask that such uploads be run through them first, in a similar-but-not-as-complicated role to that played by the Debian release team. As we rely quite heavily on Debian for QA anyway, we can probably only care for those transitions happening in Ubuntu first (as you said). When I started a library transition I've always felt it was my job to drive it to closure. I don't think it matters much if it's a post DIF merge/sync from Unstable or some upload from Experimental, the potential issues are the same. There's more risk of it being harder from Experimental, but I think that's a difference of degree, not kind. If it's not clear that developers are responsible for this, then we ought to communicate this better (and I include if you sponsor such an upload/sync then I think you are on the hook for this, it's not just up to the non-developer you are sponsoring - hopefully they'll do this, but you (the developer) are the one responsible). If people won't take care of their transitions (or make a best effort and seek help - sometimes these things turn out to be way harder than one person can deal with), then I question if they are people that should be Ubuntu developers. 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: proposal do disallow syncs of library packages from experimental without approval
Hi Scott (2011.10.05_18:23:38_+0200) When I started a library transition I've always felt it was my job to drive it to closure. That's certainly what I've always seen people say when asked how transitions were managed in Ubuntu. If it's not clear that developers are responsible for this, then we ought to communicate this better (and I include if you sponsor such an upload/sync then I think you are on the hook for this, it's not just up to the non-developer you are sponsoring - hopefully they'll do this, but you (the developer) are the one responsible). The sponsors not requesting testing and a transition effort commitment is something I've noticed too. I see transition sync requests that I don't look at immediately because they'll need a fair amount of review, and 10 mins later someone has gleefully sponsored them because they build successfully. SR -- Stefano Rivera http://tumbleweed.org.za/ H: +27 21 465 6908 C: +27 72 419 8559 UCT: x3127 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
Le mercredi 05 octobre 2011 à 16:08 +0200, Matthias Klose a écrit : During the oneiric development cycle we had syncs of library packages from experimental, introducing new sonames, and changing APIs in a way that other Hi, The issue is not really specific to experimental, that could happen the same way with updates done in Ubuntu directly or syncs from unstable. While I agree that people who start a transition should have some responsibilities in it I also think that we should be ok with dropping unmaintained code which is not ported at the end of the cycle (and not especially require that whoever started the transition has to be the one that should fix the universe). If we had the resources to both push forward our default installation with the softwares most users care and port the universe it would be great but in really we don't and I think we shouldn't let universe crufts stop use to improve the default experience. To take an example I think porting universe GNOME2 applets to GNOME3 wouldn't be a good use of our time, we better spend the resources we have making sure our current desktop version is great. If some people want to work on porting the applications they care about, great, otherwise the source can be dropped and will come back once its upstream or somebody else pick it up and update the code. 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: proposal do disallow syncs of library packages from experimental without approval
2011/10/5 Sebastien Bacher seb...@ubuntu.com: Le mercredi 05 octobre 2011 à 16:08 +0200, Matthias Klose a écrit : During the oneiric development cycle we had syncs of library packages from experimental, introducing new sonames, and changing APIs in a way that other The issue is not really specific to experimental, that could happen the same way with updates done in Ubuntu directly or syncs from unstable. Absolutely. Any extra review process, gatekeeping or whatever we come up with in this discussion should be applied more globally than just syncs/merges from Debian. It's just as (or perhaps even at least as) easy to paint yourself into a corner if you're not going through those channels. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
On Wednesday, October 05, 2011 09:30:22 PM Sebastien Bacher wrote: Le mercredi 05 octobre 2011 à 16:08 +0200, Matthias Klose a écrit : During the oneiric development cycle we had syncs of library packages from experimental, introducing new sonames, and changing APIs in a way that other Hi, The issue is not really specific to experimental, that could happen the same way with updates done in Ubuntu directly or syncs from unstable. While I agree that people who start a transition should have some responsibilities in it I also think that we should be ok with dropping unmaintained code which is not ported at the end of the cycle (and not especially require that whoever started the transition has to be the one that should fix the universe). If we had the resources to both push forward our default installation with the softwares most users care and port the universe it would be great but in really we don't and I think we shouldn't let universe crufts stop use to improve the default experience. To take an example I think porting universe GNOME2 applets to GNOME3 wouldn't be a good use of our time, we better spend the resources we have making sure our current desktop version is great. If some people want to work on porting the applications they care about, great, otherwise the source can be dropped and will come back once its upstream or somebody else pick it up and update the code. I think Gnome2 - Gnome3 is an exceptional case where that is particularly true. In general either all that's needed are rebuilds or digging for patches. I think if we're going to do a transition the developer needs to at least follow through and try to deal with Universe and file bugs where things fail. I don't think just fixing Main and then saying Meh, Univierse, Whatever is appropriate. 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: proposal do disallow syncs of library packages from experimental without approval
2011/10/5 Colin Watson cjwat...@ubuntu.com: I don't want to add extra archive-admin checking to the sync process; firstly, we're moving towards self-service syncs anyway, and secondly, as the libav example shows, syncs aren't really special here. I agree that this shouldn't be an archive-admin job. However, due to the binaries land in the NEW queue (assuming the binary package name is based off of the soname), they seem like a natural *gatekeeper*, even though they might not be the actual *reviewer*. Perhaps some sort of integration (if not directly, then by way of a Greasemonkey script or whatever) between Launchpad's binary NEW queue page and the library transition tracker could help by indicating whether this is an expected, planned transition (i.e. a red warning light if there's no corresponding transition in the transition tracker or something to that effect.)? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
... or LP could talk to the tracker via a web API :P -Rob -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: proposal do disallow syncs of library packages from experimental without approval
Am Mittwoch, den 05.10.2011, 14:35 -0400 schrieb Barry Warsaw: On Oct 05, 2011, at 07:07 PM, Stefano Rivera wrote: The sponsors not requesting testing and a transition effort commitment is something I've noticed too. I see transition sync requests that I don't look at immediately because they'll need a fair amount of review, and 10 mins later someone has gleefully sponsored them because they build successfully. Maybe we need to find ways to flag such potentially troublesome syncs early in the process, so that it's more clear to the developer and/or sponsor. Have we documented a specific set of criteria to watch out for, and can some set of checks for those criteria be automated? Yes, sponsor-patch could compare the old and the new list of binary package. If this list differs, it should ask the sponsoree to confirm this change. -- Benjamin Drung Debian Ubuntu Developer 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: proposal do disallow syncs of library packages from experimental without approval
On Wed, Oct 05, 2011 at 04:17:43PM +0100, Iain Lane wrote: On Wed, Oct 05, 2011 at 03:55:54PM +0100, Colin Watson wrote: […] All three cases have in common that the packages were left alone for months. The third example could have been avoided if we could check build dependencies when syncing, and rejecting the sync when the b-d's are not fulfilled (although there should be an override option). I don't want to add extra archive-admin checking to the sync process; firstly, we're moving towards self-service syncs anyway, and secondly, as the libav example shows, syncs aren't really special here. More discipline for library upgrades would indeed be a good thing. The main problem seems to be library upgrades that don't really have anyone looking after them (and this is worst when it's Ubuntu-local or from Debian experimental; at least in unstable the Debian release team usually cares to some extent). IMO, we should make it clear that if you sync or merge a library from experimental then it is your responsibility to ensure that all reverse-dependencies are ported. Right: if you introduce a SONAME bump (or similar) you should care for it. This cycle the burden has fallen upon those who choose to care for the NBS list, and that's neither fair nor sustainable. Most of these uploads will have to go through binary NEW so that is a good opportunity to check with the uploader that they plan to address the ramifications of the uploads they introduce. I don't think this is something archive admins should be expected to do; it's not in keeping with the other kinds of archive consistency checks they're responsible for. It's also, in a sense, too late - by the time the package hits binary new, the source version is already in the archive, so we have to deal with the transition in one way or another. Like Scott, I think this needs to be the responsibility of the developer starting the transition, and this is true regardless of the origin. I think the point of starting this thread is to get a consensus that this is the right way to handle transitions and to *raise awareness* of the issue, with a particular emphasis on experimental because pulling in a transition from experimental means we effectively have no backing from the Debian maintainers for getting it done in a timely manner (i.e., within an Ubuntu release cycle). So I would be in favor of requiring folks to discuss on ubuntu-devel any proposals for pulling libraries from experimental... in general, but particularly for the LTS. This is certainly not a hypothetical, btw. libevent was synced from experimental to oneiric to support a new version of transmission, and this resulted in a lot of extra work this cycle to fix up the many build failures among the reverse-dependencies - including of honeyd, which is by the *same upstream author* as libevent and had not been ported to the new libevent API (and won't be any time soon). In the end this was resolved by introducing a new source package for the previous upstream version of libevent. We clearly aren't all on the same page today regarding how transitions should be handled in Ubuntu. Hopefully this thread will help us get there. -- 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
