launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01791
Re: Getting upstream's trunk code for a package, and data and so forth
On Sun, Nov 15, 2009 at 11:56:47PM -0600, Jonathan Lange wrote:
> Hello Launchpadders & UDDers,
>
> Since we want people to be able to easily build packages out of the
> trunk of their upstreams, we want to have working Bazaar branches for
> the trunks of the upstreams of all our source packages, starting with
> the ones in 'main'.
>
> To me, this is a quantifiable goal, so I think we should have a graph
> that shows the following:
> - Number of packages (maybe in an interesting subset)
> - Number of these packages with upstream links
> - Number of packages that have upstream links that have trunk branches
> - Number of packages that have upstream links that have trunk
> branches that work
>
> When all of the lines converge, we win, and get to eat cake.
>
> I've written some queries that measure these things, which I shall ask
> to be put onto a graph by-and-by. However, I'd like you to have a look
> at these queries and review them for correctness.
>
> For those who are interested, the numbers for Lucid are:
> - Packages in main: 16143
> - Packages in main w/ upstream links: 16
Is an 'upstream link' a link from the package to the upstream project in
Launchpad? If so, this measurement doesn't make much sense, given how
packaging links currently work. It's designed so that if no link exist
for the current series, it will look for a link in previous series.
Therefore, the user doesn't have an incentive to create links for Lucid,
if the package already has a valid link for a previous series. Things
work just as well with a link for a previous series as it works with a
link for the current series.
What should probably happen here is that we should automatically carry
over links to new series, either by explicitly copying the links, or
implicitly by having the Python API take care of things. The only reason
at the moment to create links for Lucid, is if the package doesn't have
any link for a previous series, or if you want the project page to say
that a package exists for the project in Lucid. The latter shouldn't be
necessary, we should do it for the user. In other words, we should use
this graph to drive people to register links for Lucid; it's
unproductive use of their and our time. It would be better use of our
time to actually fix how packaging works. I know some work was done
before, so I don't know how much is remaining.
--
Björn Tillenius | https://launchpad.net/~bjornt
Follow ups
References