Project

General

Profile

Bug #5122

Develop an approval process for patches

Added by Sean Riddle about 9 years ago. Updated over 8 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
build system
Target version:
Start date:
08/04/2010
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5122

Description

At present, releasing a patch releases all changes made to the applicable release branch. If not very many people are making patches on any given module, then an ad hoc organizational scheme can be used (Just talk it out) to make sure people aren't stepping on each others toes. This is not always guaranteed to be the case. In the absence of a redesign of the patching system with more than per-module granularity, a social solution has to be developed.

History

#1 Updated by Derik Barseghian about 9 years ago

To clarify, releasing a patch is a module-level event.
Each minor release will have its own branch in svn, and if two developers are working on the same module in that branch, they need to coordinate with each other, and relevant groups, before releasing the patch. E.g. before a patch in a vanilla Kepler is released, it should be tested and approved by the architecture and leadership teams.

#2 Updated by Derik Barseghian about 9 years ago

Moving this to 2.2 target in case we want to discuss it further then.

#3 Updated by David Welker almost 9 years ago

What are we doing with respect to this item? Are we going to develop a more formal process?

#4 Updated by David Welker over 8 years ago

This is not really a release issue, but it is instead a management issue. Retargeting from 2.2 to unspecified.

#5 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 5122

Also available in: Atom PDF