2012-06-01, 06:31
Hi Chris - goes like this:
June 1st - June 10th: merge cycle - pull requests getting "blessed" by team members familiar with that code or the area it affects get vetted in and merged. This can create a higher chance of bugs than just small fixes, and the review process isn't perfect, but this is how new features and upgrades get in. These merges can happen anytime during this period.
June 11th - 30th: debug cycle - no features, only bug-fixes are allowed in. A mini-feature-freeze. Fixes ofc can be pushed any time, but the idea of this cycle is settling things down, ironing out bugs, and prepping work for the next merge cycle. Ofc bug-fixes sometimes create bugs.
Cycle repeats....
One typo can bring the whole thing down, as it did with Eden RC1, so there is no guarentees any time. That said, avoiding builds done between the 1st and 10th of every month is good if you're cautious. I only run nightlies
June 1st - June 10th: merge cycle - pull requests getting "blessed" by team members familiar with that code or the area it affects get vetted in and merged. This can create a higher chance of bugs than just small fixes, and the review process isn't perfect, but this is how new features and upgrades get in. These merges can happen anytime during this period.
June 11th - 30th: debug cycle - no features, only bug-fixes are allowed in. A mini-feature-freeze. Fixes ofc can be pushed any time, but the idea of this cycle is settling things down, ironing out bugs, and prepping work for the next merge cycle. Ofc bug-fixes sometimes create bugs.
Cycle repeats....
One typo can bring the whole thing down, as it did with Eden RC1, so there is no guarentees any time. That said, avoiding builds done between the 1st and 10th of every month is good if you're cautious. I only run nightlies