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 > > > > > > > > > > > > > > >
