my apologies if my statement appeared to be a "rant", as it was not intended
as such;

perhaps my emphasis was an exaggeration, but if one goes through the trouble
to add build rules for style checking, bug finding, and code quality
reporting, then it does appear odd to ignore them, which was my reaction to
the current code base and vincent's response;

i admit that i prefer a zero warning policy, and i have attempted at every
opportunity to introduce or enforce such policy on the many dev projects
I've managed or participated in over four decades; in general, i find it
helps me and other devs, particularly as a way of finding new noise we are
introducing; if there is already a lot of noise in the system, it is easy to
ignore new noise, which is precisely what i would like to avoid in my own
contributes: contributing to the noise level;

note that i am not arguing for or against a specific set of policy rules,
just that whatever they are, they get implemented and enforced, while
knowing at the same time that every rule has exceptions, and that mechanisms
to provide filtering adequately address this point; furthermore, arguing
over which a particular exception is justified or not can become a great
waste of time; as I've stated previously, if a contributor or committer has
made the conscious choice to disable a warning, then I'm happy to accept
their judgement, as long as it is done in a thoughtful way, and not merely
as a way of ignoring rules;

if the majority of committers feel it best not to patch these warnings and
move on from there, then i'll readily submit to that consensus; my hope,
however, is that this contribution can positively contribute to FOP and the
community, so it is natural that I would prefer it not be delayed for some
unknown process to create a "new consensus" on style rules;

regards,
glenn

On Tue, Aug 10, 2010 at 8:07 PM, Jeremias Maerki <d...@jeremias-maerki.ch>wrote:

> I kind of agree with Glenn that we have a de-facto agreement on the
> Checkstyle rules. We've adjusted them in the past and there's no reason
> why we can't change it in the future. If Glenn's patch gets the issue
> count down significantly so we can start to enforce the rules, then I'm
> fine with it. But I don't doubt that the checkstyle file may profit from
> some fine-tuning.
>
> Right now, I have a couple of things that I need to commit and I
> basically don't dare commit them as people may come screaming at me
> in that case. So I want this resolved quickly. Vincent, are going to
> process the patch? I have to do a few things first, but if you don't
> have a chance to handle it by then, I'll take a look myself.
>
> What I have a little problem with is Glenn's rant in the last paragraph.
> Some Apache project don't even have Checkstyle rules. Furthermore,
> having no Checkstyle issues doesn't equal high quality. High quality is
> the result of an open process of developing software (The Apache Way).
> There are no rules that we have to implement any particular technical
> measures. But I'm not saying that Checkstyle doesn't help improve
> quality. Then what is "high quality"? And we have to acknowledge that
> over time, many people with different skills and coding styles have been
> working on FOP and limited resources don't always allow the maximum
> possible.
>
> On 10.08.2010 13:13:08 Glenn Adams wrote:
> > Vincent,
> >
> > I disagree with your proposed delay. First, there is an established
> > consensus on the rules, namely those that are in the existing
> > checkstyle-5.0.xml file. The reason they are the current consensus is
> that
> > they are there in the trunk, and nobody has objected to them. I do not
> care
> > to object to them at this time, and merely applied them as they stand.
> >
> > I did nothing to change those rules in my patch, and saying that you wish
> to
> > effectively delay incorporating the patch until there is a consensus
> about
> > what is there already appears rather odd, if not counterproductive.
> >
> > What is most important overall is to eliminate all warnings. Period. As
> fast
> > as possible. My patch does that, so please commit it without delay. We
> can
> > then, over time, decide if the existing rules are overly conservative or
> > overly liberal. But that is not going to be a useful way to spend our
> time,
> > it is much better to just use what is there, and when something goes
> outside
> > of that set, there are adequate mechanisms to deal with it, which I
> > described in my patch.
> >
> > The alternative is to merely continue to propagate the current warnings.
> > Frankly, I was and am very surprised at the apparent lack of
> particularity
> > with respect to treatment of warnings. One of the six principles of "The
> > Apache Way" is "consistently high quality software". For me, every
> warning
> > is a black mark against quality. Let's not continue to propagate this
> state
> > of affairs. Now that FOP 1.0 has been released is the best time to move
> > forward, so why delay now?
> >
> > Regards,
> > Glenn
> >
> >
> > On Tue, Aug 10, 2010 at 6:34 PM, <bugzi...@apache.org> wrote:
> >
> > > https://issues.apache.org/bugzilla/show_bug.cgi?id=49733
> > >
> > > --- Comment #5 from Vincent Hennebert <vhenneb...@gmail.com>
> 2010-08-10
> > > 06:34:29 EDT ---
> > > Hi Glenn,
> > >
> > > Thanks for your patch. However, as I said we need to agree on a
> > > project-wide
> > > Checkstyle configuration first. Before enforcing a no-warning policy it
> is
> > > necessary to reach consensus among all the developers on a set of rules
> > > that
> > > everyone is happy to follow.
> > >
> > > We'll have a look at your patch once this is done. Meanwhile, I'll look
> at
> > > the
> > > parts that fix compilation warnings.
> > >
> > > Thanks,
> > > Vincent
> > >
> > > --
> > > Configure bugmail:
> > > https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
> > > ------- You are receiving this mail because: -------
> > > You reported the bug.
> > >
>
>
>
>
> Jeremias Maerki
>
>

Reply via email to