Things to graph for package-of-the-day work

Jordan Mantha laserjock at ubuntu.com
Tue Nov 17 03:10:34 GMT 2009


On Mon, Nov 16, 2009 at 9:02 PM, Jonathan Lange <jml at canonical.com> wrote:
> On Mon, Nov 16, 2009 at 9:20 AM, Jordan Mantha <laserjock at ubuntu.com> wrote:
>> On Mon, Nov 16, 2009 at 1:19 AM, Martin Pool <mbp at canonical.com> wrote:
>>> 2009/11/16 Jonathan Lange <jml at canonical.com>:
>>>>>>> 1. Packages with upstream imports
>>>>>>>  - Number of packages (maybe in an interesting subset)
>>>>>>
>>>>>> Packages in Lucid main: 16143
>>>>>> Packages in Karmic main: 16217
>>>>>>
>>>>>>>  - Number of these packages with upstream links
>>>>>>
>>>>>> lucid: 16
>>>>>> karmic: 340
>>>>>
>>>>> So 'upstream links' in this context means just a link from a distro
>>>>> package to a Launchpad product, and from there it may have a link to a
>>>>> trunk branch?
>>>>>
>>>>
>>>> To a Launchpad product series. From there it has a link to a product,
>>>> which then in turn has a link to a product series which has a link to
>>>> a branch.
>>>>
>>>> I'm not sure if this answer actually helps.
>>>
>>> It does confirm my tentative understanding was correct.
>>>
>>> Then your numbers seem to show that the weakest link in the import
>>> chain may be those upstream links?  And it should be fairly easily
>>> fixed, considering the data to complete say 90% of them is probably
>>> already in the system?
>>
>> From the perspective an Ubuntu developer, I've been around Launchpad
>> since Ubuntu first started using it and I am still baffled as to how
>> these upstream links work, how they are supposed to be used, and what
>> benefit they might have to the developer. I therefore choose to ignore
>> them entirely. Is there any documentation on what exactly the linking
>> is for and what it means to an Ubuntu developer?
>>
>
> No docs that I know of. Curtis might, since he seems to know
> everything about the registry.

OK, I'd be interested to know.

> Although I don't quite see the details yet, I can expect this being
> more useful when we have better bug forwarding and more infrastructure
> for package-of-the-day.

That seems logical.

> In fact, you'd probably know better than I: If Launchpad had access to
> the branch for a source package and the branch for its latest
> upstream, what could we do that would help the average Ubuntu
> developer?

Well, the primary things I think a developer wants to know about
upstream would likely be:

  1) New releases - not so interesting at the VCS level unless we are
tracking upstream's VCS in the packaging (gwibber for example) at
which time it's *very* interesting to the developer. Of course being
able to do package upgrades based off of upstream imports is great for
any package.

  2) upstream fixes for Ubuntu bugs: Practically, it would be nice to
know about upstream commits that mention LP bugs and if they are able
to apply to our current packaged source. Something along the lines of
grep'ing the commit logs for LP bug URLs and trying to cherry-pick
those commits into our source branch.

   3)tracking upstream branches with Ubuntu release branches: one of
the things that I find confusing about the upstream branch linking is
that it seems static. Several times I've linked the current
development release to upstream trunk (the only branch that was
available at the time) only to come back 6 months later to see that
upstream trunk is still linked to the now fixed Ubuntu release. What I
would like to see is the ability for the Ubuntu developer (or
automatically) to link an Ubuntu package to either an upstream
commit/tag or to an upstream branch. In the case of the upstream
branch it is enormously useful to get notifications of new commits in
that branch and some sort of automatic merging back to the right
branch.

For this last point (because I'm not sure it fully makes sense even to
me) I would like to give a concrete example. One that I'd probably
actually use is the gnome-chemistry-utils package[0]. I've registered
the upstream in Launchpad [1] and started a VCS import. I know that
upstream uses a Gnome-like release policy so even releases are
branched and bug-fix only. So here's what I'd like:
   * Lucid Lynx should either track upstream trunk or 0.10 branch
(maybe I can change that if it's wrong) and should give me notices of
new bugs fixed in VCS
   * Hardy-Karmic should track the upstream 0.8 branch and give me
notices of new commits (they are all going to be bug fixes)
   * Dapper should track the upstream 0.4 branch and give me notices
of new commits

Ideally I'd also see a links to proposed merges upon new commits for
stable Ubuntu releases. Now what would be really nice is if when Lucid
is released, it moves into the "Stable Release" mode.

What basically I'm after is me being able to utilize upstream's
commits more and upstream feeling like I'm not ignoring their hard
work. Most often I just don't have time to track the upstream VCS of
every upstream I touch (at times I've uploaded packages for 30
different upstreams in a release). If LP can track them for me, and be
smart enough to know the difference between a stable release and a
development release (either because I tell it which is which or
upstream has a nice VCS structure) I'd be a very happy developer.

-Jordan

[0] https://launchpad.net/ubuntu/+source/gnome-chemistry-utils
[1] https://launchpad.net/gchemutils



More information about the ubuntu-distributed-devel mailing list