I hoped to push my Ref Guide changes to the gradle_8 branch yesterday but got 
distracted with some other stuff for work. I don’t expect I’ll have time to 
work on it this weekend so if you push the other bits to master this weekend, 
I’ll make a new branch off master and will hopefully be able to get it in 
quickly early next week (I’m traveling Tuesday-Friday, so we’ll see).

Cassandra
On Nov 9, 2019, 9:41 AM -0600, Erick Erickson <erickerick...@gmail.com>, wrote:
> 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