On Wed, Jan 24, 2018 at 2:33 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> > > > On Jan 24, 2018, at 1:56 PM, Gary Gregory <garydgreg...@gmail.com> > wrote: > > > > On Wed, Jan 24, 2018 at 1:18 PM, Ralph Goers <ralph.go...@dslextreme.com > > > > wrote: > > > >> A vote can’t override a veto of a code commit. > >> > > > > I'm trying to get things to move along toward some kind of workable > > solution we can all live with. Why are you talking about procedure? It > just > > feels obstructionist :-( > > > > You can view it either way. I look at your position of insisting the > stuff stay in the main build as being obstructionist on the one hand and > creating a bloated mess on the other. > > I’ve been complaining about the build for at least a year and finally feel > the issue needs to be forced. Hi All, But complaining is not achieving anything. Vetoing commits is not achieving anything. It's not a solution :-( I am hoping for a concrete solution we all like. Right now we have a monorepo. I say that since log4j-tools has never been released, forgotten, orphaned. log4j-plugins is EMPTY. I'm fine with a monorepo, the advantages are huge. Someone's going to do a release once in a while and it takes time. I do releases in Apache Commons all the time, less often in Apache HttpComponents, so I get it, it's a time suck no matter what. Our builds at work take anywhere from 15 minutes to... hours and hours. In the grand scheme of things Log4j is not a long build IMO at 25-30 minutes for 'mvn clean install'. With a monorepo and more and more modules, we can slice and dice it with profiles to release modules in batches if you like. That's what I'd do, but I want us to get to a consensus. I'm not sure how to get there. Imagine I start an email thread that says [VOTE] or [POOL] Add log4j-mongodb3 to the repo and there are more +1s than -1s, then what? Thank you, Gary > Plus, I see us keep adding modules for things that are not related to > what, in my opinion, is the main purpose of the main repo - to build a Java > logging framework that meets the vast majority of users needs. Other > things, like Mongo appenders, are esoteric add-ons that don’t belong there. > Over time I can see this growing to outlandish proportions as we keep > adding things that allow you to integrate with whatever the latest thing > is. To be honest, I am not sure why we don’t have Appenders that write to > Solr, ElasticSearch, or any/every one of the other things listed at > http://nosql-database.org/ <http://nosql-database.org/>. I have no > problem with those integrations but they have no business being in the main > build. I just don’t see how you could possibly believe that having > integrations with all those components in the main build would be a good > thing. > > This discussion does make me wonder how often you perform a full build. I > found it telling that your guidance in the pull request left off running a > full build to detect whether the fix broke anything. As I have said before, > I almost always run a full build before I commit. Based on issues I’ve > found in the past with some of your commits I am pretty sure you don’t do > this, which is why you probably don’t consider this to be as big a problem > as I do. > > > Ralph > >
