On 1:59 PM, Vladimir Prus wrote:
Eric Niebler wrote:
On 10/29/2010 5:03 AM, John Maddock wrote: [...]
We really need to figure out a better way of dealing with this... It currently requires a lot of discipline from each developer to make sure every change they apply to trunk also ends up in release. I wonder if commits to trunk to schedule a nag mail to be sent to the submitter a week later that says, "Did you check the tests? Did you merge to release?" Or open a track ticket that says, "merge changelist xxx to release." I guess it's better to nag the maintainer of a library, given that merging just once is a sensible strategy.
This seems like another thing that a group of volunteers could do. It doesn't require intimate familiarity with the library, but a careful eye comparing regression tests: trunk vs release . If trunk passes more than release with no new mysteries introduced, all trunk changes can be merged. The volunteers, then, would inspect and certify to the release manager that this was the case, and the manager do the merge with confidence. Minimal work for the release manager. No special permissions for the volunteers (i.e., a larger group of folks whose work you're much-less familiar with wouldn't be given power to make changes). Even teams of two volunteers, checking each others' work. Reasonable?
On which note -- do we have up-to-date list of maintainers? Or, do we know the maintainer of libs/maintainers.txt? It appears to contain entries where a different person is know to maintain that library recently, or where the listed maintainer is known to be MIA, or have officially declared he's not maintaining that library.
Particularly valuable when the maintainer is MIA.