Every 6 months, as a cycle ends and we prepare the next, we look back at our release model and try to see how we can improve it. My opinion is that we need (once more) to evolve it, and here is why.
Our main objective …
In recent years, as open source becomes more ubiquitous, I've seen a new breed of participants appearing. They push their code to GitHub like you would wear a very visible good behavior marketing badge. They copy code from multiple open source projects, modify it, but don't contribute back their changes …
Just after a release, discovery of significant bugs always revives discussion around the need for maintenance branches or point releases. Those discussions, however, are not solving the root cause for the issue, but merely try to do damage control on the consequences.
The root cause for presence of significant bugs …
How to control what gets into your open source project code ? The classic model, inherited from pre-DVCS days, is to have a set of "committers" that are trusted with direct access while the vast majority of project "contributors" must kindly ask them to sponsor their patches. You can find that …
There was a bit of discussion lately on feature-based vs. time-based release schedules in OpenStack, and here are my thoughts on it. In a feature-based release cycle, you release when a given set of features is implemented, while in a time-based release cycle, you release at a predetermined date, with …