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

Jordan Mantha laserjock at ubuntu.com
Tue Nov 17 15:18:26 GMT 2009


On Tue, Nov 17, 2009 at 10:06 AM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>>
>> 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?

I think it depends on the upstream VCS, the kind of revision control
model being used, and how involved the patch is. In the upstream
projects I work in bug fixes are in single commits. This is normal for
SVN users (which is still a large percentage of upstream) and even in
the projects using Git what I've seen is single commit for a bug fix
and branches when something gets large enough to be called a
"feature". I think most often the kinds of bugs that most Ubuntu
developers would be interested in for  stable release updates would be
single commits outside of Launchpad. Using bzr/Launchpad is a bit
different though since it seems like the best way to get your change
noticed is to create a new branch that can be requested for a merge
rather than tagging a commit for merging (which seems to be more of
what I see outside of Launchpad).

-Jordan



More information about the ubuntu-distributed-devel mailing list