Breaking our mono repo into a bunch of smaller repo pieces is a recipe for software rot and orphanage IMO.
For example, we have never released out of the tools repo, and I have folks at work at use code from that repo for some internal facing work. Now, I could take the time and do a release of course but... priorities. OTOH, I could have gotten a release for "free" if that code was in the mono repo (I am not advocating to put it back). This email might be better articulated in a call but I am trying to be constructive: I think we can keep our mono repo and develop faster by reorganizing what we have now. I like having everything in one place myself. I am not sure how to actually move folders around to achieve whatever new release cycle/split up we want, but I am sure it is do able. Gary On Fri, Apr 29, 2022, 16:03 Volkan Yazıcı <[email protected]> wrote: > I have raised this issue in the past. I even came up with a proposal on the > repository structure > <https://lists.apache.org/thread/sdv92pw6m9bst8zzn88jyln8z8ozshw3> to be > followed. I am a big proponent of breaking up the logging-log4j2 repository > into multiple ones. The current size of the code base is simply > incomprehensible and slows down the development cycle tremendously due to > excessive compilation and test times. > > *The proposal* > > Let me share the break down I have in mind: > > *logging-log4j2-api* > log4j-1.2-api > log4j-api > > *logging-log4j2* > log4j-bom > log4j-core > log4j-core-its > log4j-gctests > log4j-iostreams > log4j-perf > log4j-plugins > > *logging-log4j2-appender* > log4j-cassandra > log4j-couchdb > log4j-csv > log4j-flume-ng > log4j-mongodb3 > log4j-mongodb4 > log4j-smtp > > *logging-log4j2-appender-jdbc* > log4j-jdbc (?) > log4j-jdbc-dbcp2 (?) > log4j-jpa > > *logging-log4j2-appender-queue* > log4j-jeromq > log4j-jms > log4j-kafka > log4j-redis > > *logging-log4j2-binding* > log4j-jcl > log4j-jpl > log4j-jul > log4j-liquibase > log4j-slf4j18-impl > log4j-slf4j-impl > log4j-to-slf4j > > *logging-log4j2-container* > log4j-docker > log4j-kubernetes > > *logging-log4j2-gui* > log4j-jmx-gui > > *logging-log4j2-jee* > log4j-appserver > log4j-taglib > log4j-web > > *logging-log4j2-layout-json* > log4j-layout-gelf > log4j-layout-jackson > log4j-layout-jackson-json > log4j-layout-jackson-xml > log4j-layout-jackson-yaml > log4j-layout-template-json > > *logging-log4j2-osgi* > log4j-osgi > > *logging-log4j2-spring* > log4j-spring-boot > log4j-spring-cloud-config > > Note that above breakdown contains every available module in master, except > log4j-samples, which has the following sub-modules: > > log4j-samples-loggerProperties (contains 2 very trivial example classes, > log4j-core [tests] contains more comprehensive alternatives) > log4j-samples-flume-remote (flume-specific) > log4j-samples-flume-embedded (flume-specific) > log4j-samples-flume-common (flume-specific) > log4j-samples-configuration (contains 3 very trivial example classes, > log4j-core [tests] contains more comprehensive alternatives) > > I propose removing the log4j-samples module and, if necessary, moving > Flume-related parts to the log4j-flume-ng. > > *The problem with multiple repositories* > > I made this proposal in June 2021. Since then the more my familiarity with > the website and manual generation increased, the less I became inclined to > move forward. I am not much concerned about the increased release labor the > Ralph has mentioned – a majority of these repos will hardly get an update > to warrant a release. Though the fact that current website generation > depends on the presence of these modules to be in the same repository and > with multiple repositories, the manual and source codes will be in > different repositories... These concern me a lot. I think, the steps to > overhaul the project structure should better be in the following order: > > 1. Replace `site` phase (`site` phase won't be needed anymore. Website > will independently be generated in a single step via JBake.) > 2. Rewrite the manual > 3. Migrate to a multi-repo structure (Each repo will have its own > website and manual, ala Maven. Here the code in steps 1 and 2 will be > reused.) > > > > On Wed, Apr 27, 2022 at 1:35 PM Ralph Goers <[email protected]> > wrote: > > > I wouldn’t necessarily want to penalize them. At the same time, I don’t > > think we want a ton of extra repos each of which needs its own release. > > > > Ralph > > > > > On Apr 27, 2022, at 12:26 PM, Piotr P. Karwasz < > [email protected]> > > wrote: > > > > > > Hello, > > > > > > On Wed, 27 Apr 2022 at 11:33, Volkan Yazıcı <[email protected]> wrote: > > > > > >> +1 with moving Cassandra et al. to their own repo > > >> > > > > > > I agree: Cassandra's tests were one of the most common reasons for > > failing > > > CI. > > > Maybe it could share a repository with other database appenders. > > > > > > Piotr > > > > >
