launchpad-dev team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

On Thu, Jul 01, 2010 at 11:49:05AM -0400, Curtis Hovey wrote:
> 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.
> 
> ...

Okay, based on this point and elaboration on the points below, it sounds
like at least for now, this feature should be implemented as a
Ubuntu-specific link.

> > 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.

Well, one of the benefits I could see from a Ubuntu perspective is that
it would give developers and triagers an easier way to get insights into
what's going on in other distros.  E.g. for patch nabbing.

However, that assumes this info is easily accessible in launchpad.  If
not, as it sounds like may be the case, then this concept is probably
out of scope for covering in this particular bug.

> > 3. Should portlets be used for this? 
>
> /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
>         -----------------------

Thanks, this is clear enough.

> 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
          ^ DYM 'distro'?
>         packaged in the project index page. The user will be asked to
>         re-confirm this a year later.

Could you clarify the last sentence - does this mean that users are
already emailed to re-confirm the project is not packaged yearly?  Or
that they *should* be emailed yearly?

>       * 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.

I would imagine that the number shown would be the sum of bugs in the 5
different packages?

The trick is in how it would be linked, since we do not have a page that
would show a merged listing of the 5 packages worth of bugs.  I think
you're right that in such a case it'd require adding another page.
(Slickest would be a page that shows a unified/merged listing of all
bugs across all of the source packages.)

>       * 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.

Right, in general for purposes of bug listings bug nominations/targets
aren't going to be relevant.

Bryce