stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <mse...@gmail.com>
Subject Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Date Sat, 04 Feb 2012 17:17:13 GMT
Stefan,

Smaller, independent patches are better for a few reasons: they
are easier to review, and easier to back out if they cause trouble.
In addition, they'll give you the opportunity to get comfortable
with the process. After you submit a few good patches over a period
of time we'll also be able to get you commit privileges. Since none
of the rest of us has the time to contribute patches of our own,
adding a committer who does is essential to keep the project alive.

Martin

PS For tracking purposes, it would be ideal to start by opening
a new Jira issue for each patch you plan to submit.

On 02/04/2012 08:15 AM, Stefan Teleman wrote:
> OK I will start submitting patches at stdcxx. Breaking them up into
> smaller chunks will increase the number of patches though. :-) Stay
> tuned.
>
> I don't intend to push changes to the build system - we use gmake to
> build stdcxx at Oracle.
>
> --Stefan
>
> ----
>
> On Fri, Feb 3, 2012 at 16:48, Andrew Black<Andrew.Black@roguewave.com>  wrote:
>> Like Farid, I too am willing to help process patches for review and
>> submission. Once a track record has been established, someone on the PMC
>> would likely raise a motion to designate you as a committer, as defined at
>> http://stdcxx.apache.org/#committers . This would allow you to make changes
>> directly to subversion without assistance. Do note that in order to be
>> designated as such, you will need to have a Contributor License Agreement (
>> http://www.apache.org/licenses/icla.txt ) on file with the Apache
>> foundation. If you are being paid to perform this work, the company you work
>> for will likely need to have a Corporate Contributor License Agreement (
>> http://www.apache.org/licenses/cla-corporate.txt ) on file.
>>
>> If we are trying to revitalize this project, there are a few things I
>> personally would/would not like to see in the patches:
>> * I would not like to see major changes to the build infrastructure at this
>> time. One of the goals of this project has been portability, and this
>> includes the build infrastructure. My understanding is that gmake is
>> considered to be more portable than some of the alternatives (cmake, ant).
>> * I would like to see tests added to verify any library changes. Ideally the
>> new tests will pass on most platforms, though we don't currently have an
>> automated test mechanism in place. If any existing tests are incorrect,
>> commentary for the change about why they are broken would be appreciated.
>> * Changes destined for the 4.2.x branch should have forwards and backwards
>> binary compatibility.
>> * Changes destined for the 4.3.x branch should have backwards source
>> compatibility.
>>
>> --Andrew Black
>>
>>
>> On 02/03/2012 03:04 PM, Farid Zaripov wrote:
>>>
>>> On 03.02.2012 1:52, Stefan Teleman wrote:
>>>>
>>>> 2. Someone with stdcxx commit privileges should be part of this
>>>> reunification (for obvious reasons). It is very discouraging to submit
>>>> patches knowing full well and ahead of time that they will never make
>>>> it anywhere. Perhaps the process of submitting patches could be
>>>> somewhat less of a "process". Just my 0.02. --Stefan
>>>
>>>
>>>     Stefan, if you split the all your patches to a set of small finalized
>>> changes and submit them through a set of corresponding issues in JIRA, I
>>> promise I will process them all one by one.
>>> At the moment I don't see any issues, reported by you. Sorry, but
>>> process is a process.
>>>
>>> Farid.
>>>
>>
>
>
>


Mime
View raw message