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/
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
