Hi,
I would like to ask everyone that wants to see some new feature in the next bigger PHP update to create an RFC on the wiki. I have to check why the register link [1] disappeared from the login page (anyone with a php.net svn account can just login without registering). Ideally we will simply cherry pick the features for the next release from the old todo list [2] as well as mature RFC's.
Personally I also think that we should make sure that we do not spend months in this planning stage. If we do not yet feel ready to do the big leap to a new major version number, since we cannot play the "lets drop some BC" card in every release, then we can of course just bump the minor version number for the next release. Even if we do not solve unicode with the next release we already have plenty of good proposals on the table. But focusing development again on a single branch and the willingness to review our approach to unicode I think we can move forward again either way. So I am suggesting that we should aim to have a solid release plan (schedule and feature set) done no later than end of April.
Personally I would like us to be able to look towards the first alpha for this new version in Q4 2010 or Q1 2011, but that is of course something that is up for debate. Obviously if we give ourselves a more or less specific timeframe it also limits the number of features we can deliver. But I think we should really become a bit more disciplined in this regard and maybe even work towards a semi regular cycle for new releases. I really like how PostgreSQL is doing things in this regard. Of course they still slip the dates at times, but so it goes (but they do not slip a few years .. just a couple of months). The important bit is that with regular releases contributors feel more like they will actually see the solution to their "itch scratching" released before they move on to other "itched to scratch". It also means that if a feature doesnt make it into the release plan for the next release, developers will at least have a rough idea for the timeframe when they will have another chance to get a given feature into PHP. Plus it will make it easier for others (like distributions and app developers) to work with us. Most importantly it will spare us running into the situation we had with PHP 6 and 5.3 in the future where because we had time finishing up something we just end up piling features up for years making the release process a nightmare.
I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence.
But again, I really do hope that we can however wrap up the debate up by end of April.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
[1] http://wiki.php.net/rfc?do=register
[2] http://wiki.php.net/todo/php60
Hi,
I would like to ask everyone that wants to see some new feature in the next bigger PHP update to create an RFC on the wiki. I have to check why the register link [1] disappeared from the login page (anyone with a php.net svn account can just login without registering). Ideally we will simply cherry pick the features for the next release from the old todo list [2] as well as mature RFC's.
+1. RFCs still seem to be a good way to work out new features while we still need to improve the way we handle it and particularly make developers who already have an account still write RFCs (and create an experimental branch) instead of committing directly to trunk.
Personally I also think that we should make sure that we do not spend months in this planning stage. If we do not yet feel ready to do the big leap to a new major version number, since we cannot play the "lets drop some BC" card in every release, then we can of course just bump the minor version number for the next release. Even if we do not solve unicode with the next release we already have plenty of good proposals on the table. But focusing development again on a single branch and the willingness to review our approach to unicode I think we can move forward again either way. So I am suggesting that we should aim to have a solid release plan (schedule and feature set) done no later than end of April.
into PHP. Plus it will make it easier for others (like distributions and app developers) to work with us. Most importantly it will spare us running into the situation we had with PHP 6 and 5.3 in the future where because we had time finishing up something we just end up piling features up for years making the release process a nightmare.
I agree that we should try to get releases out more regularly, also we should still have a little bit of flexibiltiy (particularly in the first releases). I hope we can reduce some of the issues that we had with 5.3.
I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence.
Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/<name>/<branch> for this purpuse to not clutter branches/ with a million names.
But again, I really do hope that we can however wrap up the debate up by end of April.
David
I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence.
Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/<name>/<branch> for this purpuse to not clutter branches/ with a million names.
I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss?
-- Gwynne
(g)it would be better for cherrypicking and handling multiple
development branches, but it the developers cant use it propery, the
its PITA.
Tyrael
I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence.
Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/<name>/<branch> for this purpuse to not clutter branches/ with a million names.I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss?
-- Gwynne
(g)it would be better for cherrypicking and handling multiple
development branches, but it the developers cant use it propery, the
its PITA.Tyrael
I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence.
Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/<name>/<branch> for this purpuse to not clutter branches/ with a million names.I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss?
Oh no .. another dangerous topic. Again we have been there even before the switch. The idea is to keep the centralized repo on svn, because the masses know how it works, the tools are widely available and we have plenty of experience among us in how to keep svn running. I see little incentive to move the central repo to a DVCS. Are the bridges to git, mercurial, bzaar etc really so bad that this topic is worth discussing (no sarcasm, honest question)?
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Oh no .. another dangerous topic. Again we have been there even before the switch. The idea is to keep the centralized repo on svn, because the masses know how it works, the tools are widely available and we have plenty of experience among us in how to keep svn running. I see little incentive to move the central repo to a DVCS. Are the bridges to git, mercurial, bzaar etc really so bad that this topic is worth discussing (no sarcasm, honest question)?
I only have experience with git. The problem with something like
git-svn is that your git branch becomes an island. I can't share that
branch with anyone else. So all I really get is git syntax within an
svn environment.
I have no problem working with svn and actually prefer it for projects
that use a compiler. For PHP apps, git is great because nothing has
to be built. Bouncing between git branches means I have to recompile
PHP every time (or set up some system of symlinks).
--
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com
Oh no .. another dangerous topic. Again we have been there even before the switch. The idea is to keep the centralized repo on svn, because the masses know how it works, the tools are widely available and we have plenty of experience among us in how to keep svn running. I see little incentive to move the central repo to a DVCS. Are the bridges to git, mercurial, bzaar etc really so bad that this topic is worth discussing (no sarcasm, honest question)?
I only have experience with git. The problem with something like
git-svn is that your git branch becomes an island. I can't share that
branch with anyone else. So all I really get is git syntax within an
svn environment.
There are a number of ways to share your branches with others. At
least you can do it by pushing your local changesets to some remote
repository. I've actually been experimenting with modified PHP core
with some language features added by forking the mirror on github.com
[1]. I've never felt any inconvenience there. I really appreciate
those who set up the mirror.
I have no problem working with svn and actually prefer it for projects
that use a compiler. For PHP apps, git is great because nothing has
to be built. Bouncing between git branches means I have to recompile
PHP every time (or set up some system of symlinks).
I guess you can have several local repositories that have different
branches checked out at the same time...
[1] http://github.com/moriyoshi/php-src/
Moriyoshi
There are a number of ways to share your branches with others. At
least you can do it by pushing your local changesets to some remote
repository. I've actually been experimenting with modified PHP core
with some language features added by forking the mirror on github.com
[1]. I've never felt any inconvenience there. I really appreciate
those who set up the mirror.
Yes, this is possible, but in my experience branch sharing quickly
falls apart in practice. If I make some change to foo.c, push it to
your branch and then later on do a rebase to update from svn I just
rewrote history. The commit hash you have for foo.c is now different
than mine. Now sure you can also rebase, but what if you are away? I
am stuck until you return. Or what if you have a commit to foo.c that
is made after my commit, but updating from svn creates a conflict you
need to resolve? You then again rewrite history and now I have to
sync back up. And good luck if one of us cherry-picks.
I think git svn does a great job for individuals working solo on a
project, but for me it starts to become too tedious when groups of
people are passing around branches. Or maybe I am just doing it all
wrong?
--
Herman Radtke
hermanradtke@gmail.com | http://hermanradtke.com
On Monday 15 March 2010 12:56:07 am Herman Radtke wrote:
There are a number of ways to share your branches with others. At
least you can do it by pushing your local changesets to some remote
repository. I've actually been experimenting with modified PHP core
with some language features added by forking the mirror on github.com
[1]. I've never felt any inconvenience there. I really appreciate
those who set up the mirror.Yes, this is possible, but in my experience branch sharing quickly
falls apart in practice. If I make some change to foo.c, push it to
your branch and then later on do a rebase to update from svn I just
rewrote history. The commit hash you have for foo.c is now different
than mine. Now sure you can also rebase, but what if you are away? I
am stuck until you return. Or what if you have a commit to foo.c that
is made after my commit, but updating from svn creates a conflict you
need to resolve? You then again rewrite history and now I have to
sync back up. And good luck if one of us cherry-picks.I think git svn does a great job for individuals working solo on a
project, but for me it starts to become too tedious when groups of
people are passing around branches. Or maybe I am just doing it all
wrong?
If I may pop in here a moment, my company has done a few projects recently
using git, and Drupal (the main project I work on) is in the process of
planning a git migration.
I make no claims of being a git expert (I've only used it on one project so
far personally), but my understanding from those who are is "OMG WTF are you
doing rebasing???" 99% of the time that's not what you want to do. You just
want to do a straight up merge from the "parent" branch to your branch off of
the parent periodically. That may resolve the issue you're describing.
--Larry Garfield, not a git expert by any means, just repeating what he's been
told by people who know more than him
I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate
against it before, but I've learned a bit since then. Anyone care to discuss?
Isn't it already available?
Marco