launchpad-dev team mailing list archive
Mailing list archive
Re: RFC Changing permissions to allow contributors to set upstream information
У уто, 02. 03 2010. у 13:33 -0500, Curtis Hovey пише:
> Allowing contributors to set upstream information
> A common issue that blocks an Ubuntu contributor or knowledgeable user
> from providing information that communities need to know about a project
> is permissions. While we understand that a project is shared by many
> communities, we have made a single person or team the project owner, and
> this person often represents one community. Project owners are often
> absent or do not provide the information needed by other communities to
> contribute to the upstream project.
> I want to change the permission rules for several project and series
> attributes to enable contributors to provide the missing information. This
> information pertains to Bugs, Branches, and Translations. I want to know
> your opinions and concerns about these changes.
> I'll be happy to drop aspects of this work if the respective team thinks
> the idea is bad, or the solution requires a different approach.
Thanks for working on this: it's very much appreciated!
> Branches: series branch
> Contributors want to know the branch that a source package comes from. This
> information is controlled by the series release manager or project owner.
> Changes were made recently to allow some celebrity teams to make the change
> when users asks a Question in the Launchpad project. I want to change the
> rules to permit any user to set the branch for a series that has no branch. If
> the project is owned by Registry Admins, I want to permit any user to update
> the branch attribute.
+1 Basically, we want to have a concept of "imported" project, and
perhaps having Registry Admins own it is a good indicator of such.
I think we are going to run into a lot of complications when we start
considering LP hosted projects where they are using only some bits of
LP, yet other users want to use others as well (eg. branches and/or
> Translations: enable imports
> Only project owners can enable Launchpad Translations and setup automatic
> imports/exports from a branch. This may be a contributing reason for the
> many duplicate translation projects that are registered by users.
There are also privileges: just setting up a translations import won't
allow people to translate that.
> I want to permit any user to enable imports from the series branch that is
> also linked to a source package.
Is there a reason to limit it like this? My take would be similar to
above: for any Registry-owned project, anyone can set it up. For
projects with branches and unset translations, anyone can set it up.
Perhaps the second condition should also take the existence of a link to
a sourcepackage as well.
> I want this to be visible to the series
> release manager because I think he will be more willing to except exports
> to he branch if he knew another community was helping him.
Considering how we don't want to allow anyone to translate in LP once
translations are imported, allowing export is not going to be of much
use: whatever is imported would be exported as well.
> This may require
> users to enable Launchpad Translations, but I think the project's use of
> Translations is separate from Ubuntu desire to get the latest Translations.
At the moment, it's perfectly possible to set up translations import
from a branch without "enabling" Launchpad Translations. And for the
benefits we are expecting in Ubuntu, that's just about enough.
> Implementation notes
> I think the proposed permission rules imply the return of the despicable
> EditPersonLocation-style permission checker...
> class EditProductSomething(EditByOwnersOrAdmins):
> permission = 'launchpad.EditSomething'
> usedfor = IProduct
> def checkAuthenticated(self, user):
> """Anybody can edit something if it is not set."""
> something = self.obj.something
> if something is None:
> return True
> return super(EditProductSomething, self).checkAuthenticated(user)
> ...and the setup of some unique views to isolate this kind of change.
> Since we are striving to remove the exceptional permission names, this whole
> category of needs a name and story that is easy to test when we want to
> reuse the permission name. We have a few cases of launchpad.append, but I
> do not think that is this case. I also discount launchpad.moderate.
> This looks like a launchpad.Propose, or launchpad.Suggest.
> I have some reservation about this whole proposal--users cannot fix their
> mistakes. This will lead to requests to other users to fix the data, and lead
> to bug reports just like the reports to edit/delete comments.
We may need to start thinking about "report this" functionality in LP.
Seeing how crowd-sourcing is critical to the success of our bridging the
gap goal, I think it should be a cross-team effort to nail it down.
It's not going to make it easy for users to fix their mistakes, but it
will at least make it easy for them to report them.
Or alternatively, we can start decorating objects with
"just_an_import=True" and allowing changes by anyone with sufficient
karma/standing on such objects (branches, translation set-ups, project