|
From: Ion-Mihai T. <it...@Fr...> - 2011-08-02 16:44:50
|
On Tue, 02 Aug 2011 14:09:41 +0200 Tom Hendrikx <to...@wh...> wrote: > 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 :) Thought so :) > > 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? -admins ML archive, mostly. See the mails from 2009-04 - 2009-06 and 2009-07-13 - 2009-07-15. Ping me if you don't find the messages and I'll fw them. This is the closest thing http://sourceforge.net/apps/mediawiki/dspam/index.php?title=Create_new_release > 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. The whole structure came from some discussion back then. A a side note, I think this way of using branches is more clear that odd/even-numbered releases some favor. > > 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. +1 > 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). +1 > 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. Yes, indeed. > 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). The way I see it: - users like to run a release in production - users might need some patches sooner committed since the last release, but basically they don't want to risk big changes - they'd track a stable branch (eg. RELENG_3_10) > When someone is distributing .deb packages based on git checkouts, you > know there's something wrong. I agree. The whole idea with the branches is to make minor releases easier to get out, by being conservative and consistent in what we merge down in stable branches. > 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. Yes, yes, yes. :) > > 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 :/ If I'd be pedantic about it, I'd say do a force commit :) -- IOnut - Un^d^dregistered ;) FreeBSD "user" "Intellectual Property" is nowhere near as valuable as "Intellect" FreeBSD committer -> it...@Fr..., PGP Key ID 057E9F8B493A297B |
