|
From: Tom H. <to...@wh...> - 2011-08-02 12:09:58
|
On 02/08/11 13:36, Ion-Mihai Tetcu wrote: > On Tue, 2 Aug 2011 09:54:11 +0000 > "Tom Hendrikx" <why...@us...> wrote: > >> >> - Log >> ----------------------------------------------------------------- >> commit ff5d33ddbdc449bd0ad8fa3d279b4f1a7392ee9e Author: Tom Hendrikx >> <to...@wh...> Date: Tue Aug 2 11:53:17 2011 +0200 >> >> Add doc/cssclean.txt back to Makefile. > > Is this commit supposed to be merged down in RELENG_3 at some point? yes :) > In this case please add a > MFM:<TAB><TAB> N days > to the commit message. The idea is to have all changes tested in > MASTER, and after the appropiate period of time has passed, to have > them merged in the stable branch; so the ``N'' is at committer's > discretion, depending on the potential implact the change might have. This looks like some common practice I do not know about. Is there any documentation where I can find more about this and other practices? I would also think that the way the RELENG branches are currently structured, have some bigger plan behind it that I do not know about. Again, any references to documentation on this would be nice. > This model would (theoretically, since we never really did the > merging down in time) allow users to track a more stable branch that > MASTER. I would opt for a micro release in less than a month, containing this sort of issues that are likely to come up after people start using the release. Supporting multiple branches is a nice idea but there is no manpower to do so, I'm afraid (or else it would have been done in the past). IMO there are typically 3 types of users: 1) use only stable releases 2) use git HEAD and know what they're doing 3) use git HEAD (or stable releases with patches) because they are forced to do so. If we keep the release cycle narrow, we can keep the number of users in 3) down. Users that insist on having a git version running, should be well aware of the fact that they are doing so, and can always be instructed to try today's HEAD before filing bugs. With the current slow release cycle, this is problematic because there are too many users in 3). When someone is distributing .deb packages based on git checkouts, you know there's something wrong. Finally, sending out releases (even for trivial bugfixes, used with caution) also shows to the general public that the project is alive. This can only have positive effects on attracting users, developers, distro inclusion, etc. > > Also, please give credits > Reported-By:<TAB>..... > I noticed I forgot to add his name to the commit message when I was waiting for git push to complete. Better luck next time :/ -- Regards, Tom PGP key ID: 7D54EFF5 PGP key FP: C26F 374F 5E13 157B 5B42 7A1B 93DF 319D 7D54 EFF5 |
