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
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
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
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
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
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
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,
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
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
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
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
11 matches
Mail list logo
