lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oren Eini (Ayende Rahien)" <aye...@ayende.com>
Subject Re: Long-terms plans for supporting .NET 3.5
Date Tue, 15 Jan 2013 14:06:29 GMT
We use github for ravendb and require CLA for anything except tests
We have a LOT of people contributing

On Tuesday, January 15, 2013, Stefan Bodewig wrote:

> On 2013-01-13, Troy Howard wrote:
>
> > One thing to consider is that the ASF workflow is a bit stodgy to work
> > with. It really does make a difference to collaboration, as any small
> > barrier makes it too easy to opt out of contributing and collaborating.
>
> OK, I bite ;-)
>
> What you describe (and I have largely snipped now) is how github pull
> requests lower the barrier to entry and how "send a patch and attach it
> to a JIRA ticket" is more cumbersome.
>
> Over at log4net we have people struggle with creating patches.  What
> otherwise seem to be competent developers fail to use diff or even use
> svn diff.  Using git would be even more difficult for them.  This may
> not be the target of "get more people involved in development", I'd
> aggree with that.
>
> I can't contest that pull requests are really easy for people who have
> done that a few times.  But there is a bit more to it.
>
> In my limited experience with pull requests it seems they create more
> "drive-by contributions" than the more heavy weight process at the ASF.
> The fact that forking and creating pull requests is so easy seems to
> result in pull requests by people that never show up again after it has
> been merged.  It feels as if people who have jumped through the hoops to
> actually contribute are more prone to stick around.  I may be wrong.
>
> Another aspect is that many times forks are created to fully implement a
> feature in isolation that somebody feels is worthy.  If you start out by
> proposing the feature and discussing it with the existing community
> first you may realize the majority doesn't want the feature or that a
> completely different way to skin that cat is more appropriate.  I don't
> say you couldn't have those discussions up front in a "pull request
> world", it just doesn't seem to happen as often.  Again, I may be wrong.
>
> The github "pull request world" seems centered around the code itself
> much more than the traditional way of the ASF which believes to be more
> centered around the community of developers.
>
> I'm not saying the "pull request world" is inferior (nor it is superior)
> but rather that at least I'm not sure how well the "pull request" view
> mixes with the ASF philosophical goals.
>
> Then again, we are free to use git and I'd be all for trying out how
> well it works for us.  After all a pull request at github really just is
> some icing on top of what you can do with the git CLI anyway.  Nothing
> would stop you from manually merging a fork into your local git repo and
> push the change to the ASF repo - you just didn't have the button inside
> a Web-UI.  But this difference is only visible to the existing committer
> base, not to the developers who want to contribute.
>
> Stefan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message