This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 09/29/14 02:22, Siddhesh Poyarekar wrote:
What we've found in GCC-land is it gets really hard to focus engineers efforts on fixing the important bugs to get a release out the door. Most folks would rather continue their work on features, optimizations, etc rather than fix bugs. The nerve :-)Hi, Our current release model requires us to freeze the master branch for releases, until the release is cut and branched out. This results in a halt in development for usually about a month or so and any new patches that don't qualify for the current release have to wait till whenever the release happens. Instead, we could just create a release branch to indicate the freeze, which means that the release branch can only have pre-decided exceptions on top of it and nothing else, until we're ready to actually cut the release, the point which is tagged as the release. This would work more or less the same as the current workflow, except that it frees up master for continuous development and the release manager and committers may have to push to two branches instead of one until the release is tagged.
The one really effective tool the release manager has is refusing to cut the branch until the trunk hits a set of metrics around stability (usually expressed in terms of P1-P3 regressions in bugzilla).
It's far from perfect, but does give the release manager a reasonable lever to get developers to focus on release issues rather than the next round of development.
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |