← Back to team overview

launchpad-dev team mailing list archive

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