Hi Fabien, I would suggest that all changes that you would like to have in the 1.0.1 release should receive at least a cursory review (from another community member and/or Zend) before merging the changes to the stable release branch. Particularly risky changes should receive special attention, since they may affect the stability of the 1.0.1 release if such changes are merged to the release branch. Good unit tests and peer review help to mitigate these risks.
If there are changes that you think should wait until 1.1.0, then it should be fine to forgo such review, since the changes would not be merged to the release branch, but keep in mind that we have to consider each commit on a case-by-case basis. The extra process is necessary to maintain stability of the release branch and, therefore, the quality of the 1.0.1 release. Best regards, Darby Fabien MARTY wrote: > Hi Darby, > >> [...] >> Therefore, once you have committed >> changes to the trunk with passing unit tests, please request review from >> a community member or a Zend liaison, and then merge the changes (except >> for documentation) to the release branch. >> [...] > > It doesn't sound very clear to me. > > Let's take an example. > > I commited some bug fixes into the trunk : > - (1) some of them should be commited (IMHO) into the release branch > - (2) some of them are not really important and can wait the 1.1.0 > - (3) some of them are potentially dangerous > > All of them are available in JIRA. > > => May I commit (1) directly (without any review) ? (if not, it will > be very frustrating think for personal contributors like me) > => No problem for (2), they are waiting in the trunk > => A review is mandatory to commit (3) > > Are you ok with these 3 points ? >
