launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

Hi Bryce.

This question proved to be a big distraction for me. I think this could
be the start of a discussion. I have a lot of information in this, so I
am CCing the list.

On Wed, 2010-06-30 at 17:20 -0700, Bryce Harrington wrote:
> 
> 1. Should this just be a Ubuntu-specific linking, or should it be
>    done generically to suit arbitrary numbers of distros?

When you report a package bug is also in an upstream, the Packaging
object is used to select the probable upstream project.

Packaging objects emphasise Ubuntu. They are not arbitrary. You can only
create a packaging link between a project and a source package if there
is publication history...Launchpad knows about Ubuntu and has a little
knowledge of Debian.

...


> 2. Should list include any registered distro or only ones with
> packages
>    hosted by launchpad?

What do we mean by hosted? Build packages, distribution.full_featured
(Ubuntu); or uses Launchpad to track bugs (Ubuntu, Baltix, Guadalinex)?
I think using Launchpad bugs is the right criteria since this issue is
about bug tracking.

Honestly, the bugs in other distros that do not use Launchpad (Fedora
and Gentoo for example) is a massive distraction. Their source package
names are != to debian and Ubuntu source package names. Users link to
packages to discover that while the name is the same, it is a different
upstream or has different content in Debian. Gentoo source package names
can violate Launchpad's name rules. We cannot do this well, we should
not do this unless we intend to support them well. The Ubuntu community
is the only community that really needs this.

> 3. Should portlets be used for this? 

distro-bug-links2.png: I like the proposals that reinforce what users
know and show symmetry between distros and projects. Users should not
need to guess who the upstream project is though.

distro-packages.png: The inverse looks wrong. because it is label, then
number.

The distro-packages.png is scary. The sample data makes me scream NO.
(not your fault). The proposal is impossible.

Packaging links require publishing history as stated above. They can
only be created for Ubuntu and Debian. We decided to limit this to
Ubuntu from the project perspective because 1/3 of all links created
from project to distros were wrong. Project users do not understand
distros, so we should not ask them to make bad data. I personally
deleted more than 1000 bad packaging links in January.

We fixed more than 10 bugs in the last 9 months that were about
ambiguous names and duplicate information. We do not want to reopen
those bugs. (+) Link to Ubuntu package is used from series pages because
it can create historic and current packaging links. When we are working
from the project, we use (/) Set Ubuntu package information which limits
the action to the current series in both the project and Ubuntu. 

The image proses that we add a distro packaging portlet to the project
page--we already have one and we can see from linking trends that it
works. I do not think is is necessary or wanted. We considered adding
(/) Set Ubuntu package information to the project's action menu, but
setting that will show the Ubuntu packages portlet. The actions must be
near their content.

Aside: Involvement menu presentation must be an action, but the proposal
is navigation. This is the related/nearby problem on many pages. We
officially place this kind of link in the content, often at the bottom
of the page. I think this rule is flawed and we should revise it.
Revising it means we are committing to fix about a dozen pages to use
the new rule. This is a separate problem.

/me thinks about the broader perspective.

      * We want to show there is a connection between a project and a
        package, specifically we need to know the name (with links) of
        who the two are. (this already happens on the project and
        package index, but not the bug index)
      * We want to see links to (upstream/downstream) bugs queries for
        convenience.
      * When the information is not known we want to ask the user to
        provide it.
      * This Packaging object created by the link is used to suggest the
        upstream/downstream in "also affects ..."
      * The upstream/downstream relation i asymmetric. All distro
        packages have 1 upstream, and they want to know it. A minority
        of projects have a downstream (most project fail before they are
        packaged), Some projects have many downstreams.

Package proposal:
      * On the Ubuntu/Debian package bug page we include a The Upstream
        bugs portlet among the side portlets.
      * It tells us the name of the upstream.
      * There is am edit link (/) after the upstream name that goes to
        +source/xxx/+edit-packaging that permits users to fix the
        upstream. (automatic redirection back to the package bugs page
        is already built-in)
      * It reinforces the status queries used by the package: 12 _New
        bugs_
              * I imagine 3 _bugs with patches_ would be an important
                inclusion.
        
        -----------------------
        Upstream Bugs:
        Jokosher => trunk (/)
        
        12 _New bugs_
        23 _Fix committed bugs_
        
        3 _Bugs with patches
        -----------------------

      * When the upstream is not set, we we ask for it.
   -----------------------
        Upstream Bugs:
        
        Launchpad doesn’t know which
        project and series this package
        belongs to. 
        
        (/) Set upstream link
        -----------------------

Project proposal:
        I do not have one. This is hard because there are many sets of
        information to be shown. We also need to consider that much of
        this information is not interesting to projects. Making this
        interesting is the first priority, knowing how to present it is
        the second priority.
      * Most project should not have a portlet to an non-existent
        upstream. Launchpad allow users to say the project is not
        packaged in the project index page. The user will be asked to
        re-confirm this a year later.
      * Some projects provide many source packages. How would we say the
        project has bugs in 5 different packages?
              * I am sure this would prove to be a great distraction for
                users trying to work the project bugs
              * If we need to do this, it would require a separate page.
      * Some projects have packages in Ubuntu and Debian
              * We often ignore Debian because the publishing
                information used for packaging is stale.
              * Projects do not care about bugs in Jaunty because that
                is a year away from tip.
-- 
__Curtis C. Hovey_________
http://launchpad.net/

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