launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01642
Re: Getting upstream's trunk code for a package, and data and so forth
Hi Jono.
Thanks for working on these queries. I had written something similar,
but I think your concrete examination of main is better than my effort.
I have been looking at linking in two ways, but have produced nothing
concrete. Since I have looked at this for two days, I think it is best
that I publish my notes and get the input of others.
On Sun, 2009-11-15 at 23:56 -0600, Jonathan Lange wrote:
> For those who are interested, the numbers for Lucid are:
> - Packages in main: 16143
> - Packages in main w/ upstream links: 16
> - Packages in main w/ upstream links w/ branches: 9
> - Packages in main w/ upstream links w/ products that have trunk
> branches: 9
> - Packages that have upstream links that have trunk branches that
> work: 9
>
> The numbers for karmic:
> - Packages in main: 16217
> - Packages in main w/ upstream links: 340
> - Packages in main w/ upstream links w/ branches: 217
> - Packages in main w/ upstream links w/ products that have trunk
> branches: 230
> - Packages that have upstream links that have trunk branches that
> work: 223
>
> The poor quality of the data in the Packaging table makes me think
> that we need to:
> a) rethink the details of this particular goal (look under the
> streetlight, so to speak)
> b) rethink the way we're gathering data
> c) make package / product linking way better.
>
> Anyway, here are the queries.
Reporting
---------
These reports can help measure our success at linking Ubuntu to upstreams:
Track the number of upstream links
Track the number of upstream links with branches
Track the number of upstream links with branches and translations
Track the number of upstream links with bug trackers
Track the number of upstream links with bug trackers with bug watches
Track the number of upstream links with maintainers
But what of linking upstreams to Ubuntu? Their needs are different.
Track the number of packages that match the current release for upstream
Track the number of users who are affect by an upstream bug in tip
Track the number of users who are helped by an upstream patch
Issues and ideas
----------------
There are two general approaches that can be taken to bridge the gap.
The strategy is kind of like the game Chutes and Ladders. We can
improve the current design by fixing bugs so that users can do the work
to complete the missing data. The complimentary approach is to add new
features that do the work for the users, possibly before they knew to
request it.
The UI to link packages needs improving
.......................................
* We Fixed a lot of bugs recently to clarify the UI and give users
equal access package linking.
* Fixed the code to make sane package links...no more oopses
* Fixed the instructions to link packages
* Reconciled permissions so that any user can link a package from
the project pages--this makes linking more likely to be discovered.
* There are still duplicate and somewhat contradictory pages for showing
package links and creating them.
* Project +ubuntupkg and +addpackage
* Project +packages and +distributions
* SourcePackage +packaging is redundant in every distroseries
* bug 71545 shows that the project does not think it is packaged
in feisty, the series says shows it is linked and lists packages,
yet it too states there is no current release
The call to action is absent
............................
* The distroseries page needs a portlet that calls attention to
packages that need linking. Martin and I discussed this during
the distroseries redesign.
* The distroseries and source package pages need some way to indicate
or list upstream releases that need packaging.
* When a driver registers a project series, he should be prompted to
link it to a source package.
* When a driver registers a project release, he should be prompted to
link to a source package
* There is no clear benefit for a an upstream to link a package.
The Workflow needs improving
............................
* Launchpad lost the upstream links when Ubuntu started a new series
* Compare
https://launchpad.net/ubuntu/karmic/+packaging
https://launchpad.net/ubuntu/Lucid/+packaging
* We know that Lucid started with the same packages so the links
should have been identical at that moment
* We can fix the process, and prepare a data fix for right now
* When the project does not exist, the UI could provide a way to
create the project just like reporting a upstream bug. Well not just
like because that experience needs improvement.
* Super projects like GNOME have a central repository of code and there
is a DOAP that clearly states information we need to register a
project: http://git.gnome.org/cgit/gedit/tree/gedit.doap
Registering a project could be as simple as pointing to a URL.
* We know the repos for the super projects and their policies, we
could have thousands of project imported.
* Requesting a code import could suggest the user link to an Ubuntu
package
* Creating packages for PPAs, or the PPAs could encourage linking
the source series to an Ubuntu package.
* There was discussion about presenting the completeness of project
information that would encourage users to provide this missing
data.
* Introduce project karma: yes that is right, all you developers who
have worked tirelessly to maintain your project have never been
award points, unlike that random person who filed a bug. We could
reward users for maintaining theirs projects and their links to
the community.
* The emphasis on project downloads encourages user to think of projects
as isolated entities, and Launchpad as a hosting service. Projects
are entity in an ecosystem, and Launchpad is a community. The UI
could emphasise this.
--
__Curtis C. Hovey_________
http://launchpad.net/
Attachment:
signature.asc
Description: This is a digitally signed message part
References