[TYPO3-core] SVN branches & stuff

Ernesto Baschny [cron IT] ernst at cron-it.de
Thu Jul 20 11:33:27 CEST 2006

Martin Kutschker schrieb am 20.07.2006 10:57:

>>> Good idea. It will be much easier to test: just update from repo
>>> instead of download-patch/apply.

>> But one more question pops up: this branch may go too far from HEAD at
>> one point. Who, how and when will resync?

> We shouldn't sync. While testing many patches may be rejected and
> changed again and again that it will be a mess. The final patch must be
> written against HEAD/trunk not experimental anyway.
> Thinking again about it I don't think the idea is that great.

I think it is interesting, we just have to make some rules on how to use
it. Most of the times it should be in sync with trunk, except when a
patch is being "discussed" here in -core. I propose the following workflow:

1) patch is suggested by someone in -core. He applies it to
"experimental". He says: "check out experimental revision XXXX", patched
files are "x, y, z".

2) someone checks it out, but finds this or that could be done better.
He just changes the code, commits and tells us the new revision where
his changes are included. This has the advantage that we can see: the
original patch, the changes made by person #2, and the complete result.
So we can all be sure to be discussing the "latest code available" for a
patch request. There had been problems before where people suggested
changes to patches that were later just "forgotten" to be integrated
into the original patch. Also no more patches need to be posted to the
list (different patch styles, line-endings, etc).

 a) if someone finds more stuff to change: goto 2) again

 b) if the patch is not approved by two +1 in a certain amount of
reasonable time (two weeks?) the author might post a reminder to the
list or he withdraw his suggestion: this is when he HAS to place
experimental back to the stage before 1) began. This is pretty easy
(doing a diff and applying with -R). Then he commits the change and
tells: "ok, revision XXX restores old behaviour"

 c) if the patch is approved by two +1, the original author makes a
diff, applies to trunk and it then will be in sync with "experimental"

I'm not sure if we need an "experimental" also for 4_0, I think that
would be an overkill. But if we later on need to add "major changes"
because of the usability issues for 4.5, that would be much easier
accomplished with a branch than with several patch files to the list.


More information about the TYPO3-team-core mailing list