launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

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