search for: release_branch

...cess works like this: > > - patch gets checked-in on the trunk > > - developer sends message to the code owner who > approves the patch and sends the *APPROVED* to the > release manager > > - somebody (not specified who in the current flow) > merges the patch on to the release_branch > > - release manager creates rc1/rc2/and final branches > from the release_branch verifying that each patch > has been approved by the code owner. > > This process looks good on the screen but breaks down > in practice because: > > - patches get checked-in onto the r...

...proval process? Generally release patch process works like this: - patch gets checked-in on the trunk - developer sends message to the code owner who approves the patch and sends the *APPROVED* to the release manager - somebody (not specified who in the current flow) merges the patch on to the release_branch - release manager creates rc1/rc2/and final branches from the release_branch verifying that each patch has been approved by the code owner. This process looks good on the screen but breaks down in practice because: - patches get checked-in onto the release_branch (rare) - patches get sent to t...

> This approach is fine for casual reader but > does not work for scripting or any automated > way of dealing with the build. Will you please clarify how the automation / scripting helps with the patch approval process? > I would like to propose addition of the > "folder/file (F)" field. The format > would be the same as used by Joe,Owen > and Justin This won't

Hello, Recent code owner activities have led to what I would call loss of referential integrity in the CODE_OWNERS.TXT file. Changes are fine but the information in the CODE_OWNERS.TXT does not allow to positively identify code owner of the particular file or patch. The problem stems from the usage of the "description (D)" field which is overloaded with meaning. Most people put