Core-Development Mailinglist Rules
The core development mailinglist is the channel through which every change to the TYPO3 4.x sourcecode needs to go before it can be committed to the Subversion repository by a core developer.
All mails sent to that list come with the code change attached to it as a patch file along with a description of what the change does and which problem it addresses.
Until now, only members of the core team were allowed to post messages to that list. However, in order to open up for community involvement we have decided to allow non-members write access to the list as well*.
In order to keep the work in the list as effective as it used to be, postings to the core list are only allowed if they
- are patch requests adhering to the format described below, or
- are replies to existing patch requests stating whether the patch worked or not
It is strictly not allowed to start other new threads or discussions. For discussions use the TYPO3-dev list. All postings should be sent in plain text format (no HTML mails) and must carry the sender's real name in the "From" header of the mail.
Sending your own patch requests
Before sending a patch to the core list, it must be submitted to the bug tracker, filed under the TYPO3 Core project and in the category that fits the issue. Also add the tag "pending in core list" to the bug. RFCs must only address one single issue, never mix up two different topics in one patch.
Then you can send a mail to the core list with a unified diff patch attached. The patch should be created against Subversion trunk (see Using Subversion).
The mail must look like this:
This is an SVN patch request.
Type: [Bugfix / New feature / Code cleanup]
Bugtracker references:
[A link to the issue in the bugtracker must be placed here. If there
is none yet, create one. Example: http://bugs.typo3.org/view.php?id=6522]
Branches:
[SVN branches you think this patch belongs into, e.g. "TYPO3_4-1 & trunk".
At the moment we actively maintain TYPO3_4-1, TYPO3_4-2 and trunk. Trunk is always the
latest development code, and currently is what will become 4.2. In general,
everything goes into trunk (= next minor/major version) while bugfixes also
go into the current stable branch (= next patch level version).
For details, see the release workflow guidelines.]
Problem:
[Precise and short, but not too short description of the problem]
Solution:
[Description of the solution]
Notes:
[This section is optional. You can write various notes here
such as describing additional files you attached (e.g.
screenshots or documentation changes) or mentioning the
sponsor or the original creator of the patch]
[Put your name or greetings here, if you like]
The subject line of the mail must look like this:
RFC #[bug number without leading zeros]: [Bug / Feature / Code cleanup]: [some keywords describing the change]
Example:
RFC #6046: Bug: Make requestUpdate work for selectboxes
Don't forget to attach the patch to your mail! The patch must have the file extension *.diff or *.patch.
If your patch changes something that needs to be documented in the official documentation (like TSRef, TSConfig reference or Core API), you need to attach the documentation changes in a .txt file to your RFC mail in the format used on the Pending Documentation page, so it's ready to paste into the wiki page. The format is not strictly defined, so just write the changes down in a sensible way, so that the person who will finally put the changes into the documentation knows where to insert it (example file).
As for the nature of your change, feature of bugfix, there are no limitations. However, new features must be discussed in the TYPO3-dev list before they are sent to the core list. Only bugfixes or minor tweaks are allowed to be sent to the core list without being discussed on the TYPO3-dev list first.
When the mail is sent, you have to wait for feedback and votes as described below and a core developer to pick up your patch and commit it to the core. If no-one seems to notice your patch, keep sending reminders up to once a week as replies to your original mail.
Generally it seems like sending ones own patches is more attractive than reviewing others patches. Therefore we would like to remind you that it's also important and necessary to make reviews and not only to send new patches to the list, otherwise we're finally stuck with a long list of pending patches.
Replying to existing patch requests and voting
You are allowed to vote for patch requests if you have thoroughly tested them (how to apply a patch) and confirm that they work/don't work. We have established a +1/-1 voting scheme in the core team, which means you can express your vote with a short sentence on whether and how you tested the patch as well as writing "+1" or "-1". It should be clear from the sentence you write whether you only reviewed the code, only the functionality or both code and functionality.
Example for a positive review:
"The code looks all good to me and I've tested it. So I vote +1."
Example for a negative review:
"I applied the patch and tried to use its functionality but it stops working at this and that point. -1 for the moment."
A patch is considered to be ready to be committed to the Subversion repository by a core developer as soon as both of the following conditions are met:
- Two positive code reviews (one of them made by a core developer)
- Two positive functionality reviews (one of them made by a core developer)
Other core developers can veto against the decision if they have stated good reasons for it.
To access the list, you can either subscribe to the mailinglist or use a newsreader. To get a feeling for what mails in the core list look like, have a look at the archive.
We hope you'll enjoy the new possibilities of participating and wish for a lot of input.
* Note that opening up the core development list currently is an experiment. If it turns out to obstruct effective development, we reserve the right to moderate the list or revert to a closed list for the overall good of the project.
