I’m still not convinced that moving the items that Ralph enumerated out of core will make a significant difference in the time it takes to do a release (I believe other measures will be more effective), but fine.
If Ralph wants this as a precondition to continue to perform the Log4j2 releases then I can accept that. I’m not planning to start doing the Log4j2 releases and I’m grateful that others are willing to do so. However, an important question that needs to be answered before we do this is: how do we detect when changes in the main Log4j2 project broke one of the plugins when they live in another repo? Creating a plugin API is one option but this will take time to design, develop and test. One possible alternative: Can we set up a continuous integration service that builds the main project together with the plugins subproject? (We probably need this regardless of whether there is a plugin API or not.) I’m open to other solutions but we do need some process in place to detect breaking changes. FYI I strongly feel the perf module should stay in the main project/repo or it won’t be useable. Finally, I think breaking up log4j-plugins into many separate repos is not a good idea. It may sound nice on the surface but the overhead is large. Are the people pushing for the repo-per-module idea willing to do the release work for these plugins? And is everyone else willing to review and vote for 10 plugin releases instead of just one? And integrate 10 websites instead of one? (Shameless plug) Every java main() method deserves http://picocli.info > On Jan 25, 2018, at 9:45, Matt Sicker <boa...@gmail.com> wrote: > > I'm going to sum up my view here: if we split up repos to include plugins > that depend on log4j-core, then we first need to define and release a > stable plugin API. If we can't guarantee BC for plugins, then there's no > realistic way to both split out additional plugins and have them be > officially endorsed plugins. If said plugins were completely outside Apache > (e.g., personal GitHub pages), then it wouldn't be as strict. > > Also, I find it hard to believe that Google really uses a monorepo anymore. > Such an idea wouldn't work too well with software that isn't continuously > released. > > I suppose that's an alternative: I'd be open to splitting up repos however > desired if releases were continually published to avoid version number > synchronisation efforts, but I'm not so sure how well that meshes with the > Apache Way for releasing software.
