Lars Marowsky-Bree wrote:
Hi,
how about commit messages which have some resemblance to what the change
actually is about - preferably from a user's point of view, but I'd even
take a developer PoV, but with
bug impact: major (if you use cl_respawn), risk: low-to-moderate LF bug
1706 (finishing up associated issues)
not even _I_ can figure out what it is about and supposed to fix w/o
going to bugzilla.
My suggestion would be to have a short, concise summary in the first
line (user's point of view) and explain any implementation details worth
mentioning in the body of the commit (developer's point of view).
The "severity" and "risk" assessment in the summary also seems to be
counter-productive and uses up most of the conciseness of the summary
already, and we can't seem to decide between impact/severity/risk/bug
impact etc.
This _is_ somewhat annoying to parse.
I know! Maybe we should have a policy and stick to it? ;-)
I know that others might disagree with this - but trying to squeeze
everything that is already in a bugzilla entry into a commit message is
going to result in these kinds of complaints. And, not to mention a
lot of duplication of effort.
There is so _much_ we potentially want to know about a change - and a
good bit of it is already in bugzillas - for those where we create
bugzillas. And, you could argue that the rest could or should go into
the bugzilla database - especially since bugzilla is customizable (or so
I understand it).
There is no query facility for commit messages - and it would be very
difficult to write one.
If I want to ask the question about what all bugs we've fixed in a
certain area, I can't figure that out from commit messages without
reading them all.
Putting this kind of info into a database is an obvious "well, duh" kind
of answer. And, bugzilla is designed for just this kind of thing, and
we do use it for quite a few changes.
If we added the risk field to bugzilla - it already has all the rest of
the info in the database.
It would not be terribly complicated to write a tool to pick out the bug
number from the commit message and bring up the corresponding bugzilla.
If we pasted in the URL into the bugzilla, it would be even easier.
If you look in the "real world" outside open source development, it's
the norm to tie source control and bug tracking together for lots of
good reasons.
--
Alan Robertson <[EMAIL PROTECTED]>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
