Re: Opening backports pre-release
On Thu, Nov 17, 2011 at 7:05 PM, Evan Broder wrote: > On Wed, Nov 2, 2011 at 2:11 PM, Evan Broder wrote: >> - Component isolation. All packages in the backports pocket build >> with all components enabled. This means that if we copy binaries to >> x+1, we could be copying binaries built against packages from the >> wrong component. It might make sense to only pocket copy source >> packages into the x+1 release, instead of all packages. [...] > * When the next release is opened for development, pre-release > backports will be re-uploaded to the new release with their version > number bumped for a rebuild (i.e. there will be no direct source or > binary pocket copies) Would the TB be OK with relaxing the requirement to implement component isolation on the backports pocket? I feel like it's not actually necessary given that we'll be rebuilding packages, so we'll catch problems from component mismatches quickly at the start of the release cycle. But on the flip side, it reduces the amount of work necessary to backport packages that are affected by component mismatches, which has always been the intent with backports. - Evan -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: Opening backports pre-release
On Thu, Nov 17, 2011 at 07:05:53PM -0800, Evan Broder wrote: > On Wed, Nov 2, 2011 at 2:11 PM, Evan Broder wrote: > > - Archive admin workload. All backports currently require some action > > from archive admins. For no-source-change uploads, an archive admin > > runs a script on the archive master. For source-change uploads, > > because they are uploaded post-release, they are automatically put > > into the unapproved queue. Additionally, new packages have to go > > through sourceNEW and binNEW. Our proposal would create additional > > work for the archive admins near release time, which may be > > problematic. > > > > - Upload privileges. I believe that currently anybody on ~ubuntu-dev > > can upload any package to the backports pocket, and backporters can > > approve backports of packages they otherwise would not be able to > > upload. The backports team would prefer to maintain that - would it be > > sufficient to ensure that manual backports uploads always go through > > unapproved? [...] > * Privileges to upload source-change backports will be changed to > match the rest of the archive, as opposed to the current configuration > where any member of MOTU or Core Dev can upload any package. However, > all uploads would still require approval from ubuntu-backporters. We talked about this a bit in #ubuntu-motu today. The background is that I'm intending to get rid of all cases where archive administration work requires sshing to ftpmaster (https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-replace-archive-admin-shell-access) and backporting is one of these things. The obvious answer is to simply use backportpackage and sign and upload the results. There are two ways this might work: (1) We could adapt the archive admin scripts that process backport request bugs to run backportpackage, and then we'd sign and upload the results. (2) ubuntu-backporters could run backportpackage directly and sign and upload the results themselves. Once backporters have queue admin privileges for the backports pocket (as I explained in the 2011-11-17 meeting), I favour the second option, on the basis that my understanding of the TB consensus position here is that we trust ubuntu-backporters to manage the backports pocket sensibly. However, Evan pointed out that this contradicts the position as written up above, so I'd like to lay out the specifics a bit and make sure we're all in agreement. Firstly, there's a premise above that turns out not to be true: "as opposed to the current configuration where any member of MOTU or Core Dev can upload any package". I've verified by code inspection, and Iain Lane has verified by experiment, that a developer who is a member of MOTU but not a core developer cannot upload a package in main to the backports pocket. Secondly, I think it's bizarre in general to have a position where somebody can approve an action but not perform it themselves (aside from social requirements for peer-review and the like, which aren't really the same thing). We've agreed that we're going to aim for backporters being able to administer queues for the backports pocket, so I think it's clear that they should be able to upload to it directly as well. Therefore, I believe that the ACLs should be as follows: * Uploads to all pockets: ~ubuntu-core-dev for all components, ~motu for universe/multiverse, teams for package sets, etc. (unchanged) * Uploads to backports pocket: ~ubuntu-backporters (new) * Possibly other new ACLs for teams such as ~ubuntu-security, ideally replacing current hardcoded hacks in LP Iain has filed https://bugs.launchpad.net/launchpad/+bug/914779 for this. Does the TB think this is OK? Option (1) is a reasonable fallback for the moment that still allows us to reduce our dependency on shell access to ftpmaster (in fact, this should allow us to drop our sudo access to lp_queue in the near future). It's worth noting, though, that this will only work for archive admins who are also core developers, and it still leaves archive admins rubber-stamping the work done by backporters, often with a delay, rather than just letting them do it themselves. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
Re: Opening backports pre-release
On Wed, Nov 2, 2011 at 2:11 PM, Evan Broder wrote: > Greetings, Tech Board - > The backports team has been playing with a proposal for about a year > now that we'd like to finally submit to you folks. > > Currently, during the period between FeatureFreeze and release (about > 1/3 of the cycle!), it's impossible to upload either new packages or > new features to Ubuntu (freeze exceptions excluded). Post-release, > this is an issue already addressed by the backports process. We'd like > to propose extending the use of backports by opening the backports > pocket for uploads and Debian syncs at FeatureFreeze, and then copying > the contents of the backports pocket to the x+1 release when it opens, > similar to what we do already for SRUs. > > We would still enforce the current backports requirements (the package > must "build, install, and run", any reverse-dependencies must still > work with the new package, and all uploads must be approved by a > backporter). These requirements are stronger than those for general > archive uploads, so we don't believe that there is significant risk to > post-release archive quality of x+1. > > I see a handful of potential issues with this, and I only have answers > for some of them, so if the TB is generally interested in the idea, > I'd certainly appreciate feedback and suggestions: > > - Skew between backports (and therefore x+1) and the main archive: > bugfixes in release not making it into backports, versions in release > superseding those in backports, etc. In general, I think we would want > a mechanism to invalidate packages in the backports pocket whenever > that package is uploaded to the release pocket, and possibly to the > proposed pocket, though I don't know what that is. > > - Archive admin workload. All backports currently require some action > from archive admins. For no-source-change uploads, an archive admin > runs a script on the archive master. For source-change uploads, > because they are uploaded post-release, they are automatically put > into the unapproved queue. Additionally, new packages have to go > through sourceNEW and binNEW. Our proposal would create additional > work for the archive admins near release time, which may be > problematic. > > - Upload privileges. I believe that currently anybody on ~ubuntu-dev > can upload any package to the backports pocket, and backporters can > approve backports of packages they otherwise would not be able to > upload. The backports team would prefer to maintain that - would it be > sufficient to ensure that manual backports uploads always go through > unapproved? > > - Component isolation. All packages in the backports pocket build > with all components enabled. This means that if we copy binaries to > x+1, we could be copying binaries built against packages from the > wrong component. It might make sense to only pocket copy source > packages into the x+1 release, instead of all packages. > > If the TB approves this, the backports team would gladly take > responsibility for proposing patches to Launchpad, ubuntu-dev-tools, > ubuntu-archive-tools, and anything else we've forgotten that needs > modification to support the new workflow. > > I know this is rather late notice, but I'll go ahead and add this to > tomorrow's meeting agenda in the hopes that there's time to discuss > it. I'm also generally available for in-person or IRC discussion. Hello everybody - We discussed this during today's TB meeting. Thanks to Stephane, Colin, and Martin for their input on our ideas. I believe that this represents the changes to my original proposal that were suggested today: * In order to be sure that the packages in -backports remain in sync with -release, the backports team will develop a bot to file bugs against the backports project when a package already in -backports is uploaded to a non-backports pocket. For now, the backports team will be responsible for merging these changes when necessary (though we would obviously welcome collaboration from whoever actually did the upload) * Souce-change uploads to the -backports pocket will continue to land in the UNAPPROVED queue. * Privileges to upload source-change backports will be changed to match the rest of the archive, as opposed to the current configuration where any member of MOTU or Core Dev can upload any package. However, all uploads would still require approval from ubuntu-backporters. * When the next release is opened for development, pre-release backports will be re-uploaded to the new release with their version number bumped for a rebuild (i.e. there will be no direct source or binary pocket copies) * Somewhat tangentially, Launchpad should ideally be modified to allow sufficient granularity of queue control that the backports team could be given permission to accept packages from the UNAPPROVED queue for backports pocket uploads. Bug #648611 is already scheduled for escalation due to release team's requirements, but I've also mentioned the
Opening backports pre-release
Greetings, Tech Board - The backports team has been playing with a proposal for about a year now that we'd like to finally submit to you folks. Currently, during the period between FeatureFreeze and release (about 1/3 of the cycle!), it's impossible to upload either new packages or new features to Ubuntu (freeze exceptions excluded). Post-release, this is an issue already addressed by the backports process. We'd like to propose extending the use of backports by opening the backports pocket for uploads and Debian syncs at FeatureFreeze, and then copying the contents of the backports pocket to the x+1 release when it opens, similar to what we do already for SRUs. We would still enforce the current backports requirements (the package must "build, install, and run", any reverse-dependencies must still work with the new package, and all uploads must be approved by a backporter). These requirements are stronger than those for general archive uploads, so we don't believe that there is significant risk to post-release archive quality of x+1. I see a handful of potential issues with this, and I only have answers for some of them, so if the TB is generally interested in the idea, I'd certainly appreciate feedback and suggestions: - Skew between backports (and therefore x+1) and the main archive: bugfixes in release not making it into backports, versions in release superseding those in backports, etc. In general, I think we would want a mechanism to invalidate packages in the backports pocket whenever that package is uploaded to the release pocket, and possibly to the proposed pocket, though I don't know what that is. - Archive admin workload. All backports currently require some action from archive admins. For no-source-change uploads, an archive admin runs a script on the archive master. For source-change uploads, because they are uploaded post-release, they are automatically put into the unapproved queue. Additionally, new packages have to go through sourceNEW and binNEW. Our proposal would create additional work for the archive admins near release time, which may be problematic. - Upload privileges. I believe that currently anybody on ~ubuntu-dev can upload any package to the backports pocket, and backporters can approve backports of packages they otherwise would not be able to upload. The backports team would prefer to maintain that - would it be sufficient to ensure that manual backports uploads always go through unapproved? - Component isolation. All packages in the backports pocket build with all components enabled. This means that if we copy binaries to x+1, we could be copying binaries built against packages from the wrong component. It might make sense to only pocket copy source packages into the x+1 release, instead of all packages. If the TB approves this, the backports team would gladly take responsibility for proposing patches to Launchpad, ubuntu-dev-tools, ubuntu-archive-tools, and anything else we've forgotten that needs modification to support the new workflow. I know this is rather late notice, but I'll go ahead and add this to tomorrow's meeting agenda in the hopes that there's time to discuss it. I'm also generally available for in-person or IRC discussion. Thanks, -- ubuntu-backports mailing list ubuntu-backports@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
