Re: A question (or two) of procedure, etc.
On 09/06/12 23:00, Martin Sebor wrote: Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). We've done most work on 4.2.x for historical reasons. I think a better strategy is to develop, as you suggest, on trunk which has the least restrictive commit policy, and merge changes out to the more restrictive branches as appropriate. If open to voting, I am for trunk first, branches later. Liviu
Re: A question (or two) of procedure, etc.
Many projects have CTR on trunk and RTC (based on trunk revisions) to branch. This works well. On Sep 7, 2012, at 7:40 AM, Liviu Nicoara nikko...@hates.ms wrote: On 09/06/12 23:00, Martin Sebor wrote: Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). We've done most work on 4.2.x for historical reasons. I think a better strategy is to develop, as you suggest, on trunk which has the least restrictive commit policy, and merge changes out to the more restrictive branches as appropriate. If open to voting, I am for trunk first, branches later. Liviu
Re: A question (or two) of procedure, etc.
We should remember that there are a number of Jira issues that we fixed on 4.2.x but haven't merged out to 4.3.x or trunk. The idea behind the current process (4.2.x - 4.3.x - trunk) was to be able to simply merge the branches in bulk, as opposed to an fix at a time. Unfortunately, we ran into some Subversion issues that made it a huge pain. IIRC, Travis did it at least once so he might still remember the details. Before we change the process, it might be a good idea to go through the Jira issues (I think they are resolved but not Closed), commit the 4.2.x fixes to 4.3.x and trunk, and close them. That way we won't have to wonder what fixes are where. Going forward, to avoid this mess, I would suggest we make an effort to commit fixes wherever necessary at the same time instead of delaying it until some time in the future. Martin On 09/07/2012 05:40 AM, Liviu Nicoara wrote: On 09/06/12 23:00, Martin Sebor wrote: Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). We've done most work on 4.2.x for historical reasons. I think a better strategy is to develop, as you suggest, on trunk which has the least restrictive commit policy, and merge changes out to the more restrictive branches as appropriate. If open to voting, I am for trunk first, branches later. Liviu
Re: A question (or two) of procedure, etc.
On 09/07/12 10:54, Martin Sebor wrote: We should remember that there are a number of Jira issues that we fixed on 4.2.x but haven't merged out to 4.3.x or trunk. The idea behind the current process (4.2.x - 4.3.x - trunk) was to be able to simply merge the branches in bulk, as opposed to an fix at a time. Unfortunately, we ran into some Subversion issues that made it a huge pain. IIRC, Travis did it at least once so he might still remember the details. That would be very helpful to know. Going forward, to avoid this mess, I would suggest we make an effort to commit fixes wherever necessary at the same time instead of delaying it until some time in the future. Got it. Liviu
Re: A question (or two) of procedure, etc.
Liviu Nicoara nikko...@hates.ms writes: What is the latest policy in what regards trivial fixes, e.g., the volatile qualifier for the max var in LIMITS.cpp we discussed earlier, etc.? It seems excessive to create a bug report for such issues. My advice based on some observations with other projects, is that in these cases we go just go on and apply fix. Non invasive code quality improvements over the codebase should be promoted not hindered. More risky patches, should be discussed on the list, the ones that needs either serious changes, attention, re-factoring, feature or fixes that may break something should be logged in Jira. So I vote for keeping the changes as lightweight as possible, and avoid extra bureaucracy if it makes sense. This assumption is based that developers here trust their selves, and run the tests often. I'm not subscribed to the commit list here, but if I do - I usually follow people's changes and assume that developers do read commit lists. So the general consensus from my experience with other project was: not sure - ask. That's my experience, also I don't have full rights to express my opinion right now about stdcxx. Also, IIUC from reading previous discussions, forward and backward binary compatible changes go in 4.2.x, followed by merges to 4.3.x and trunk. Am I getting this right? Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on Apache (Jenkins) is anybody building on HP-UX, AIX, etc.? Thanks. Liviu -- Wojciech Meyer http://danmey.org
Re: A question (or two) of procedure, etc.
On 09/06/12 14:37, Wojciech Meyer wrote: Liviu Nicoara nikko...@hates.ms writes: What is the latest policy in what regards trivial fixes, e.g., the volatile qualifier for the max var in LIMITS.cpp we discussed earlier, etc.? It seems excessive to create a bug report for such issues. [...] So I vote for keeping the changes as lightweight as possible, and avoid extra bureaucracy if it makes sense. This assumption is based that developers here trust their selves, and run the tests often. I'm not subscribed to the commit list here, but if I do - I usually follow people's changes and assume that developers do read commit lists. Makes sense. Thanks. So the general consensus from my experience with other project was: not sure - ask. That's my experience, also I don't have full rights to express my opinion right now about stdcxx. I sure hope we can have totally open (civilized) discussions going forward. :) Also, IIUC from reading previous discussions, forward and backward binary compatible changes go in 4.2.x, followed by merges to 4.3.x and trunk. Am I getting this right? Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). Right... I saw some discussions from a while back about active development on 4.2.x with integration to other branches as dictated by compatibility (e.g., integrating 4.2.x - 4.3.x and 4.2.x - 4.2.1), and reintegration to trunk as needed. I am not looking to change any such policy just wanna make sure I am not messing something up. Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on Apache (Jenkins) is anybody building on HP-UX, AIX, etc.? Thanks. Liviu
Re: A question (or two) of procedure, etc.
Trivial fixes should just be fixed... the normal expectation is that bug reports are for non-trivial bugs or for trivial (and non-trivial) bugs reported from the outside. If a committers sees a bug, just go ahead and fix it, and document the fix in a commit log, changefile, etc ;) On Sep 6, 2012, at 2:06 PM, Liviu Nicoara nikko...@hates.ms wrote: What is the latest policy in what regards trivial fixes, e.g., the volatile qualifier for the max var in LIMITS.cpp we discussed earlier, etc.? It seems excessive to create a bug report for such issues. Also, IIUC from reading previous discussions, forward and backward binary compatible changes go in 4.2.x, followed by merges to 4.3.x and trunk. Am I getting this right? Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on Apache (Jenkins) is anybody building on HP-UX, AIX, etc.? Thanks. Liviu
Re: A question (or two) of procedure, etc.
Anyone is welcome to express their opinion here, especially if you are or have in the past contributed to the project. The weight of the opinion is (or should be) commensurate to the value of the contributions. I think the ASF calls this Meritocracy. I made the stdcxx process increasingly more formal as I learned from my own past mistakes that a loose process makes it harder to track changes and find the root cause of the problems they sometimes introduce. In practical terms, I've made an effort to have an issue, with a test case if possible, for every change made to the code, and commit a regression test into the test suite for every bug fix. FWIW, in my day to day job, this is a requirement. Cisco doesn't make a change to its code without an issue. My team does the same with GCC changes. We find that projects that don't follow this practice as closely (e.g., GNU Binutils), tend to be more difficult for us to work with than those that do. That being said, when it comes to the stdcxx configuration machinery, or to the test suite, I think it's fine to be somewhat less formal. We don't need test cases for problems in configuration tests, or necessarily even test cases reproducing failures in library tests (although small tests can often be more useful than the large tests we have in the test suite). We also don't need tests for makefile bugs. Outside of that, when it comes to changing the library, I do recommend making an effort to create test cases and open issues for all changes. Martin On 09/06/2012 12:37 PM, Wojciech Meyer wrote: Liviu Nicoaranikko...@hates.ms writes: What is the latest policy in what regards trivial fixes, e.g., the volatile qualifier for the max var in LIMITS.cpp we discussed earlier, etc.? It seems excessive to create a bug report for such issues. My advice based on some observations with other projects, is that in these cases we go just go on and apply fix. Non invasive code quality improvements over the codebase should be promoted not hindered. More risky patches, should be discussed on the list, the ones that needs either serious changes, attention, re-factoring, feature or fixes that may break something should be logged in Jira. So I vote for keeping the changes as lightweight as possible, and avoid extra bureaucracy if it makes sense. This assumption is based that developers here trust their selves, and run the tests often. I'm not subscribed to the commit list here, but if I do - I usually follow people's changes and assume that developers do read commit lists. So the general consensus from my experience with other project was: not sure - ask. That's my experience, also I don't have full rights to express my opinion right now about stdcxx. Also, IIUC from reading previous discussions, forward and backward binary compatible changes go in 4.2.x, followed by merges to 4.3.x and trunk. Am I getting this right? Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on Apache (Jenkins) is anybody building on HP-UX, AIX, etc.? Thanks. Liviu -- Wojciech Meyer http://danmey.org
Re: A question (or two) of procedure, etc.
One thing I forgot to mention: we have three active branches, and, for better or worse, most changes tend to get committed to 4.2.x first. It's easy to forget or delay committing the same change to 4.3.x and trunk. Having an issue in Jira serves as a reminder to also commit the change to the other branches. (At least until we start doing development on trunk.) On 09/06/2012 08:36 PM, Martin Sebor wrote: Anyone is welcome to express their opinion here, especially if you are or have in the past contributed to the project. The weight of the opinion is (or should be) commensurate to the value of the contributions. I think the ASF calls this Meritocracy. I made the stdcxx process increasingly more formal as I learned from my own past mistakes that a loose process makes it harder to track changes and find the root cause of the problems they sometimes introduce. In practical terms, I've made an effort to have an issue, with a test case if possible, for every change made to the code, and commit a regression test into the test suite for every bug fix. FWIW, in my day to day job, this is a requirement. Cisco doesn't make a change to its code without an issue. My team does the same with GCC changes. We find that projects that don't follow this practice as closely (e.g., GNU Binutils), tend to be more difficult for us to work with than those that do. That being said, when it comes to the stdcxx configuration machinery, or to the test suite, I think it's fine to be somewhat less formal. We don't need test cases for problems in configuration tests, or necessarily even test cases reproducing failures in library tests (although small tests can often be more useful than the large tests we have in the test suite). We also don't need tests for makefile bugs. Outside of that, when it comes to changing the library, I do recommend making an effort to create test cases and open issues for all changes. Martin On 09/06/2012 12:37 PM, Wojciech Meyer wrote: Liviu Nicoaranikko...@hates.ms writes: What is the latest policy in what regards trivial fixes, e.g., the volatile qualifier for the max var in LIMITS.cpp we discussed earlier, etc.? It seems excessive to create a bug report for such issues. My advice based on some observations with other projects, is that in these cases we go just go on and apply fix. Non invasive code quality improvements over the codebase should be promoted not hindered. More risky patches, should be discussed on the list, the ones that needs either serious changes, attention, re-factoring, feature or fixes that may break something should be logged in Jira. So I vote for keeping the changes as lightweight as possible, and avoid extra bureaucracy if it makes sense. This assumption is based that developers here trust their selves, and run the tests often. I'm not subscribed to the commit list here, but if I do - I usually follow people's changes and assume that developers do read commit lists. So the general consensus from my experience with other project was: not sure - ask. That's my experience, also I don't have full rights to express my opinion right now about stdcxx. Also, IIUC from reading previous discussions, forward and backward binary compatible changes go in 4.2.x, followed by merges to 4.3.x and trunk. Am I getting this right? Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). Also, besides the Linux, FreeBSD, Windows, Solaris builds hosted on Apache (Jenkins) is anybody building on HP-UX, AIX, etc.? Thanks. Liviu -- Wojciech Meyer http://danmey.org
Re: A question (or two) of procedure, etc.
Every project has certain branch strategy, I'm not sure about this so maybe Martin can advice. I prefer to develop on trunk and cherry pick to the other branches avoiding bulk merges (and that's in both directions). We've done most work on 4.2.x for historical reasons. I think a better strategy is to develop, as you suggest, on trunk which has the least restrictive commit policy, and merge changes out to the more restrictive branches as appropriate. Martin
Re: A question (or two) of procedure, etc.
Liviu Nicoara nikko...@hates.ms writes: I sure hope we can have totally open (civilized) discussions going forward. :) Yes I'm also sure we can, thanks :-) -- Wojciech Meyer http://danmey.org
