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