I will vote -0 with reasons I have already expressed in the 'Merge
Request - Temp_ComplexScripts into Trunk' thread.

I hope we can go forward refining this work, along with the rest FOP,
through constructive collaboration, respecting the varied degrees of
experiences, expertises and passion that we can all bring to the
project.

Peter

[1] http://markmail.org/message/ti5233ftlxacau4a

On Fri, Oct 28, 2011 at 3:40 PM, Vincent Hennebert <vhenneb...@gmail.com> wrote:
> This vote was launched while discussion was still going on on the
> mailing list. It would have been good to wait that a consensus is
> reached, which I don’t think has happened yet. What was the urgency to
> launch the vote now?
>
> I haven’t received any answer to my concerns about the following
> metrics:
> • 74 files in the o.a.f.fonts package
> In o.a.f.fonts.truetype.TTFFile:
> • 5502 lines
> • 150+ method declarations
> In the test o.a.f.complexscripts.util.TTXFile:
> • 3449 lines
> • 50+ field declarations
> • 1800 lines in the Handler.startElement method
>
> As it currently is, I believe that the font package will cause serious
> issues when merging other branches, fixing bugs or implementing other
> features.
>
> I don’t see what advantage does merging the Complex Scripts branch to
> trunk bring. Users who are skilled enough to check out a copy of the
> trunk, build it and test it can equally do it on a branch. For the rest
> of them, I don’t think that downloading a nightly build of trunk or
> a build of the branch would make any difference.
>
> ATM Simon is regularly uploading a build of the branch on his personal
> space at people.apache.org. I believe that this is exactly what non
> power users need, and I would be happy to take over this task if he is
> no longer willing to do it.
>
> If trunk is regularly merged to the branch (which I would also happily
> do), then it makes virtually no difference whether one is working on the
> trunk or on the branch.
>
> The new code deliberately ignores established code conventions by
> disabling Checkstyle rules. This makes it inconsistent with the rest of
> the code base and will unnecessarily distract people who try to
> understand it.
>
> I saw some slightly encouraging notes from Glenn that he is prepared to
> do some refactoring work on his code. I urge him to break down the fonts
> package and classes into smaller, more manageable components, and to do
> it as soon as possible.
>
> ATM I don’t believe that this code is maintainable by anyone else but
> Glenn. Therefore I think that merging it to Trunk is a bad idea. I’m not
> willing to provide any support for it at the moment, and the tone of his
> latest messages does certainly not encourage me to get involved in it in
> the future.
>
> Therefore, I’m voting -0.9.
>
> Vincent
>
>
> On 25/10/11 09:31, Simon Pepping wrote:
>> With his latest patch, Glenn Adams wrote:
>>
>> With this latest patch I am satisfied that there is sufficient testing and
>> stability in the CS branch to support its merger into trunk. Therefore, I
>> request that such a merge be accomplished after applying patch 5 to the CS
>> branch.
>>
>> ... snip ...
>>
>> Note that there remains work to be done on CS support, including adding
>> support for:
>>
>>    - additional scripts
>>    - additional output formats
>>
>> At present, support is provided for:
>>
>>    - Arabic, Hebrew, and Devanagari Scripts
>>    - PDF output format
>>
>> I expect that additional support for other scripts and formats will be added
>> over time, either by myself, or other members of the community. However, the
>> absence of support for all complex scripts and all output formats should not
>> be a deterrent to active use of the support already present. It is now a
>> good time to broaden the user community of the CS features, and the best way
>> to do that is to bring it into the trunk at this time.
>>
>> End of quote
>>
>> Following this request, I herewith propose to merge the branch
>> Temp_ComplexScripts into trunk, and launch a formal vote.
>>
>> I vote positive: +1
>>
>> For the rules of voting about code commits, see the project charter,
>> article 11, http://wiki.apache.org/xmlgraphics/ProjectCharter.
>>
>> Simon Pepping
>

Reply via email to