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. _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
