There has obviously been some serious discussion about these topics. We're not going to come to a total agreement on this. I propose:
- We have a committers-only vote in the "Enums and Custom Levels" thread on whether to make Level an extensible enum. - AFTER having that vote, we have a committers-only vote in this thread on whether to add these three levels. - We only roll back this revision AFTER the second vote is complete and IF the vote rejects the new levels. Nick On Jan 23, 2014, at 7:58 AM, Paul Benedict wrote: > On Thu, Jan 23, 2014 at 11:54 AM, Scott Deboy <scott.de...@gmail.com> wrote: > We don't need to scuttle the new levels to support extensible levels. > > > Of course. The two things are not technically related. That's not what this > is about, though. Since there are camps for and against the new levels, I was > hoping the "extensible enum" feature would bring about a compromise. > > > Gary's change is essentially a 'usability enhancement' - if anything > close to 80% of the folks who might want custom levels can use new > built-in levels, that's an API win in my book. Custom levels help the > other 20%, and I'm supportive of that. > > Also please keep in mind this doesn't really add to our maintenance > burden, which I think may be contributing to the concern about adding > new levels. Gary already did the heavy lifting, and the change to > something other than an enum for levels would just be a bit more work > because of this addition. > > Scott > > On 1/23/14, Paul Benedict <pbened...@apache.org> wrote: > > Let's not lose sight why the "extensible enum" discussion occurred. > > Speaking solely for myself, I am not fond of the new logging levels; but I > > don't want the framework from preventing them. The intention behind this > > proposal was to get agreement by scuttling the new levels but allowing > > anyone to add them in their own private code. > > > > > > Paul
