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]
>
>

Reply via email to