launchpad-dev team mailing list archive
Mailing list archive
Re: RFC Changing permissions to allow contributors to set upstream information
On Thu, 2010-03-04 at 18:20 +0100, Danilo Šegan wrote:
> > Branches: series branch
> > -----------------------
> +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
Indeed. This is the reason why Edwin's proposal to change the
Involvement portlet is confusing. Most people think of Launchpad as a
project hosting service. I think it is better to think of Launchpad are
a community hosting service. Projects are where communities often
intersect and they must share.
I have considered the case where the project does use Launchpad for
hosting. If conflicts over series cannot be reconciled, I would allow
anyone to create a series instead of the projects drivers. This will
allow communities to work in parallel. This also invited forking which
may be a false understanding since branches are also forks.
> > Translations: enable imports
> > ----------------------------
> > 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 was thinking the users would have link to a source package first, but
I think your suggestion is best. I think this will also reduce the
number of users who want to import a project instead of translating the
project already in Launchpad.
> > I want this to be visible to the series
> > release manager because I think he will be more willing to except
> > 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.
I do not understand this point.
> > 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
> 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.
Ah! I was looking at the project, not the series. Okay, This is good. I
can see I can do this for my projects, Registry Administrators, and
projects owned by other users. This does not need a permission change,
it just needs to made more prominent--this path requires knowledge.
https://launchpad.net/ubuntu/lucid/+source/gedit > gedit HEAD series
https://launchpad.net/gedit/head > Translations
https://translations.launchpad.net/gedit/head > Set up branch synchronization
> > Implementation notes
> > ....................
> > I think the proposed permission rules imply the return of the
> > 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
> > else:
> > return super(EditProductSomething,
> > ...and the setup of some unique views to isolate this kind of
> > 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
> > 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
> > 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
> gap goal, I think it should be a cross-team effort to nail it down.
I would like to avoid this. We get feedback@ email and questions about
bug trackers because Launchpad hides bug tracker registration and does
not permit the user to set this information. This is also wrong because
the email/question should go to the project maintainers, not us.
> 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.
We have this problem now in bugs and answers. Bugs has a better history
so the teams can fix other user's mistakes. Questions is hard since
retargeting and assignees are not in history.
> 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
> properties, etc.).
I think you are right. I think a good crowd sourcing implementation
requires us to complete standing. I wonder if I would need to be
scanning Launchpad for spam every day if we had complete standing two
__Curtis C. Hovey_________
Description: This is a digitally signed message part