On Thu, Nov 25, 2010 at 3:05 PM, Derick Rethans <der...@php.net> wrote:

>> This doesn't seem the ideal time to introduce a new toolchain, so
>> sticking with SVN, we should maintain 4 branches, 5.2 (security only),
>> 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC
>> breaks), 6.0 (BC breaks).
>
> Four branches? Are you going to help?

I'd to ask you to stop to say that in every 2nd person. What have you
done lately to help anyway? Besides the controversial patch for type
hinting? Right, there is no point to ask you that, so I remove this
question. Please, just respect everyone giving us precious feedback as
well as other developers.

>> Non-agreed upon enhancements, potential BC breaks, all should be done
>> in feature branches.
>
> That's a good theoretical point of view. And I maintain it doesn't work.
> It makes it for example very difficult to try out multiple new features
> at the same time; to say, to try to figure our whethr your app will
> still works. It's also a lot more egocentric thing, instead of
> collaboration. You want your stuff exposed to as many developers as
> possible (that's also why I am not a fan of DVCS, because it reduces
> that exposure drastically).

You mean more than putting an extension in some random personal
repository? Be serious please. github and bitbucket are the two best
examples why these tools are fantastic ways to ease contributions,
both for the developers and the contributors. The requests procedure
is simply amazing, there are also tools to review & manage external
patches, with comments and history. That's simply impossible to do
with svn.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to