On 16-05-06 02:58 PM, David Lang wrote: > On Fri, 6 May 2016, Kus wrote: > >> >> I'd argue such a barrier is OK if we want to quickly increase the size >> of the team of people with commit access. I think we're >> underestimating our contributors here. I agree that we shouldn't have >> unnecessary barriers (such as copyright assignment to give a specific >> example). > > I'm not representing LEDE, but I have to ask, why do we think that we > need a lot of people with commit access? > > Linux Kernel works just fine with only one person having commit access > (Linus) > > I think this is legacy thinking based on SVN. > > With Git, you don't need a lot of people with commit access, everyone > can have their own tree and create branches to be pulled by a single > person (or small group of people), potentially through a hierarchy > similar to how the Linux kernel maintainers merge things from their area > and then Linus merges from them to the final tree. > > Too many people with commit access to the central tree just leads to > more ways to trip over each other.
I agree with David, enough committers to prevent merging being a bottleneck, but no more than actually required for merging (which if the trees being merged are in a respectably up-to-date state shouldn't result in huge numbers of conflicts that need to be resolved, in fact I'd argue that tree really should already be up-to-date vs master so that you only need to do a fast-forward update before merging, as untested merges create the potential for untested changes that cause issues (merge is just textual not semantic, which means that even a successful merge with no conflicts may in fact break things)). Regards, Daniel _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
