On Jul 5, 2012, at 10:53 AM, Chiradeep Vittal wrote: >>> However, several factors complicate that. First, >>> not all patches applied cleanly as the three different codebases were >>> often in very different places. Second, people are human, and I >>> imagine some commits just didn't make it. >> Sounds like something a tool would help with, but I don't know of said >> toolŠplugin for Jenkins, maybe? Seems like it shouldn't be too hard to >> look for similar commits to 2 different branches. >> >> Would this maybe be something that falls under a Maintainer to manage? >> e.g. for the Agent Maintainer, make sure /agent patches are applied to >> the last 3 release branches? > > That does sound like a lot of work. Does this mean the maintainer asks the > patch submitter to test against the last 3 release branches?
Good question. I don't think that'd have developers flocking to work on CS. How about this, just to define it (more or less what David just said): * For development/feature branches, the developer(s) have a responsibility of making sure their code will cleanly merge back into master, either by keeping their branch in sync with master, or by doing any triage at time of merging their branch back to master when ready. * The only time CS patches and releases an update for a release is in the event of a security vulnerability. If a vulnerability is found, the CS team will evaluate releases within the last 3 releases, and issue patches where necessary. * Otherwise, patches will be applied to the master tree only. John
