-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/18/2011 12:07 PM, Julian Edwards wrote: >> A DSP is a valid choice if: >> * The source was published by the distro. >> Once published, it is forever a valid choice. >> <https://launchpad.net/ubuntu/+source/mysql> >> <https://launchpad.net/ubuntu/+source/devicekit> (still published) >> <https://launchpad.net/ubuntu/+source/devicekit> (deleted, >> yet still valid) > > How did you decide on the validity rules? Particularly the last one. (I am > curious) 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) >> Packages that were never published nor had a branch are not valid. >> <https://launchpad.net/ubuntu/+source/epsoneplijs> >> Was never published in Ubuntu. It was never published in any >> debian-based distro. No distro has a branch for it. It is invalid. > > That page exists probably because the package exists in a PPA. Does presence > in a PPA count for anything? > > (sorry, more questions than answers so far) 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. >> Though there is work going on to demoralise the data to make the DSP > > This is one of the best typos I've ever seen you make. If it's deliberate to > see if we were paying attention, then kudos. If it wasn't, you still get > kudos for giving me a massive belly laugh. This is a malapropism. I strived to keep my feeling out of this email. While I consciously wanted to type 'denormalise', my subconscious was wanted to scream that the current effort is demoralising. ... >> I believe we need a resource that represents every DSP that is a valid >> choice. Lp does have a DSP table, and parts of Lp does treat it as a >> definitive resource, but it is flawed as William Grant pointed out. The >> table has two purposes, Store DSP information that is beyond the package >> and branch, like bug supervisor or bug reporting guidelines. It also >> stores facts like PO message count and bug heat. We want this data for >> every valid DSP, but not every DSP is in the table, and there are more >> than a thousand impossible DSPs in the table. > > So there's two DSPs in the model code, as I suspect you know. There's a fake > one and a real one, which is in the DB. > > We thought a while ago that getting rid of the fake one is a seriously good > idea but there was never enough impetus to do the work. It would solve a raft > of problems with performance on some of the Soyuz pages. > > The idea is that it would be a cache of the latest publication data and other > bits required from other tables. Keeping it up to date is pretty easy since > we create all publications in once place in the code. > > I'd be very happy to see this work done and the old DSP fake removed. > > (I forgot the name of this data pattern but it's a common one I've seen and > used before) 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. 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. >> In the case if impossible DSPs in the table, they are mostly historic >> entries created by users to targeted a bug to a distro that does not use >> Lp to manage bugs. There is only one bad entry for Ubuntu, there are >> many for Debian that need investigation. There are about 1000 rows for >> distros that never used Lp to track bugs, do not have publishing >> history, do not have branches. >> >> There are two reason for missing rows. Changes were made in the last >> year or two to ensure that every uploaded source package has a DSP >> entry. Packages that were in older Ubuntu releases are not present. I >> image we could make the missing DSP rows by mining the source package >> publishing history table. > > Presumably this is only packages that are in older Ubuntu series but not in > the latest? > > In that case it needs entries for those packages to record that the latest > status is "deleted". > > Yes, we need to get some hard-hats on and go mining to fill these gaps. 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. 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. > > 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. >> Maybe the branch scanner could do this. > > If it did, we'd need to be careful about what publishing data it has as per my > idea above. Indeed. If a package has never been uploaded or built, what do we know about it from the branch? Its source package name is all that I can determine. >> Principia, a distro with just branches does have rows in the DSP table >> for the packages the owners have configured or have bugs. Most are not >> represented, so bugs cannot be retargeted to them. How do we ensure that >> source package branches are in the table? > > It seems like the table needs to be written to from two different places, the > branch scanner and the Soyuz publishing code. Obviously that has the caveat > of locking, data integrity and data overlap. Maybe there needs to be another > table? I believe soyuz already does the right thing. PublishingSet.newSourcePublication() calls DistributionSourcePackage.ensure(spph) - -- Curtis Hovey http://launchpad.net/~sinzui -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk5NStAACgkQnGlTRlchMn3aigCfYI2tabiKSe0F6E4djLf8PyAw ejIAnRjXwIHXRkuiwZ6Q5gi9qAfKLsKa =w5Jd -----END PGP SIGNATURE----- _______________________________________________ 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
