Re: [Monetdb-developers] Monetdb-developers Digest, Vol 6, Issue 15
Hi Stefan,
Thanks for bringing this up.
While I started with (1) for some of the most glaring bugs on Wednesday to ensure that the HEAD has some functionality; I switched to (2) since yesterday.
Peter
------------------------------
Message: 2 Date: Fri, 10 Nov 2006 00:39:08 +0100 From: Stefan Manegold Stefan.Manegold@cwi.nl Subject: [Monetdb-developers] Branches, Checkins & Propagation To: monetdb-developers@lists.sourceforge.net Message-ID: 20061109233908.GA13905@corona.ins.cwi.nl Content-Type: text/plain; charset=us-ascii
Esteemed fellow developers,
having two tightly related branches --- the release branch and the development trunk --- give us the opportunity to clearly and conveniently isolate new "progressive" developments on the development trunk from "conservative" code consolidation and bug fixing on the release branch.
Unfortunately, also this medal has a second side: to make the development trunk benefit from the code consolidation and bug fixes on the release branch either (1) *each* of the respective changes has to be checked in twice (by *each* developer), or (2) the checkins to the branch are *in bulk* (aka. "automa[tgn]ically") propagated from the release branch to the development trunk on an (ir?)regular basis or on need/request.
(1) has the advantage that all bug fixes are "instantly" available in the development trunk, too, but comes at the cost of double checkins and bears the risk of "forgetting" one. (2) keep all developers from extra work and -responsibility, but has the disadvantage that the availability of bug fixes in the development trunk is delayed.
Both strategies bear the risk of conflicts in case development has modified code before a bug fix is applied. That's obviously unavoidable and such conflicts need to be resolved "by hand".
Provided only one of the two strategies is strictly applied these should be the only conflicts.
Mixing the two strategies, however, is IMHO no option, as it will/does/did introduce extra conflicts: Say developer A applies a bug fix X to both the release branch and the development trunk. Later developer B applies once bug fix Y that (partly) changes the code that was also modified by bug fix X. Finally, when developer C tries to perform the bulk propagation of bug fixes since the last propagation (i.e., X & Y) from branch to the trunk, a conflict occurs since X had already been applied on the trunk.
Hence, mixing both strategies forces us to spend even more of our precious time and energy on fixing these *avoidable* conflicts by hand. I guess, I can assume that you all agree that this is not desirable.
Since we started with the first release branch a couple of years ago, we have been using strategy (2), summarized as
* all bug-fixes (and only these) must go to the new release branches (and only there) * all new features must go to the development trunks (and only there)
However, since the above (and similar) situation of mixing the strategies with all its consequences has just occurred, I'm wondering whether you're all still "satisfied" with strategy (2), or whether you'd prefer to switch (completely!) to strategy (1).
I'm in favor of sticking to (2), but I'm perfectly fine if we agree on *consequently* switching to (1).
Hence, please hit your keyboard, comment, and vote for either strategy.
Looking forward to hearing your verdict!
Good night,
Stefan
(2) is the only real option given the number of people involved in code production. Too many will (accidently) forget all steps needed.
It would be nice if CVS has an option to discriminate check=ins by separate developers. This gives an option to merge selectively.
Moreover, it gives an option to run testweb over all systems on a person-by-person basis. Given the focused activities, each developer is working in a more-or-less isolated corner, this would ease locking out updates until it has reach a satisfactory quality level.
p.a.boncz wrote:
Hi Stefan,
Thanks for bringing this up.
While I started with (1) for some of the most glaring bugs on Wednesday to ensure that the HEAD has some functionality; I switched to (2) since yesterday.
Peter
Message: 2 Date: Fri, 10 Nov 2006 00:39:08 +0100 From: Stefan Manegold Stefan.Manegold@cwi.nl Subject: [Monetdb-developers] Branches, Checkins & Propagation To: monetdb-developers@lists.sourceforge.net Message-ID: 20061109233908.GA13905@corona.ins.cwi.nl Content-Type: text/plain; charset=us-ascii
Esteemed fellow developers,
having two tightly related branches --- the release branch and the development trunk --- give us the opportunity to clearly and conveniently isolate new "progressive" developments on the development trunk from "conservative" code consolidation and bug fixing on the release branch.
Unfortunately, also this medal has a second side: to make the development trunk benefit from the code consolidation and bug fixes on the release branch either (1) *each* of the respective changes has to be checked in twice (by *each* developer), or (2) the checkins to the branch are *in bulk* (aka. "automa[tgn]ically") propagated from the release branch to the development trunk on an (ir?)regular basis or on need/request.
(1) has the advantage that all bug fixes are "instantly" available in the development trunk, too, but comes at the cost of double checkins and bears the risk of "forgetting" one. (2) keep all developers from extra work and -responsibility, but has the disadvantage that the availability of bug fixes in the development trunk is delayed.
Both strategies bear the risk of conflicts in case development has modified code before a bug fix is applied. That's obviously unavoidable and such conflicts need to be resolved "by hand".
Provided only one of the two strategies is strictly applied these should be the only conflicts.
Mixing the two strategies, however, is IMHO no option, as it will/does/did introduce extra conflicts: Say developer A applies a bug fix X to both the release branch and the development trunk. Later developer B applies once bug fix Y that (partly) changes the code that was also modified by bug fix X. Finally, when developer C tries to perform the bulk propagation of bug fixes since the last propagation (i.e., X & Y) from branch to the trunk, a conflict occurs since X had already been applied on the trunk.
Hence, mixing both strategies forces us to spend even more of our precious time and energy on fixing these *avoidable* conflicts by hand. I guess, I can assume that you all agree that this is not desirable.
Since we started with the first release branch a couple of years ago, we have been using strategy (2), summarized as
- all bug-fixes (and only these) must go to the new release branches (and only there)
- all new features must go to the development trunks (and only there)
However, since the above (and similar) situation of mixing the strategies with all its consequences has just occurred, I'm wondering whether you're all still "satisfied" with strategy (2), or whether you'd prefer to switch (completely!) to strategy (1).
I'm in favor of sticking to (2), but I'm perfectly fine if we agree on *consequently* switching to (1).
Hence, please hit your keyboard, comment, and vote for either strategy.
Looking forward to hearing your verdict!
Good night,
Stefan
On Fri, Nov 10, 2006 at 06:56:48PM +0100, Martin Kersten wrote:
(2) is the only real option given the number of people involved in code production. Too many will (accidently) forget all steps needed.
It would be nice if CVS has an option to discriminate check=ins by separate developers. This gives an option to merge selectively.
Merging happens only for bugfixes from the release branches to the respective deveopment trunks, i.e., merging only developer A's bug fixes but not developer B's bug fixes INHO (1) does not make any sense (once checked into the release branch they are by definition bug fixes; if they don't fix a bug or introduce new one(s), propagating this "faulty" changes to the deveopment trunk actually even increases the "need" ("pressure"?) for the respective developer(s) to check and fix their code!), (2) would increase the administrative overhead for the developer(s) that do the propagation, (3) introduces more risks for error and lost propagations (read: lost fixes).
Moreover, it gives an option to run testweb over all systems on a person-by-person basis. Given the focused activities, each developer is working in a more-or-less isolated corner, this would ease locking out updates until it has reach a satisfactory quality level.
There are IMHO no resources (time, machines, people to actually check the results and act accordingly) to run the testweb (regularly) for each developer that did check in since the last run.
Cetero Censeo: Indevidual (per developer) test runs are possible, triggered by the hand of the very developer (preferably before checkin) --- in fact, they have been possible since *before* automatic testing was introduced.
And I still believe that "distributed" processing (read: testing) is the only reasonable way to check individual changes and hence accurately relate potential problems to the very changes that cause (or at least trigger) them.
*Centralized* per-developer testing simply creates a(n other) bottleneck.
Stefan
p.a.boncz wrote:
Hi Stefan,
Thanks for bringing this up.
While I started with (1) for some of the most glaring bugs on Wednesday to ensure that the HEAD has some functionality; I switched to (2) since yesterday.
Peter
Message: 2 Date: Fri, 10 Nov 2006 00:39:08 +0100 From: Stefan Manegold Stefan.Manegold@cwi.nl Subject: [Monetdb-developers] Branches, Checkins & Propagation To: monetdb-developers@lists.sourceforge.net Message-ID: 20061109233908.GA13905@corona.ins.cwi.nl Content-Type: text/plain; charset=us-ascii
Esteemed fellow developers,
having two tightly related branches --- the release branch and the development trunk --- give us the opportunity to clearly and conveniently isolate new "progressive" developments on the development trunk from "conservative" code consolidation and bug fixing on the release branch.
Unfortunately, also this medal has a second side: to make the development trunk benefit from the code consolidation and bug fixes on the release branch either (1) *each* of the respective changes has to be checked in twice (by *each* developer), or (2) the checkins to the branch are *in bulk* (aka. "automa[tgn]ically") propagated from the release branch to the development trunk on an (ir?)regular basis or on need/request.
(1) has the advantage that all bug fixes are "instantly" available in the development trunk, too, but comes at the cost of double checkins and bears the risk of "forgetting" one. (2) keep all developers from extra work and -responsibility, but has the disadvantage that the availability of bug fixes in the development trunk is delayed.
Both strategies bear the risk of conflicts in case development has modified code before a bug fix is applied. That's obviously unavoidable and such conflicts need to be resolved "by hand".
Provided only one of the two strategies is strictly applied these should be the only conflicts.
Mixing the two strategies, however, is IMHO no option, as it will/does/did introduce extra conflicts: Say developer A applies a bug fix X to both the release branch and the development trunk. Later developer B applies once bug fix Y that (partly) changes the code that was also modified by bug fix X. Finally, when developer C tries to perform the bulk propagation of bug fixes since the last propagation (i.e., X & Y) from branch to the trunk, a conflict occurs since X had already been applied on the trunk.
Hence, mixing both strategies forces us to spend even more of our precious time and energy on fixing these *avoidable* conflicts by hand. I guess, I can assume that you all agree that this is not desirable.
Since we started with the first release branch a couple of years ago, we have been using strategy (2), summarized as
- all bug-fixes (and only these) must go to the new release branches (and only there)
- all new features must go to the development trunks (and only there)
However, since the above (and similar) situation of mixing the strategies with all its consequences has just occurred, I'm wondering whether you're all still "satisfied" with strategy (2), or whether you'd prefer to switch (completely!) to strategy (1).
I'm in favor of sticking to (2), but I'm perfectly fine if we agree on *consequently* switching to (1).
Hence, please hit your keyboard, comment, and vote for either strategy.
Looking forward to hearing your verdict!
Good night,
Stefan
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
participants (3)
-
Martin Kersten -
p.a.boncz -
Stefan Manegold