[zeromq-dev] merge commits in libzmq clutter the commit space.

[crocket]

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 <ph at imatix.com> 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 <lindleyf at gmail.com>
> 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 <ph at imatix.com> 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 <crockabiscuit at gmail.com>
> 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 <ph at imatix.com>
> wrote:
> >> >>
> >> >> On Fri, Dec 6, 2013 at 4:41 PM, Michel Pelletier
> >> >> <pelletier.michel at gmail.com> 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
> >> >> zeromq-dev at lists.zeromq.org
> >> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > zeromq-dev mailing list
> >> > zeromq-dev at lists.zeromq.org
> >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >> >
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> >
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131207/1b27df41/attachment.htm>