On Tue, Aug 30, 2011 at 1:46 PM, Marcus (OOo) <[email protected]> wrote: > Do you remember this one and its usage? ;-) > > https://issues.apache.org/ooo/show_bug.cgi?id=100000 > > It doesn't make sense to have a issue ID for *every* problem that > can/should/has to be fixed in the code. Especially for a build breaker fix > in a single line of code a detailed commit message is really sufficient. >
Something to keep in mind is that we agree to have different policies during different phases of a release cycle. For example, at the beginning of a release we would have a lenient policy: Commit Then Review, no requirement for pre-existing BZ issues, etc. But then after we branch for stabilization, or maybe after beta, or at some point where stability is the overriding concern, then we could switch to a policy of: Review then Commit, no commits unless accompanied by a BZ issue number, etc. There is a time for "bureaucracy" and we should not hesitate to be strict. But maybe we can narrow this to a small portion of the release cycle? -Rob > Marcus > > > > Am 08/30/2011 06:53 PM, schrieb Michael Stahl: >> >> On 30.08.2011 17:53, Tor Lillqvist wrote: >>>>> >>>>> I'd like to see commit log/messages containing the number of fixed >>>>> issue referenced and no commit >>>>> messages without that number. >>> >>> So people would not be allowed to improve things without first filing >>> issues? Isn't that the kind of bureucracy that gave OOo a bad >>> reputation among people who then created LibreOffice? >> >> i also think that requiring an issue id and thus an issue in the >> bugtracker for every commit is overkill. >> >> there are lots of trivial problems that always pop up (especially >> considering that we support many different platforms, and it's not >> really possible to test all of them before every commit). >> >> on the other hand, if there already is an issue for whatever is fixed by >> a commit, then that commit should be required to contain the issue id. >> >>> Also, having an issue number in the commit message is not really that >>> helpful, if the commit message is a short one-liner, the bug report >>> doesn't describe what the changed/added/fixed code actually does >>> either, and no useful comments are added. >> >> indeed, that sometimes bothered me in the past as well. >> >> if a bug fix isn't totally obvious, then there should be a comment >> somewhere, whether in the code, the commit message, or the issue >> referred to by the commit message, as to what went wrong and why this is >> the right fix. >> >>> --tml >> >> regards, >> michael >
