I have expressed my detailed opinion on the [VOTE] thread about this. One more
thing I'd like to add here.

In general, I like the idea of branch-committers, but I don't see this as a
very helpful mechanism for us, considering the agility of Bigtop. It might be
a good idea for, say, Hadoop, where it is getting almost impossible to commit
anything as _any_ change is being considered as a potentially harmful. Which
is not surprise, considering how entangled, rigid, and fragile the Hadoop code
is.

On Mon, Dec 22, 2014 at 12:25PM, Mark Grover wrote:
> Here's another option that I have seen to have worked well in other
> projects.
> 
> We create a separate branch for development of BigPetStore and Rj can be a
> branch committer on that without being a committer on the broader project.
> So, you guys can quickly iterate over BigPetStore in that branch. Once that
> branch is ready to be merged into the main master branch, you'd require a
> regular +1 from one of the committers.
> 
> The benefits of this approach is that you can quickly iterate on the
> development without having to wait for a formal committer +1. The downside
> is that when merging back the change may be a substantial so merge can be
> non-trivial.
> 
> I would personally be ok with such an approach here.
> 
> Mark
> 
> On Mon, Dec 22, 2014 at 9:47 AM, Jay Vyas <[email protected]>
> wrote:
> 
> > 1) I agree with Rj on that, we don't need to  change the rules for being a
> > commiter - it's a big responsibility and imo a achievement to be proud of
> > to be a commiter on bigtop, and I don't think we need to dilute that.
> >
> > So back on topic... :)
> >
> > 2) Given that we are quite small at the moment, we just need to remove any
> > barriers to getting good solid updates into bigtop, and doing so, possibly
> > make it easier for existing very busy commiters to focus on adding new
> > features, rather than reviewing patches which they aren't really that
> > interested in...  Example: I'd rather trust Debian expert review pig fixes
> > for Ubuntu packaging the review it myself, wether I'm a commiter or not.
> >
> > > On Dec 22, 2014, at 6:18 AM, RJ Nowling <[email protected]> wrote:
> > >
> > > I don't think know that my work meets the necessary requirements. I'm
> > focused primarily on BigPetStore, not the larger code base, while others
> > such as Evan have contributed more than I have and more broadly to the core
> > code base than I have yet they aren't committers yet.
> > >
> > > Just my two cents...
> > >
> > >
> > >> On Dec 20, 2014, at 6:54 PM, Bruno Mahé <[email protected]> wrote:
> > >>
> > >> Why not make RJ a commiter?
> > >>
> > >> From my understanding a review has at least 2 parts:
> > >> 1/ Is the intended change correct.
> > >> 2/ Does this change fit into the project's standards, culture.
> > >>
> > >> A change may perfectly be correct from a 1/ perspective but may require
> > some changes because of some issues related to 2/
> > >>
> > >> Thanks,
> > >> Bruno
> > >>
> > >>> On 12/17/2014 12:21 PM, jay vyas wrote:
> > >>> Hi bigtop.
> > >>>
> > >>> Is it okay for us to commit bigtop-bigpetstore/ updates if RJ +1's
> > them  ?
> > >>
> >

Attachment: signature.asc
Description: Digital signature

Reply via email to