launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 18 August 2011 18:24:32 curtis Hovey wrote:
> A user can report a bug or ask a question about any package installed on
> their system via apport/ubuntu-bug/Get Help.
> 
> /me tries
> 
> <https://launchpad.net/ubuntu/+source/gaim> is deleted. It was published
> in Dapper and I cannot report a bug on it now since it was deleted. Okay
> maybe we do not need to support deleted packages since Lp does not
> currently support it
>
> Lp lets me ask questions, but I think we could consider desupporting
> this case to be consistent with bugs.
> 
> In the case of a branch, I am still learning the rules. Francis
> qualifies this as an official branch. What is official though? I think
> it means the branch linked to the package such as lp:principia/mysql
> which is actually shorthand for lp:principia/<currentseries>/mysql (AKA
> SeriesSourcePackageBranch)

Based on the thread title you started - the package is not in the distribution 
if it's not published.  This is why I think unpublished source package 
branches are an odd case and IMHO are not "in the distribution".

> No it does not count, though that process is what created source package
> names that Lp current uses for bug and question targets. ubuntu-bug does
> not let me report bugs against  python-html5-browser since it is only in
> PPAs.

Based on the bridging-the-gap work I expect we'll need to support bugs on PPAs 
at some point.  Think of the situation where a developer needs bug reports on 
daily builds (which is one of the main reasons of doing daily builds).

> This issue also came up when working on bridging the gap, where DSP is a
> fulcrum for package, branch, upstream project, etc... We decided to do
> the minimum work do move on to something different after 13 months. I
> think the performance gain as well as the certainty of knowing valid
> DSPs makes this effort worth doing.

Also - nothing apart from Soyuz should ever be looking at publishing records, 
it's a gross violation of the interface if it does.  Soyuz definitely should 
be creating this summary info if other apps need it.

> I am inclined to study the removal of the DSP virtual object. I believe
> there are instances where Lp works with the DSP as virtual before
> deciding that it needs to me in the DB.

I think some places create one just so they can call canonical_url() on it.

> Ah. Yes we do need to know if the status is deleted. I think this means
> that an official package branch that was deleted and never published
> makes a DSP also deleted/obsolete.
> 
> Maybe obsolete is a better term to describe a DSP that is not used any
> more. I am not proposing that we delete it when the package/branch is
> deleted.

"Obsolete" is a specific publishing status for when a package was completely 
removed from the archive in a particular distroseries.  "Deleted" just refers 
to a version that was manually removed.

Everything else that's auto-removed has the "superseded" status.

We should definitely simplify any statuses for DSP, most things don't need to 
know this level of detail.

> So while I was thinking about this as a DSP issue there are cases where
> the bugtarget is (DistroSeries)SourcePackages. I think this happens via
> bug nominations; ubuntu-bug reports the bug on the DSP.  . We have no
> mechanism to ensure that source package branches are represented in the
> DSP table.

Right.  We could go for a DSSP table to replace the existing fake as well if 
required.  Again, I think some of the Soyuz pages would benefit.

(It's bizarrely named just "SourcePackage" in the current code)

> > What needs to happen if there's a branch for an unpublished source?
> 
> I am certain we know the source package name and the distro, which is
> enough to create the DSP entry.

See my earlier comment about whether this is really desirable.

Cheers.