What I had in mind was as follows: 1. after the cleanup/warnings patch is applied to trunk, it should be merged into the complex scripts branch (which still does not have the complex scripts patch applied); 2. I merge the head of the updated complex scripts branch with my existing patch, then replace that patch with a new one that applies immediately to the complex scripts branch that contains the cleanup merge; 3. this new patch is immediately applied to the complex scripts branch without further review, thus making it available for 3rd parties to use with less effort than having to go through the patch process themselves; 4. i will post new patches to the HEAD of the complex scripts branch over time in order to complete the work, and these new patches should be applied immediately without pre-review; i.e., CTR policy should apply; 5. as the functionality in the branch becomes completed and the FOP community becomes comfortable with it, the committers can decide when it is ready to merge into the trunk, and perform whatever additional review is necessary to reach a comfort level to facilitate that merge;
Independently, someone may choose to nominate me for committer status prior to the above process being completed, which may ease the burden on other committers to finish this feature. Regarding code status, my iCLA applies for all of my contributions, so there is no issue there as far as I'm aware. Depending on how well the above process moves along, I may or may not make use of a GIT repo to help manage my working set, in which case I may make it available via a public GIT server so that interested parties may observe internal state changes in this working set. G. On Fri, Aug 13, 2010 at 4:53 PM, Simon Pepping <spepp...@leverkruid.eu>wrote: > I wonder how we are going to organize the application and review of > the Complex Script Support work. Glenn has now submitted a patch and > we have created a branch for this work. > > We can apply the patch and then make comments or request > changes. Glenn does further work and reacts to our comments and > requests. Does he then give us a patch agains the HEAD revision of the > branch? That would work fine for us. > > If it would not be possible for Glenn to produce patches against the > HEAD revision of the branch, should we then do something with git? I > notice that Glenn mentions he uses git. I am not sure how that would > help us produce patches against the HEAD revision of the branch, but I > presume that a distributed versioning system would at least make it > easier. > > Regarding the application of the patches, I am in favour of applying > the patches as soon as we receive them. It makes the code available to > many users. We could even build and make available a jar file from the > branch, which would allow more users to install and test it. I know > for sure that more users in the Arabic world would like to use this > functionality. > > Application of the patches does not imply our endorsement. It requires > that the code is donated to the ASF, which is guaranteed by Glenn's > submission to the ASF Bugzilla and his CLA. Basis Technology > Corporation could augment this with their CCLA, but that is not > required. It also requires that there are no IP problems with the > code, but basically Glenn assures that by his CLA and submission of > the patch. > > Simon > > -- > Simon Pepping > home page: http://www.leverkruid.eu >
