Am 15.01.2014 19:41, schrieb Tom Wijsman: >>> Yes, I see some commit messages not refer to bugs which is >>> something we will want to avoid; think this might need to go >>> into the commit policy. >>> >> There's nothing wrong with fixing/implementing something that >> nobody filed a bug about. > > Sorry, consider the common case where a bug was filed but the > commit message does not refer to that bug. Also note that I am > trying to refer to the ChangeLog of Portage itself, not that of the > ebuild; thus I mean the commit messages for the Portage repo, not > to the Portage tree. > Not sure if we're talking about the same things.
1) If you fix something that has a bug, you should refer to that in the git commit message. 2) There's nothing wrong with a git commit message that does not refer to a bug, if there is no bug filed. > The whole point of documenting it in a workflow is to make it > converge; Not the "converge" I meant. What I meant was to allow people to test different styles and hope that the one that works best will be adopted by everyone at some point. Once that happens you can document that style. > if you instead leave things unclear or undocumented, you have no > guaranteed convergence and might even see a disconvergence. Yes, maybe. One then needs to see if that is a problem and if it is then force everyone to use one style. > > It's already making people unhappy right now; because as it is > documented now, it is turned from the meaningful experience that > the previous Portage team had before to something that is > meaningless. It is a regression in checking the list of bugs that > block the tracker, as the states of the bugs no longer have a value > as it is documented now. > Previously the bug state was not used at all. There is no regression.
