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

[John Arbash Meinel]

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

Are bugfixes generally done in a single commit? I suppose it is worth
starting with the concept that they are. For *my* bugfixes, they are
generally done in a single feature branch, likely with a few commits,
which is then landed in "trunk" in a single merge. (So if you
cherrypicked the merge, you would get the full bugfix, but if you
cherrypicked a commit on the feature branch, you probably wouldn't.)

Does this correspond with a common case for upstreams?

John
=:->