I’m fine with Option 2. Putting my project manager hat on, I’d really like to see a central list or Jira issues of the things we want to make sure to do before we can turn off Ant. The list/sub-tasks could be compiled after it’s merged to master, but it would be nice if we could approach this in a coordinated way so we’re all able to figure out quickly what remains - I think we’ll have a higher chance of faster success that way. Hopefully also people would sign up for the things that they will volunteer to drive to completion instead of hanging back because they aren’t sure what needs to be done.
Dawid and I worked on the Ref Guide transition to Gradle in a separate branch and it’s either finished or very close to it IMO. It includes the PR I put up last night to remove the PDF build tasks. I just need to merge it into the main Gradle branch (jira/SOLR-13452_gradle_8), which I will try to do by tomorrow. Cassandra On Nov 6, 2019, 3:07 PM -0600, David Smiley <david.w.smi...@gmail.com>, wrote: > Option 2. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > > On Wed, Nov 6, 2019 at 12:36 PM Erick Erickson <erickerick...@gmail.com> > > wrote: > > > 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: dev-unsubscr...@lucene.apache.org > > > For additional commands, e-mail: dev-h...@lucene.apache.org > > >
