|
From: Tom H. <to...@wh...> - 2011-08-02 22:00:15
|
On 02/08/11 18:44, Ion-Mihai Tetcu wrote: > 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. I need to read up on the bigger idea behind the odd/even releases, but I see the way the branches are intended. While it makes sense for our own work, I'd still not like to see users running a snapshot of some RELENG branch from some undefined point in time. In the end, they choose by themselves, but this is more about giving them too much rope (apart from the additional work that needs to be done). > >>> 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) > Ah yes, I'm beginning to the reasoning behind it all. The RELENG_3 and RELENG_3_10 are not only updated while working on a new release, but also after bug fixes on earlier releases. Eventually, when enough bug fixes have accumulatedin RELENG_3_10, you just branch RELENG_3_10_1 from that, and release the tarball with all bug fixes. This makes it easier to add new functionality to master without polluting the bugfix releases. But regarding external users in need of specific patches: I'm used to picking patches directly from master when I need them, like most patch-savvy users I think. >> 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 :) > I tried to do this, merely as a means of getting more git voodoo. I did git --amend on my latest commit, and git log looks fine after that. But pushing the change to SF bails with an error, which sounds logical: ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'ssh://whyscream@dspam.git.sourceforge.net/gitroot/dspam/dspam' To prevent you from losing history, non-fast-forward updates were rejected git push --force sounds like the way to go, but I'd like to know for sure before I break something :) -- Tom |
