A question (or two) of procedure, etc.

[Liviu Nicoara <ni...@hates.ms>]

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.

[Martin Sebor <ms...@gmail.com>]

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 Nicoara<ni...@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.

[Wojciech Meyer <wo...@googlemail.com>]

Martin Sebor <ms...@gmail.com> writes:

> 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.

Thanks, that sounds sensible.

> 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.

I can understand the reasons, system library programming is not a piece
of cake, and must be taken with a great care. However, IMHO it's more
important for the propriety projects to log everything in bug tracker,
then just in the rcs, within the absence of commercial type of
management. Maybe my opinion is a bit biased (I've never been a real
tech lead so it's difficult to say), but please see below.


> 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.

In my day time job it's also a requirement. At ARM we do put so much
efforts to get the processes right, and no change is allowed without
being logged in the tracker, peer reviewed, validated etc. It makes
sense for the projects kind of compiler, kernel, or system library -
no doubt I fully agree. However, I believe that it has other side of
story, it comes with an overhead, sometimes it's just very difficult to
do anything because it all needs to go through the process. It's really
pleasant feeling (which is perhaps an attribute of open source), when you
just go to the code, feel true confidence, fix the bug and commit. Of
course it makes sense in a certain cases and with the complexity of stdcxx
is just very difficult to feel that true confidence :-)

By looking at what kind bugs Liviu, Stefan, and you have
fixed/discussed, I had an impression that lot of this stuff is tweaking,
and smaller re-engineering work which just takes a lot of time and
experience, and notoriously difficult to get right.

I hope I will also have a taste of stdcxx, perhaps I might look at
something this weekend. I still need to commit (somewhat) the bigger
patches for armcc.

>
> 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.

I fully agree with the test cases and the rest of the paragraph.

It's really good to know your opinion!

Thanks.

--
Wojciech Meyer
http://danmey.org

Re: A question (or two) of procedure, etc.

[Jim Jagielski <ji...@jaguNET.com>]

On Sep 7, 2012, at 7:26 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>    board@
> 
> 2. ASF Projects are, well, ASF projects. They are external
>    adjuncts of corporate projects,

Major typo: It should read: They are NOT external adjuncts of corporate projects.

Re: A question (or two) of procedure, etc.

[Jim Jagielski <ji...@jaguNET.com>]

Just a few points:

 1. No single individual can "make a process more formal". If the
    project itself wants more process, and to make it more formal,
    then all is good. If a single committer decides on his/her
    own to add process *which is not formally required by the
    ASF* then committers are free to discuss and even ignore
    that process. If in doubt, ping others and, eventually,
    board@

 2. ASF Projects are, well, ASF projects. They are external
    adjuncts of corporate projects, and so having processes
    "flow" into the ASF project due to "requirements" from
    one's employer is *definitely* a NoNo.

With all that said, Martin's process flow is a Good One and
should the PMC decide it is the official procedure to follow,
then the project would be the better for it.

On Sep 6, 2012, at 10:36 PM, Martin Sebor <ms...@gmail.com> 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 Nicoara<ni...@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.

[Martin Sebor <ms...@gmail.com>]

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 Nicoara<ni...@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.

[Wojciech Meyer <wo...@googlemail.com>]

Liviu Nicoara <ni...@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

Re: A question (or two) of procedure, etc.

[Liviu Nicoara <ni...@hates.ms>]

On 09/06/12 14:37, Wojciech Meyer wrote:
> Liviu Nicoara <ni...@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.

[Jim Jagielski <ji...@jaguNET.com>]

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 <ni...@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.

[Liviu Nicoara <ni...@hates.ms>]

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.

[Martin Sebor <ms...@gmail.com>]

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.

[Liviu Nicoara <ni...@hates.ms>]

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.

[Martin Sebor <ms...@gmail.com>]

> 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.

[Wojciech Meyer <wo...@googlemail.com>]

Liviu Nicoara <ni...@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.

[Jim Jagielski <ji...@jaguNET.com>]

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 <ni...@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
>