[Da-tools-discuss] a couple of stylistic questions

[Joerg Jaspert]

On 11257 March 1977, Stephen Gran wrote:

> I just did a couple of commits to clean up the packaging of a few of the
> packages, and it got me thinking.  My workflow is to generally make
> changes that I feel are smenatically related (in this case, freshen the
> packaging) and then commit them as one commit, even if that means
> multiple lines in debian/changelog.  Do other people have other
> preferences (lots of small commits, eg)?  I don't mind either way, I
> just want to make it easy for to collaborate, so I'm asking.

Smaller commits are fine, but I think that can be done as one likes.
As long as you dont push knowingly broken things, but like - for dak i
go and do lots of small commits, and at some point push it somewhere so
elmo can merge. When I then merge back from "upstream" dak - all my
small commits get turned into one revision, showing a subtree for my
commits (bzr viz makes that nicely displayed, but you also see it by bzr
log, the indented stuff)). Keeps working history.

The above is true for "bzr branch", where you commit locally and then
push it up. If you did checkout the commit moves up immediately, there
you might want to be more careful.

> And another thought this raised:
> In a lot of projects I work on, we tend to use distribution=UNRELEASED
> or something in the changelog while we're working on a new release, and
> only change it just prior to upload and tag.  This makes it easy to
> track whether another change needs to increment the revision or not, but
> this isn't exactly the normal packaging workflow - most of these
> packages are irregularly uploaded to the archive, if at all.  Thoughts
> about how to handle this?

I would follow whatever weasel wants here, as we want him to merge from
us. If he doesnt want to have some UNRELEASED tag there and we use it he
would always have a conflicting line to fix, i think.

-- 
bye Joerg
I read the DUMP and agree to it.