I want to move forward with Glenn's work. As you wrote, it is an important addition to FOP which we cannot let go unused.
I feel that the CHECKSTYLE comments are clear, and allow us to take any action later that we require. They could be harmful if we would feel that further work would have to be done, but actually is not done. Then the comments will hide that situation. But that is up to us. I understand that Glenn wants to work from a clean checkstyle and javadoc situation, which allows him to have a clear view on the consequences of his own actions. It is a fairly puristic stand point, but I appreciate that he feels that he needs it to do a good job. After all, his is quite a far-reaching code change. We do need to retain a few deprecated methods, as they are deprecated parts of the public API, of which you are one of the users. It would be good if we could document the new alternatives, and fix a time when they can be removed. Perhaps at release 1.1, as they were already deprecated at release 1.0? We will see how the other team members stand in this issue, but I will be thoroughly disappointed if we cannot move forward efficiently with this work. Simon On Fri, Aug 13, 2010 at 04:47:07PM +0200, Jeremias Maerki wrote: > I've mentioned the deprecated methods in my reply to Vincent. I'll > restore two instances which can be handled later. At least one is kind > of important as long as I haven't done a Barcode4J 2.1 release (which is > long overdue). > > Do I understand you correctly, Simon, that you're OK to leave the CS > comments for now and revisit later? I could live with that, too. If I > read Vincent and Chris correctly, they are not absolutely against having > the CS comments for now although they are not at all happy about them. > Please correct me if I got that wrong! Removing them later is always a > possibility. I'm not too happy to disregard a majority opinion > especially since Glenn is not yet a committer. But I guess leaving the > CS comments for now allows us to continue and we can still reduce (or > get rid of) the CS comments later. > > I know I'm currently behaving like a flag in the wind but I'm really a > bit clueless what the best way is since we do not have a consensus right > now. But I'd like to continue here as quickly as possible. I didn't get > to handle the patch today due to a support request (FOP go boom with PDF > sizes over 2GB). But the weather doesn't look to good here during the > weekend so I may be able to get this done tomorrow. > > On 13.08.2010 14:40:55 Simon Pepping wrote: > > Glenn, > > > > 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
