On Mon, 2008-06-02 at 20:49 -0400, Drew Marold wrote: > IMHO it gets to be too much overhead. I don't think it's necessary to > file a bug every time I want to make a change to the build system, or > update a document, or write a new tool. And the second you introduce to > concept of standing bug ids for certain tasks you know people will take > the lazy route and use them instead of filing a new bug.
I understand what you mean. I've experienced that scenario. If let's say you are rapidly developing (e.g. a startup, or a toy idea, or Scmbug 0.0.2) and are not sure what your requirements are, that's ok. Just be conscious that you *want* to not have tight SCM integration at that environment. But if that's not explicitly what you want to do, then I have to disagree with you. I believe it is necessary to file a bug every time you want to make a change to the build system. Perhaps this "change" outlines the fact that a previous bug you developed should be reopened because the work on it was incomplete. Or you could leave a standing bug id for certain tasks, yes. Note that a standing bug id (any bug id really) still cannot have source committed against it just by anybody; only the owner of the bug id can commit against it. Which outlines in my opinion a separate issue: the fact that components and tasks should have owners, people that are *responsible* for them. e.g. I wouldn't feel comfortable having just anyone changing the build system, or updating documents that someone else is writing, or writing new tools whose logic someone else may have already partially developed. This can be important in development teams where there's no possibility for face-to-face dialog or no easy way to know what someone else is working -- e.g. collaborating on Scmbug with people from other timezones. Such changes could be developed by other people as patches and attached to bugs, so that the owner of the component can review and apply. It may be tempting to skip such steps, but aren't you losing something from a change management process perspective ? I know I broke things by pushing seemingly trivial changes, only to search the bug-tracker later and find... my own notes that such a change was applied before and did not work; to realize that I was pushing changes in haste. It's hard to stay disciplined in that respect, but failing to understand *why* something was not fixed already would be equivalent to sweeping other possible bugs under the carpet. So my point is that this "overhead" is the necessary reminder that some tasks haven't been completed yet and that you should be aware of them. I feel it's important to accept that some tasks may take a long time to complete (so we shouldn't be closing bugs just because we are tired of seeing them showing up in our bug-list). But it is just an opinion and I'd be interested in what others have experienced.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ scmbug-users mailing list [email protected] http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
