gdb branch policy in non-gdb code

gdb branch policy in non-gdb code

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 569 bytes --]

the gdb docs are little unclear:
https://sourceware.org/gdb/wiki/Internals%20Releasing-GDB

it focuses on the gdb/ subdir.  that makes sense -- the gdb branch is meant
for releasing gdb, and most bugfixes will be in that directory.

but what about commits outside of gdb/ ?  does the gdb branch maintainer
have to approve each one ?  like something in bfd/ or libctf/ or sim/.
or is it good enough that it's already been approved & merged into master,
and the flow is more interested folks post a [committed] notification to
the list when they cherry-pick back ?
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: gdb branch policy in non-gdb code

[Joel Brobecker]

> the gdb docs are little unclear:
> https://sourceware.org/gdb/ about wiki/Internals%20Releasing-GDB
> 
> it focuses on the gdb/ subdir.  that makes sense -- the gdb branch is meant
> for releasing gdb, and most bugfixes will be in that directory.
> 
> but what about commits outside of gdb/ ?  does the gdb branch maintainer
> have to approve each one ?  like something in bfd/ or libctf/ or sim/.
> or is it good enough that it's already been approved & merged into master,
> and the flow is more interested folks post a [committed] notification to
> the list when they cherry-pick back ?

This document gives guidelines in the decision process, but
indeed doesn't talk about responsibilities.

My position as the current manager of GDB releases is that
Global Maintainers have the ability to approve that a patch
be backported to a release branch. The idea behind it is that
those Global Maintainers often have a better understanding of
the ins and outs of a given patch and therefore of its potential
impact. I think we can extend this to the Responsible Maintainers
such as yourself as well for the patches that fall within their
area of responsibility. Parallel to this, I am always happy to
provide feedback on patches people would like me to evaluate.

One important note is a reminder that patches backported to
the .2 must have a PR number attached to them, with the target
milestone set to the release in question. This is critical
for the issue to list as being fixed in the .2 release.

-- 
Joel