Diff for "VersionFourDotO/Stakeholders/Soyuz"

Not logged in - Log In / Register
Differences between revisions 3 and 5 (spanning 2 versions)
⇤ ← Revision 3 as of 2009-09-01 12:23:19 →
Size: 5837
Editor: julian-edwards
Comment:
← Revision 5 as of 2009-09-23 17:54:37 → ⇥
Size: 2356
Editor: julian-edwards
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

== Mark Shuttleworth ==
 * 1
 * 2
 * 3
Line 10: Line 5:
 * 1
 * 2
 * 3
 1. '''LP: #391820 Optionally strip translations in PPAs.'''
 We need a robust way to handle translations for our builds. Stripping translations + custom language packs are a couple things that have been discussed. The basic problem is that we need to strip translations from packages we rebuild, so that we can take advantage of distro's translations for that package. In some cases we have new translations (done by a third party) that we want to integrate in addition to or in place of distro's translations.

 2. '''All projects in a single pool''' as this imposes an important constraint that will prevent projects from having packages with the same version but different changes.
  * This would require the ability to have custom suite names like we do now. Creation and management of new suites should be managed via API. Its also important to note that lp should not assume all the suites belong to a single linear series.
  * It would be useful to have per suite http authentication credentials that would only grant access to the packages in the suite. This would allow us to give access to customers that is appropriately restricted to packages that are common and that belong to their project.

 3. '''Custom incoming queue processing.''' The idea here is that we can optionally have all uploads for a project held in an 'incoming queue' that requires an individual with the necessary permissions to accept or reject. The primary purpose of this would be to allow us to run our scripts that currently get run via the reprepro hook functionality by polling the queue. The second purpose would be to allow the tech lead to freeze their project and approve uploads and copies that are critical to the release, reject what he or she wants, and leave everything else waiting in this queue until the freeze is over.


And lastly, a blue-sky request: Installer-building support, for creating
customized versions of Ubuntu based on a distribution and one or more PPAs.
You'll recall that we discussed this at SomeHands '09:
https://wiki.canonical.com/AllHands/2009/SomeHands/CustomizingUbuntu
Line 25: Line 32:


== Suggestions ==
The following are bugs and ideas for improvement collected over the last cycle.
|| Item || Story Points || Description ||
|| PPA download counters || || Enable the distro team to prioritise merges from PPAs based on real usage and popularity and testing ||
|| SoyuzDistributionScript || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#soyuz-distribution-script|3]] || Re-write cron.publish in Python ||
|| Provide support for package sync reviews|| [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#package-sync-reviews|13]] ||Consider how critical uploads, bugs, the upload queue and PPAs can interact ||
|| Licensing Metadata support (see [[http://wiki.debian.org/Proposals/CopyrightFormat|1]] and [[http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License:_field|2]] || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#licensing-metadata|2]] || Extra data on SPR that specifies the set of licenses for a package; obtained by parsing the licensing description and creating a set) ||
|| Changelog repackaging for native source syncing || || Allows us to store proper changelogs for Debian-NSS'd packages ||
|| Fix changelog attribution and repackaging for native source syncing || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#changelogs|5]] || [[https://bugs.edge.launchpad.net/soyuz/+bug/55795|55795]], [[https://bugs.edge.launchpad.net/soyuz/+bug/139162|139162]], [[https://bugs.edge.launchpad.net/soyuz/+bug/247456|247456]] ||
|| Support zsync/pdiff for apt-get update || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#pdiff|XXX]] || [[https://bugs.launchpad.net/bugs/214612|214612]] ||
|| Pool buildds between PPAs and the distro || [[https://dev.launchpad.net/VersionThreeDot0/Soyuz/StoryCards#pool-builders|3]] || [[https://bugs.edge.launchpad.net/soyuz/+bug/285207|285207]] ||
|| Make buildmaster work with buildds that build any arch || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#any-arch-builder|13]] || [[https://bugs.edge.launchpad.net/soyuz/+bug/285206|285206]] ||
|| Display PPA diffs against Ubuntu || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#ppa-diffs-ubuntu|5]] || [[https://bugs.edge.launchpad.net/soyuz/+bug/259422|259422]] ||
|| Multi-series support in package uploads || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#multi-series-upload|8]] || [[https://bugs.edge.launchpad.net/soyuz/+bug/235064|235064]] ||
|| PPA popularity index || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#ppa-heat|5]] || Do an emergent "heat" on PPA's, which would quietly factor in downloads, subscribers, karma of uploaders etc. ||
|| SFTP package uploads || 5 || Provide a secure upload mechanism with synchronous feedback to uploaders; GPG still a requirement ||
|| Per-package apt:// download links.|| || ||
|| NoMoreAptFtpArchive || 8 || (package metadata, speeds up publishing by 20m) ||
|| RealDistroReleases || || Point-releases for distributions ||
|| Archive from librarian || 20 || Dynamic pool and autogenerated dists ||
|| Archive Branches, Snapshot Archives and Independent Suites || 13 || (could we have hardy-intel?) If done with ''Diskless Archives'' makes archive branching cheap ||
|| Upload RSS feed || || [[https://blueprints.edge.launchpad.net/soyuz/+spec/upload-rss-feed|Bluprint]] ||
|| LiveFS generation || || ||
|| Branch uploads || || https://edge.launchpad.net/bzr-builddeb, data model, branch uploads ||
|| Modelling seeds || 6 || Data model and basic germinate interface. Could be done with 'NoMoreAptFtpArchive' which needs to know about seeds ||
|| Package copying only shows first 20 packages || || bug 276019 ||
|| [[https://bugs.edge.launchpad.net/soyuz/+bug/236922|Current SourcePackage metadata persistence]] || 5 || Internal-only, performance and correctness, enables per-package features ||
|| Hang BPPH off SPPH || || ||
|| [[https://bugs.edge.launchpad.net/soyuz/+bug/236925|Explicit Distribution.currentseries]] || || Internal-only, perf and correctness ||
|| Remove Lucille config || || [[https://bugs.edge.launchpad.net/soyuz/+bug/55288|Bug 55288]] and [[https://bugs.edge.launchpad.net/soyuz/+bug/45270|bug 45270]]. Fix the publisher configuration system; get rid of the Lucille config stuff and prevent the publisher from failing when a new series is opened but is not initialised. Also see the [[https://blueprints.edge.launchpad.net/soyuz/+spec/remove-lucilleconfig|blueprint]] ||
|| AJAX +builds || || Sex up the /+builds pages with AJAX: Allow in-place re-try (including multiple arches), make failures more obvious, in-place rescoring, filter on series/arch/status. ||
|| AJAX +queue || || Add AJAX to the +queue page: approve all, in-place approval, remove actions where not permissioned, possibly lots more usability optimisations. ||
|| Soyuz instant messenger buddy (XMPP) || [[https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#xmpp|XXX]] || [[https://bugs.edge.launchpad.net/soyuz/+bug/305331|305331]] For notifications of important events like build failures. Probably not limited to Soyuz ||
|| Rebuilds of binary packages without source changes || || [[https://bugs.edge.launchpad.net/soyuz/+bug/245594|bug 245594]] (required for bug 235064)||
|| PPA deletion || || [[https://bugs.edge.launchpad.net/soyuz/+bug/391807|We need a way of deleting unwanted PPAs.]] ||
|| PPA Mirroring || || [[https://bugs.launchpad.net/soyuz/+bug/396488|bug 396488]] ||

Soyuz 4.0 stakeholder priorities

OEM Services

Contact: Cody Somerville

  1. LP: #391820 Optionally strip translations in PPAs. We need a robust way to handle translations for our builds. Stripping translations + custom language packs are a couple things that have been discussed. The basic problem is that we need to strip translations from packages we rebuild, so that we can take advantage of distro's translations for that package. In some cases we have new translations (done by a third party) that we want to integrate in addition to or in place of distro's translations.

  2. All projects in a single pool as this imposes an important constraint that will prevent projects from having packages with the same version but different changes.

    • This would require the ability to have custom suite names like we do now. Creation and management of new suites should be managed via API. Its also important to note that lp should not assume all the suites belong to a single linear series.
    • It would be useful to have per suite http authentication credentials that would only grant access to the packages in the suite. This would allow us to give access to customers that is appropriately restricted to packages that are common and that belong to their project.

  3. Custom incoming queue processing. The idea here is that we can optionally have all uploads for a project held in an 'incoming queue' that requires an individual with the necessary permissions to accept or reject. The primary purpose of this would be to allow us to run our scripts that currently get run via the reprepro hook functionality by polling the queue. The second purpose would be to allow the tech lead to freeze their project and approve uploads and copies that are critical to the release, reject what he or she wants, and leave everything else waiting in this queue until the freeze is over.

And lastly, a blue-sky request: Installer-building support, for creating customized versions of Ubuntu based on a distribution and one or more PPAs. You'll recall that we discussed this at SomeHands '09: https://wiki.canonical.com/AllHands/2009/SomeHands/CustomizingUbuntu

Ubuntu Foundations

Contact: Colin Watson / Robbie Williamson

  • 1
  • 2
  • 3

Ubuntu MOTU

Contact: wgrant and mok0

  • 1
  • 2
  • 3

VersionFourDotO/Stakeholders/Soyuz (last edited 2010-01-05 07:50:34 by jml)