What if the CS* comments are removed in trunk, so the committers are happy, but 
accepted in the branch, so Glenn can work as he wants to? Not a perfect 
solution, but maybe an acceptable compromise, as long as somebody removes the 
comments prior to merging the branch back into trunk?


Georg Datterl

------ Kontakt ------

Georg Datterl

Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg

HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert

Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20


Weitere Mitglieder der Willmy MediaGroup:

IRS Integrated Realization Services GmbH:    www.irs-nbg.de
Willmy PrintMedia GmbH:                            www.willmy.de
Willmy Consult & Content GmbH:                 www.willmycc.de

-----Ursprüngliche Nachricht-----
Von: Simon Pepping [mailto:spepp...@leverkruid.eu]
Gesendet: Freitag, 13. August 2010 14:41
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: [Bug 49733] [PATCH] resolve compilation, checkstyle, javadoc 
warnings (a proposal for next steps)


On Fri, Aug 13, 2010 at 05:07:52PM +0800, Glenn Adams wrote:
> In any case, we now appear to be at a juncture where one of the following
> options may be implemented:
> (1) leave the CS* comments in place, but DON'T change the checkstyle rules
> AT THIS TIME (but reserve option to change later)
> (2) remove the CS* comments, but DON'T change the checkstyle rules, leaving
> at least 279 warnings/errors to be produced;
> (3) remove the CS* comments, but DO change the checkstyle rules AT THIS TIME
> such that none of the CS* comments are required
> I prefer option #1.
> I cannot accept option #2, since it leaves a large number of reported
> warnings, thus negating my primary goal in creating this patch.
> I can live with option #3, although it requires editing around 100 files to
> remove the CS* comments. And it also requires modifying the checkstyle rule
> set, and in some cases removing or weakening potentially useful rules.

I would prefer something like option #2, and so do a few other
committers. I understand this produces an unacceptable working mode
for you. I can live with that, and we can review the CHECKSTYLE
comments later in an effort to make further improvements.

I would like to hear Jeremias' comment on the removal of the
deprecated methods. Deprecated methods are a fact of life.


Simon Pepping
home page: http://www.leverkruid.eu

Reply via email to