Re: Proposed hook to tag bugs as pending
* Clint Adams [Thu, 26 Mar 2009 19:22:31 +0000]:
> On Thu, Mar 26, 2009 at 08:12:29PM +0100, Adeodato Simó wrote:
> > Right, but my proposed script should cater for both workflows (letting
> > the tools write your debian/changelog, or writing it by hand), since the
> > bug closure will *always* be in debian/changelog.
> That is not true; for those of us who are not mixing debian/changelog
> in with our commits, the bug closure will *not* be there until such
> time as the pending tag will be useless.
“Oh.” I guess such workflow was already implied in John’s message, but I
parsed his “git-buildpackage tools can generate an appropriate changelog
for you” as to mean that they’d generate the corresponding
debian/changelog entry *on each commit*, whereas he problably meant (or
at least you are now, AIUI) generating the full debian/changelog before
the upload, from all the existing commit messages since the last tag.
This is a workflow I actually knew existed, but failed to recall today,
hence my EPIC FAIL above.
Now, if one wanted to write a hook that actually catered for both
workflows, what would one do? Does anybody has suggestions? It is
certainly doable to parse the commit message for Closes, and act only on
those bugs if any, and if there are not any, look at the changelog. (I
think it’s reasonable not looking at debian/changelog it the commit
message mentions a bug number.)
However, this will behave horribly when the run of git-dch or whatever
tool is committed, since it will want to mark all the bugs as pending
again; that’s the part where I need suggestions. I’d rather not have the
hook need any configuration, and making it stateful is definitely out of
questions. Maybe it should treat the bug numbers from debian/changelog
as “untrusted”, and only send the message if they are not tagged pending
already (by doing a SOAP request)?
Thoughts? (And thanks for pointing out this.)
--
- Are you sure we're good?
- Always.
-- Rory and Lorelai
Reply to: