OK, see SOLR-13914. I figure to close SOLR-13452 after I push to master, it’s 
too long.

To Cassandra’s point: I fully sympathize for two reasons:

1> the more we all can use Gradle all the time, the faster it’ll get into its 
final shape

2> the longer we have to add patches, the harder it’ll be to backport

Therefore I’m going to push for back-porting Real Soon Now, next weekend if 
possible. As soon as we have evidence that the Gradle build doesn’t break Solr, 
i.e. Jenkins master builds using Ant don’t start breaking due to this, I 
propose to back-port to 8x.

Let the fun begin!

Erick

> On Nov 8, 2019, at 8:30 PM, Gus Heck <gus.h...@gmail.com> wrote:
> 
> +1 to option 2
> 
> On Thu, Nov 7, 2019 at 6:23 PM David Smiley <david.w.smi...@gmail.com> 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 <jpou...@gmail.com> 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 <casstarg...@gmail.com> 
> 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 <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
> >>
> 
> 
> -- 
> Adrien
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> -- 
> Sent from Gmail Mobile
> 
> 
> -- 
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to