Re: Strawman: merge main and universe
Scott James Remnant wrote: The distinction between main and restricted is done based on licensing: software in main fulfils the necessary freedoms for modification and redistribution, software in restricted may not. [snip] I therefore propose an alternative. We move all packages from universe into main, and remove the universe component. Likewise packages from multiverse are moved into restricted, and multiverse removed. Instead, we define who provides what kind of support through meta-data. I think separately-maintained metadata is the right way to solve the problem of "what are we communicating about package X". Even components fail to communicate tricky things like the difference in maintenance windows for desktop and server on an LTS release - gnome-gpg is in main, and apache is in main, but they are "formally maintained" for different lengths of time, and there's no way to have the system generate a report of that for you. Metadata, published separately and used by the full set of apps that need to communicate this to the end-user, would be a good solution. [snip] What about upload privileges? Let's do those the same way. -1, and loudly. I do think we need a richer privileges system for upload - we specifically need to solve the problem that people who care about a package in universe don't lose the ability to tend to it when it moves to main. But that should be the exception, rather than the rule. In other words, I would layer explicit additional permissions for packages, and (small) sets of packages, on top of our existing main/universe permissions. That way, when a package, or small set of tightly-linked packages, wants to migrate from universe to main, it can come with a dedicated group who can continue to upload to it even though it's in main. I don't want to see a general move to seed-based permissioning, because while the seeds themselves are relatively stable, their dependencies can flap all over the show, and I don't want to have to try to resolve those issues, nor do I want people to have any incentive to define dependencies to achieve ulterior policy goals. Mark -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Strawman: merge main and universe
On Wed, Dec 12, 2007 at 10:24:56PM +, Scott James Remnant wrote: > The distinction between main and universe is instead done based on > "support". But what does this actually mean? Our terminology on this needs a bit of cleanup, but the relevant distinction here is "maintenance". This means that, for example, a security vulnerability in the package will be fixed, and this is backed up by a commitment from Canonical (which has dedicated resources to this maintenance). > What about support for fixing bugs? We actually don't like to do that > very much, we only have limited updates to our stable release. This > surprises most people who think this is what support means. We do need to do a better job of both communicating our maintenance practices and ensuring that they meet expectations. There is work in progress to change this for 8.04 LTS. > We move all packages from universe into main, and remove the universe > component. Likewise packages from multiverse are moved into restricted, > and multiverse removed. > > Instead, we define who provides what kind of support through meta-data. > > We have generated lists of packages already, the seeds. In fact, it's > these seeds that (by a manual process) result in packages being divided > between main and universe right now. > > So let's just use these to determine the types of support provided. This seems sensible to me; Debian-style components are unwieldy to work with, as they are closely tied to the way the archive is published. We should be able to change a declaration of maintenance without moving files around on a web server, and the placement of the files isn't a very good way of communicating this information. > Canonical can declare that it provides commercial support for the > ubuntu-desktop, ubuntu-server, ubuntu-mobile and kubuntu-desktop seeds > (and any others we support that I forgot). It can also declare what > date that support ends. > > Other companies and groups can declare their own support based on the > existing seeds, or just branch the bzr repository and make their own > (the seeds are public, and the tool to generate complete package lists > is also public). > > The Ubuntu Security team can declare which seeds they provide security > support for at which levels. All reasonable. > The packaging tools can then use this information to show appropriate > information to the user; they'll know the package they are installing is > supported for a further 12 months by Canonical, a further 18 months by > another company or group; Security support is provided by the Ubuntu > security team for 12 months and critical bug fixes are no longer > provided. This is tricky. In order to be effective, this needs to be communicated all the way from apt-cache up through gnome-app-install in a reasonably consistent way. > What about upload privileges? > > Let's do those the same way. Sounds elegant enough, though I wonder about automatically granting upload privileges based on a new dependency. -- - mdz -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Strawman: merge main and universe
Scott James Remnant schrieb: > I'd like to make a strawman proposal to be torn apart and burnt as > necessary: merge main and universe. I will try and explain my > rationale, and my alternate proposal. +1 We apparently have difficulties to communicate that this separation was done only for the support case mentioned. two examples for "universe not being ubuntu": - distrowatch.com treats universe as non-existant (I contacted them, but they didn't want to change their mind). - Fedora did get good feedback by integrating "extras" into "core"; while not directly comparable you can see the some impact on integrating the community. Matthias -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Strawman: merge main and universe
I'd like to make a strawman proposal to be torn apart and burnt as necessary: merge main and universe. I will try and explain my rationale, and my alternate proposal. (I'm subscribed to all of the mailing lists I'm posting to, please don't Cc me if you're following up to one of them) The distinction between main and restricted is done based on licensing: software in main fulfils the necessary freedoms for modification and redistribution, software in restricted may not. It is simple to pick a component for the software, you simply read the licence. It also makes sense for the components to be separate since it allows users (and derivatives) to make a decision not to accept software under restricted licence conditions. The distinction between main and universe is instead done based on "support". But what does this actually mean? Canonical provides commercial support for all packages in main. Well, that's not actually true: we don't provide commercial support for them all. More than that, this needlessly emphasises Canonical in the Ubuntu community. Why can't another company or group provide support? Why doesn't members of MOTU supporting the package mean it can move to main? What about support for fixing bugs? We actually don't like to do that very much, we only have limited updates to our stable release. This surprises most people who think this is what support means. Security support is another angle to take; and another bucket of worms. So the distinction is actually quite blurry. Perhaps the separation still makes sense for user choice? I don't this is true either. We used to have only main and restricted enabled by default, users had to deliberately enable universe to get the software from it. Some time ago we changed this to instead be handled through the user interface, declaring whether or not you'd receive this strange "support" for the package or not. And this still doesn't cover the fact that in just a few months time, there will be a LOT of packages in the "main" component of a "supported" release (dapper) that won't be "supported" anymore. I therefore propose an alternative. We move all packages from universe into main, and remove the universe component. Likewise packages from multiverse are moved into restricted, and multiverse removed. Instead, we define who provides what kind of support through meta-data. We have generated lists of packages already, the seeds. In fact, it's these seeds that (by a manual process) result in packages being divided between main and universe right now. So let's just use these to determine the types of support provided. Canonical can declare that it provides commercial support for the ubuntu-desktop, ubuntu-server, ubuntu-mobile and kubuntu-desktop seeds (and any others we support that I forgot). It can also declare what date that support ends. Other companies and groups can declare their own support based on the existing seeds, or just branch the bzr repository and make their own (the seeds are public, and the tool to generate complete package lists is also public). The Ubuntu Security team can declare which seeds they provide security support for at which levels. The packaging tools can then use this information to show appropriate information to the user; they'll know the package they are installing is supported for a further 12 months by Canonical, a further 18 months by another company or group; Security support is provided by the Ubuntu security team for 12 months and critical bug fixes are no longer provided. What about upload privileges? Let's do those the same way. Teams can approach the Technical Board for permission to own a particular seed; if granted, their team has permission to upload any package in the resulting list of packages from that seed. (The seed system already has priorities, so you couldn't add a package in ubuntu-desktop and take it over; at least, not without negotiation.) The kubuntu-dev team could maintain (and support, etc.) Kubuntu. xubuntu-dev could do the same for Xubuntu, and so on. To become an uploader for Kubuntu, you would need to be granted permission from that team, not from the Technical Board. That team is better placed to judge your skills anyway. We'd still need the existing two teams: ubuntu-core-dev would have permission to upload to everything. It would remain the ultimate accolade technical team, and membership would be available to anyone who has excelled in ubuntu-dev, which would have permission to upload to anything not seeded, and would be members of most of the other technical teams as well. This is where you would graduate to after being a member of a specific team. Like I said, it's a straw man. Please debate, discuss, argue, but don't flame :-) Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings o
