|
From: Ion-Mihai T. <it...@Fr...> - 2011-08-02 11:36:47
|
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? 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 model would (theoretically, since we never really did the merging down in time) allow users to track a more stable branch that MASTER. Also, please give credits Reported-By:<TAB>..... Thanks, -- Ion-Mihai Tetcu <it...@Fr...> |
|
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 |
|
From: Ion-Mihai T. <it...@Fr...> - 2011-08-03 08:08:08
|
On Wed, 03 Aug 2011 00:00:00 +0200 Tom Hendrikx <to...@wh...> wrote: > 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, There's none, really :) Some think that eg. odd release are experimental while even are stable. We don't follow this. IMO is a bad idea, it just lowers the bar from a QA/RE point of view. > 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). IMMV ... > >>> 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. Exactly. We could have a script that would parse the commits for the MFM tags and send a reminder when the period has passed. > 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. Yeh, but not all users are. More, if you pick one patch from MASTER, you'll have to check how the changes in it might interfere with the rest of the code, while checking out a branch is very straitforward. > >> 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 :) Well, personally I dislike git and the "chaotic" model it seems to encourage. -- Ion-Mihai Tetcu <it...@Fr...> |
|
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 |
|
From: Ion-Mihai T. <it...@Fr...> - 2011-08-02 16:44:50
Attachments:
signature.asc
|
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 |
