This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ping: Re: handling of absolute source file paths


For now, just to mainline, think about 6.2 branch after 6.2 is out.


What is the reason for that (just to understand how such matters are
handled)?

The emphasis is on getting changes into the mainline for the next release (and it is now very very late in the 6.2 release cycle).


For reference:

@section Branch Commit Policy

The branch commit policy is pretty slack.  @value{GDBN} releases 5.0,
5.1 and 5.2 all used the below:

@itemize @bullet
@item
The @file{gdb/MAINTAINERS} file still holds.
@item
Don't fix something on the branch unless/until it is also fixed in the
trunk.  If this isn't possible, mentioning it in the @file{gdb/PROBLEMS}
file is better than committing a hack.
@item
When considering a patch for the branch, suggested criteria include:
Does it fix a build?  Does it fix the sequence @kbd{break main; run}
when debugging a static binary?
@item
The further a change is from the core of @value{GDBN}, the less likely
the change will worry anyone (e.g., target specific code).
@item
Only post a proposal to change the core of @value{GDBN} after you've
sent individual bribes to all the people listed in the
@file{MAINTAINERS} file @t{;-)}
@end itemize

@emph{Pragmatics: Provided updates are restricted to non-core
functionality there is little chance that a broken change will be fatal.
This means that changes such as adding a new architectures or (within
reason) support for a new host are considered acceptable.}

Andrew





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]