launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

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
> translations).

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
> 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.

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
> 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.

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
> 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
> >             else:
> >                 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.

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
years ago.

-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part