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<[email protected]> 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.
