launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Tue, 2011-03-08 at 09:57 +0100, Henning Eggers wrote:
> > Perhaps this is similar to team membership: someone upstream and
> > someone downstream should both agree?
...
> A packaging link is not about agreeing to package a project, though,
> it is
> about stating the fact that it is being packaged. But it should state
> this
> fact correctly. 

This is the key point, thank you Henning. I think there is a
misunderstanding of the issues here, and how packaging links work.

BACKGROUND

The packaging link *was* nothing more than a pointer from a package to a
registered project. Anyone can created and delete them. Last year, we
changed packaging pages to show information from the registered
upstream, such as indicate the branch was imported, or state if the
upstream has a release version that is different from the current
packing release. This year, we want automatically use the packaging link
to sync translations automatically.

Up until this year, when a user makes a mistake, there was no harm,
Someone would notice the mistake when they wanted the code or bug
tracker, and fix it. This year we could have a destructive import of
translations!

We know that upstream and Ubuntu contributors rarely interact in
Launchpad. Upstreams rarely understand packaging. *Upstreams* are
*rarely* qualified to state where and what versions are packaged.

We added a portlet that compares names and descriptions to
packages/projects to suggest to users what to link to. The process was
simplified by removing the PackagingType.INCLUDED relationship and
always selecting to the development series. This did a lot to improve
the quality and quantity of packing links.

THE ISSUE

I delete wrong packaging links every month though. I know they are wrong
because the packaging link is absurd, such as language bind to a lib
claiming to be the lib itself. The user accepted a suggestion without
investigating if the package and project have the same origin. There are
also packaging links claim they provide a package they are in fact a
dependency...I have seen about 5 projects claim to provide Linux.

We also need to consider that about 50% of the bad packaging links are
on new projects. They do not have POTs and POs, they rarely have code,
and the project will probably fail in 6 months.

Is an accidental translation import a disaster? I am certain there will
always be bad links. A good link could become bad if someone changes the
linked branch for example.

SOLUTIONS

1.1 Remove the suggestion portlet from the project page, or only show it
to qualified users (Good luck working that out.)

1.1.1 There was a decline in packaging links shortly after we released
the suggestion portlet. I think all the easy one are done. Most
packaging links are now created using the register an upstream project
link from bugs and package pages. I think package portlet is still doing
some good though because it encourages investigation.

1.2 Remove the links to create packaging from project series pages and
from the projects packaging page. Or only show the create/delete links
to qualified users.

2.1 I do not accept an a suggestion from the portlet without first
looking at the project/package's download/homepage links to ensure they
are the same. This information is embedded in the narrative text of the
package copyright file. This information may not even be set on the
registered project. Maybe the suggestion portlet could show, the
packaging 

2.2 Reject packaging links that conflict with data, such as the source
tree is missing PO/ or the POTs have different names. This may mean
users need to work complete the project information before creating a
packaging link, which will discourage Ubuntu contributors from helping.

3.1 Add a queue to approve packagings links. I personally think that
this would be very bad. Adding procedure and identify who can approve
would be a problem. Well it would for me and a few other people since
packaging links are dominated by a few contributors.

3.2 Add an approval queue for translation imports that have high delta.
If we see the changes are greater than 5%, abort the operation and queue
it.

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

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