Al 05/09/12 17:49, En/na Allison Randal ha escrit: > On 09/04/2012 10:02 AM, Emmet Hikory wrote: >> >> The above notwithstanding, I'm all in favour of being able to safely add >> new or frequently changing packages with policy-compliant filenames to >> Ubuntu, >> both during the life of a release and as part of future releases. I'm just >> concerned that our attempts to work around some of the problems we have had >> with such systems in the past may lead to us creating new systems that >> closely >> parallel older systems without addressing the issues that caused the prior >> systems to no longer be considered ideal for future progress. Given my >> experience with cleanup after the pull of all the random apt repos, and work >> with REVU, I feel fairly strongly that we ought create an implementation that >> closely integrates with exsting Debian tools and avoids as many potential >> sources of conflict as possible. If we are to have a high-throughput mostly >> automated mechanism for new packages to be added, we need to be sure that we >> have not created too many bottlenecks relying on human discussion, whether >> this be too high a reviewer overhead, a need to coordinate yet another >> namespace conflict resolution forum, or anything else. >> >> Based on this belief, while we might have any arbitrary process by which >> applications are submitted for review, the only reason I can see for treating >> the packages as any different than any other unseeded package is either some >> technical limitation or if we somehow felt that we had different levels of >> trust for packages in one place or another (as reflected by our trust in the >> reviewers, presumably). The more effort we spend to create a "special" and >> "different" class of applications, the greater the chance we have created >> a division in the self-perceived identities of our various developers where >> none need exist. >> >> Of course, this may not be considered safe (see all the sandboxing >> discussion in the spec), but I believe we'd do better to help those who >> are developing applications follow a model that generates software that >> we would be happy to welcome as regular system software than to encourage >> those who might need greater system access to find ways to work around >> whatever limitations we might attempt to put in place. If we can use >> the same front-end to the application developers for *both* types of >> applications, we reduce both confusion and dissention, and likely find >> that our implementation need have fewer loopholes, as there is a means >> to easily move software from the restricted facility to a more regular >> facility, with full filesytem access, no network restrictions, etc. >> which we may use whenever we find a package that might otherwise require >> an extension to the facilities available. > > Well said! > > Here's my perspective, in short form: > > - Extras is PPU + Backports + training wheels. > > - Extras is a place to experiment with how the training wheels should > work, without disrupting the main archives. > > - Eventually Extras should go away, once we've extracted the best value > from the experiment. >
I personally don't feel strongly about which location third party apps are distributed from, be it in Extras or somewhere else, but I can see the benefits of having a separate archive that does not disrupt the main one. That said, there is one part where I disagree: in considering Extras (if we identify Extras with the App Developer Process) an experiment or training ground for Ubuntu platform development, for which we already have a process in place. I consider the App Developer Process simply a way to enable application authors to seamlessly and securely publish their apps. Human review and packaging policies have proven to be the main bottlenecks for this happening, and these (plus security) are the main points the proposal is trying to address. > The proposal that started this thread is rather lengthy, and contains > 2-3 years worth of work on tooling. Indeed, and work that will benefit the distro too, such as sandboxing. > It's a valuable seed for discussion, > but really too much to digest all at once. I'd like to focus on what to > do in the next Ubuntu release cycle. Partly because each cycle *is* a > fresh experiment for Extras. I think we've got different views on this: I believe considering each cycle as an experiment will not bring us to the end goal. The fact that it will take some cycles to implement such a spec simply means that when agreed upon, the work will be divided and scoped into cycles, so this is also about focusing on what to do in the next Ubuntu release cycle. > What we've learned in previous cycles has > radically changed the plan already, and is sure to do so in the future. > And partly because we may not agree right now on the ultimate future > (some won't agree with me that Extras should go away, others won't agree > with me that it should stick around for a little while longer), but I'm > confident that we *can* agree on what the immediate next steps should be. > > These are what I consider to be the most crucial immediate questions: > > - Should we change Extras operation so it's less like REVU (approving > each package) and more like PPU (approving a particular developer for a > particular package name)? > My vote, as contemplated in the spec, would be to use the PPU model, with one or more developers having upload rights for a package. > - Should the DMB be made responsible for approving those Extras PPU rights? > We have not yet expanded on which particular board would take care of the human review component, which in any case would be reduced to the minimum: identity checking. The main requirement would be that the team of individuals are committed to doing the reviews and are responsive. > - Should we remove the /opt install requirement? > +1, for all the reasons already mentioned in the discussion. From the previous replies on the thread, it seems to me we've all already agreed on this one. > - Should we start developing tooling for more automated package > checking/sandboxing? > Absolutely! :-) > My vote is: Yes, make it more like a PPU. I see advantages to recruiting > the DMB for approvals, but they may not want the extra work. No, we > shouldn't remove the /opt requirement, at least not yet. Maybe later > when we have more advanced tools. And heck yeah!, we should start > working on the tools. We can keep doing manual reviews until the tools > are good enough that we trust them. (And will always make the tools kick > back to manual review for anything they can't handle.) > > > My ideal future looks something like: Debian and Ubuntu co-habiting on > DebExpo (either on mentors.debian.net, or two sites with federated > data), with a slick UI, and fantastic integrated tools for automated > package checks. But, there's a lot of development work between here and > there, I can't just snap my fingers and make it happen tomorrow. > Yeah, I'd like to have some magic finger snapping making it happen, but then that'd take the fun in we working to make it happen! :-) Thanks a lot for the input, also the one you provided during the drafting of the spec as well. Cheers, David.
signature.asc
Description: OpenPGP digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
