+1 to option 2 On Thu, Nov 7, 2019 at 6:23 PM David Smiley <[email protected]> wrote:
> > Doing 2 doesn’t stop us going to 3 soon if we want. Easier to fix/improve > on one branch while it’s new. > > On Thu, Nov 7, 2019 at 5:41 PM Adrien Grand <[email protected]> wrote: > >> I'd be fine with option 2 but I have a slight preference for option 3. >> If we see the Gradle build as the future default build, then we need >> to start using it and I wonder that having to use a different workflow >> on branch_8x would be an incentive to keep using the Ant build >> instead. >> >> On Thu, Nov 7, 2019 at 11:15 AM Cassandra Targett <[email protected]> >> wrote: >> > >> > 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 <[email protected]>, >> 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 <[email protected]> >> 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: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> >> >> -- >> Adrien >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- > Sent from Gmail Mobile > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
