Hello, +1 for 2.0 branch. I totally agree with Parth that for the fast progress of a feature (like RM) which can break the backward compatibility of an existing functionality, maintaining a separate branch is better.
Thanks, -Hanu On Mon, Mar 4, 2019 at 11:44 AM Parth Chandra <par...@apache.org> wrote: > The wisdom of the ancients says that if you want fast progress while a new > code base is in development, CTR is the way to go. Once the code is out in > a release, stability becomes important and you want to review before > committing it. > > With CTR you are allowed to - > Not worry about style. > Not worry about clean implementation. > You don't even have to make sure the code compiles. > Have non committers work alongside committers without having to wait. > > While it is up to each group of developers to have a common policy to which > they will adhere, as a project we can relax the rules and make sure that > those who want to move fast are able to do so without process getting in > the way. > > Either way, we should go ahead with the new branch and evolve the commit > policy as works starts/continues on 2.0 > > > > On Sun, Mar 3, 2019 at 9:18 PM Sorabh Hamirwasia <shamirwa...@mapr.com> > wrote: > > > 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 <amansi...@gmail.com> 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 <par...@apache.org> > 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 <pma...@mapr.com> > 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 < > agir...@apache.org> > > > > > 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 <amansi...@gmail.com > > > > > > 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 < > amansi...@gmail.com > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
