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 <[email protected]>, 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 <[email protected]> wrote: > > > > +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) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
