All: re: SOLR-13452. I’m now coming down on both sides of the issue. My motive here is if this was pushed, even in its current incomplete state, people would have an easier time contributing to the effort. Of course this means I would be asking people to use the gradle build at least on master if at all possible.
There are several assumptions I’m making here: - we can keep running the Ant build as long as necessary. Ant would be our primary build process. The purpose of pushing the current Gradle effort is to make it easier for others to contribute and “just try it”. - There are no conflicts between the Gradle and Ant builds, so we can continue to use Ant as necessary until we make the switch. - people will commit up front to putting some effort into this. I flat guarantee I won’t carry the load alone. If nobody else steps up, I’ll table it. I will volunteer to push fixes from non-committers. — Yes, people can do this already with the gradle_8 branch, it’d just be easier if it was already in the pull. - moving to Gradle as our primary workflow won’t happen until we work out some of the kinks, things like. — running on Jenkins. — Getting the equivalent of “ant server dist” to run. — Getting the ref guide built. — I’m sure other things will crop up. So there are several options, please let me know which one you prefer: 1. do nothing. People can check out the gradle_8 build and work on it. There has been some of this so far, many thanks. 2. merge it into master only. TBD is when we take Ant out of master. 3. merge into both master and 8x. Assuming we can continue to use both, I’m not sure what advantage there is to merging into 8x. This seems like something that should come along with a major version release. 4. wait until it’s feature-complete. Based on the evidence so far, this may be a long time coming. Also, the timing is fungible. I don’t see a downside as long as we can continue to build with Ant. I certainly _do_ see a downside if we have to do everything Ant does immediately after pushing to whatever branches. Erick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
