> On Jan 24, 2018, at 3:02 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Wed, Jan 24, 2018 at 2:33 PM, Ralph Goers <ralph.go...@dslextreme.com > <mailto: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.
So your problem is simply that you want someone else to do the work of creating the shells for those projects and don’t want to do the work yourself. If that is all it takes I have no problem with that. As soon as I get Log4j Audit released I plain to release log4j-server. Creating a shell for log4j-plugins won’t take much work. > > I'm fine with a monorepo, the advantages are huge. I see only disadvantages. The advantages you stress are not really there. For example, you continually update versions of dependencies. While that validates we work with the latest release it does nothing to insure we continue to be compatible with the release originally developed for. I could easily argue that dependency versions should only be upgraded when required. > > 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? I would argue that this decision requires consensus, not more +1s than -1s. Unfortunately, the guidelines on what consensus means is less than clear. In some cases it can mean no -1s, in others something over 2/3 majority or more. In general, it is that the “community” is agreeable the outcome. Ralph
