Reducing unneccesary complexity works well. I think I want to suggest this approach to many company.
The link you referred to says "A Contributor SHALL NOT commit changes directly to the project. Anyone who submits a patch is a contributor, and all contributors follow the same rules. No special privileges to the original authors, because otherwise we're not building a community, only boosting our egos." Technical brilliance is certinaly an asset for humanity, however optimizing for technical brilliance can work against building a community sometimes or most of times depending on how closed a project is. I'm really interested to see how different models end up after 2 decades. On Sat, Dec 7, 2013 at 8:33 AM, Pieter Hintjens <[email protected]> wrote: > There is a long and somewhat labored explanation of how we came to > where we are today: zguide.zeromq.org/page:all#toc130 > > tl;dr complex repositories are hard to scale to more people. > > On Sat, Dec 7, 2013 at 12:13 AM, Lindley French <[email protected]> > wrote: > > I'm a fan of gitflow, I think it's great. > > > > I'm still getting a feel for how the forking model works. > > > > > > On Fri, Dec 6, 2013 at 6:10 PM, Pieter Hintjens <[email protected]> wrote: > >> > >> it's because that project isn't using pull requests, but one person > >> committing directly to master. We abandoned that model some years ago > >> as inherently unstable and unscalable. > >> > >> On Fri, Dec 6, 2013 at 11:37 PM, crocket <[email protected]> > wrote: > >> > I just came by https://github.com/nanomsg/nanomsg/commits/master , > which > >> > is > >> > M.sustrick's new endeavor, and I was surprised that it didn't have any > >> > merge > >> > commits. > >> > It looked cleaner than with github's usual merge commits. > >> > So I wanted ZeroMQ people to just imagine another possibility. > >> > > >> > > >> > On Sat, Dec 7, 2013 at 3:54 AM, Pieter Hintjens <[email protected]> > wrote: > >> >> > >> >> On Fri, Dec 6, 2013 at 4:41 PM, Michel Pelletier > >> >> <[email protected]> wrote: > >> >> > >> >> > Feature developers should be responsible for squashing their > commits > >> >> > before > >> >> > submitting the PR. It's a simple git rebase command. > >> >> > >> >> Yes, and it's specified in our process that one change should be one > >> >> commit. However it's the merge itself that adds another commit, which > >> >> Crocket is referring to here. > >> >> _______________________________________________ > >> >> zeromq-dev mailing list > >> >> [email protected] > >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > >> > > >> > > >> > _______________________________________________ > >> > zeromq-dev mailing list > >> > [email protected] > >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >> > > >> _______________________________________________ > >> zeromq-dev mailing list > >> [email protected] > >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
