Hi, +1 for 2.0 branch. From RM perspective since we will be adding support for more richer configuration to support multiple queues, the existing functionality will be deprecated. This will result in breaking backward compatibility hence 2.0 branch will be preferred. I think it will be confusing and also extra work to keep support for both existing and new queues support for RM. However I would still prefer the commit process in 2.0 branch to be same as that in master branch. Review and approved by a committer before check in and all tests should pass. If we follow these steps then during integration of the entire feature into master branch, review of 1 big fat PR will not be required.
Thanks, Sorabh On Sun, Mar 3, 2019 at 7:35 PM Aman Sinha <[email protected]> wrote: > Catching up on this thread since I was traveling and am currently in India > time zone. > Interesting suggestion about the C-T-R policy for a potential 2.0 branch. > I don't recall we have done this for any prior releases. > In the past, my experience with a separate feature branch (not on apache > but in a private repo) was that we still did the review-then-commit > since that's what everyone is accustomed to and most Drill developers tend > to want early feedback. This depends on the folks working on the > specific features. > > For the branching, it sounds like people are more inclined towards option > (a). Parth does make a good case for 2.0 branch and it would be > inevitable at some point in future especially for the > compatibility-breaking functionality. We would expect the feature > developers to indicate when > that time comes. > > I believe at least partial support for Arrow is a 2.0 objective. Hopefully > one of us can free up from other commitments and start working on it. > > Aman > > On Thu, Feb 28, 2019 at 9:56 AM Parth Chandra <[email protected]> wrote: > > > +1 for a 2.0 branch. > > Feature specific branches can be created off the 2.0 branch, and should > > ideally be merged periodically. > > I would also suggest that we adopt a C-T-R policy [1] for the 2.0 branch > > until it is at a stable point. > > Finally, I would assume that it is up to the feature developers to decide > > whether the feature will maintain backward compatibility or not. 2.0 is > an > > opportunity to break backward compatibility so it would be quite > acceptable > > for some major features to break compatibility. > > One major question backward compatibility for 2.0 would be Arrow. If we > > decide we want to have Arrow support, we would probably break backward > > compatibility in may ways. If we don't do Arrow support in 2.0, we'll > > probably never do it. We could, of course, do partial support. For > > reference see the Spark effort [2] > > > > [1] https://www.apache.org/foundation/glossary.html#CommitThenReview > > [2] https://jira.apache.org/jira/browse/SPARK-26413 > > > > > > On Thu, Feb 28, 2019 at 9:26 AM Pritesh Maker <[email protected]> wrote: > > > > > I think option (a) is better in terms of maintaining branches. With > > option > > > (a) how do we handle a situation where one of these features breaks > > > backward compatibility or deprecates some functionality? > > > > > > Pritesh > > > > > > On Wed, Feb 27, 2019 at 4:23 PM Abhishek Girish <[email protected]> > > > wrote: > > > > > > > My opinion would be option (a) as well. It's easier to maintain a > > single > > > > master branch. With a separate v2 branch, it's twice the effort to > test > > > > common commits going in (either directly or via later via rebase). > > > > > > > > On Wed, Feb 27, 2019 at 12:40 PM Aman Sinha <[email protected]> > > wrote: > > > > > > > > > My personal preference would be option (a) as much as possible > until > > > we > > > > > get to a situation where it is getting too unwieldy at which point > we > > > > > re-evaluate. > > > > > > > > > > Aman > > > > > > > > > > On Wed, Feb 27, 2019 at 12:35 PM Aman Sinha <[email protected]> > > > wrote: > > > > > > > > > > > Hi Drill devs, > > > > > > There are couple of ongoing projects - Resource Manager and the > > Drill > > > > > > Metastore - that are relatively large in scope. Intermediate PRs > > > will > > > > be > > > > > > created for these (for example, there's one open for the > metastore > > > [1]. > > > > > > Another one for the RM [2]. These don't currently break existing > > > > > > functionality, so they have been opened against master branch. > > > > > > > > > > > > The question is, for future PRs, would it make sense to create a > > > > > separate > > > > > > Drill 2.0 branch ? There are pros and cons. Separate branch > would > > > > allow > > > > > > development on these features to proceed at a faster pace without > > > > > > disrupting others. However, in Drill we typically have only > > created > > > a > > > > > > separate branch close to the release, not up-front. It > simplifies > > > > > testing > > > > > > and maintenance to have a unified master branch. > > > > > > > > > > > > Another option is feature specific branch. > > > > > > > > > > > > What do people think about the 3 options: > > > > > > a) Merge intermediate PRs into Apache master as long as they > > don't > > > > > break > > > > > > existing functionality. In some cases, temporary config options > > may > > > be > > > > > > used to enable new functionality for unit testing. > > > > > > b) Create a Drill-2.0 branch which will be work-in-progress and > > be > > > > > > periodically sync-ed with master branch. Code reviews will be > done > > > > > against > > > > > > this branch. > > > > > > c) Have a feature specific branch - e.g for RM, for Metastore > > etc. > > > > such > > > > > > that collaborators can do peer reviews and merge intermediate > > > commits. > > > > > > These branches will also need to be periodically sync-ed with the > > > > master > > > > > > branch. > > > > > > > > > > > > Please share your choice of one of these options and any > additional > > > > > > thoughts. > > > > > > > > > > > > [1] https://github.com/apache/drill/pull/1646 > > > > > > [2] https://github.com/apache/drill/pull/1652 > > > > > > > > > > > > > > > > > > > > >
