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