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

[Curtis Hovey]

Resend since I have not seen this message arrive.

On Mon, 2009-11-16 at 22:10 -0500, Jordan Mantha wrote:
...
> >> 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.

I have not found any documentation. I have been reading the code, the
bug reports, and trying the UI to understand what it does. I have fixed
many bugs that make the action easier to perform and prevents insane
data.

I have been asking the similar questions as you. Package links do not
create notifications when upstream creates a release. The imported
releases may fix bugs that Ubuntu cares about, but there is no automatic
way to state that 10 fixed bug upstream are some other 10 bugs in
launchpad.

I think packaging links (as they are implemented) are documentation
about the past. They are not a tool that helps contributors to know when
to create a package and where to get the code.

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

Do you care about currency? Many packages in Ubuntu seem to be many
version away from the latest release

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

This was very confusing for me too. I know that most of Lucid's
development for the code GNOME packages will track the master branches.
GNOME will stabilise at 2.30.0 in a few months, and Lucid will go into
beta. It is possible that Lucid final will release with packages created
from the 2.30.1 branches.

The instructions in the UI to link a distro package to a upstream states
that trunk is probably *not* the correct series. I think in many cases
it is the *correct* series for most of the distro series' development.

When I review package updates for the stable series, the links are
clearly wrong.

> 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

This might be doable. Each series does have its own link, the problem as
I said above is that the link often changes during development. There is
no mechanism to identify when the switch happens. It is not clear who or
what should perform the change. If there were a mechanism to marry the
version of the package to the upstream trees, we could automatically
switch the package link. Should the switch be predicated on the upload
of a new package or should upstream's new branch trigger an update to
the link?

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

Interesting. Thanks. Launchpad hosted project have also stated that
Launchpad needs to distinguish between stable and development releases
instead of tracking the latest release.


-- 
__Curtis C. Hovey_________
http://launchpad.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-distributed-devel/attachments/20091117/07eed483/attachment.pgp