[maint] Commit rules for un-maintained targets ....

[maint] Commit rules for un-maintained targets ....

[Andrew Cagney]

Hello,

The current commit rule for un-maintained targets is:

> All maintainers can make arbitrary changes to OBSOLETE targets.
> 
> All maintainers can make mechanical (params, spelling, indentation,
> multi-arch, -W..., ....) changes to ``maintenance only'' targets.
> Please sanity check the change by compiling with one of the listed
> targets.
> 
> The GAWK segment:
> 
>   awk < "${maintainers}" '
>   $2 ~ /--target=.*/ {
>     targets = gensub (/^.*--target=/, "", 1, $2)
>     warnings = gensub (/[)]*$/, "", 1, $3)
>     split (targets, targ, /,/)
>     for (i in targ) {
>         print targ[i], warnings
>     }
>   }'
> 
> can be used to generate a full list of --target=
> --enable-gdb-build-warning= pairs.


I'd like to propose a change so that it is something like:


 > All recognized developers can make arbitrary changes to OBSOLETE targets.
 >
 > All maintainers can test and thence approve non-trivial changes to 
``maintenance only'' targets submitted by recognized developers.
 >
 > All recognized developers can make mechanical changes (by virtue of 
the obvious fix rule) to ``maintenance only'' targets.  The change shall 
  be sanity checked by compiling with one of the listed targets.
 >
 > The GAWK segment: ....

(I am not a lawyer)

Anyway, the motivation is pretty simple: I can't see any point in 
someone waiting for approval of their patch from me (or another global 
write maintainer?) when all I'm going to do is check for codeing, style 
and curent conventions.  Hmm, gdb_indent.sh and the nasty 
http://sources.redhat.com/gdb/ari/ do this - I'm kind of redundant.

I think it is better that someone in a position to build / test the 
change be given the oportunity to give the thumbs up.  (The emphasis 
being on _test_ :-)

Clearly the more popular / complex targets (MIPS, ARM, x86, PPC) are 
going to have maintainers and hence this change won't apply.

Depending on how this is received, I guess I should probably look at 
doing similar to the native platforms.

Several things to note: the obvious fix rule contains the clause 
``Something like changing or bypassing an interface is _not_ an obvious 
fix, since such a change without discussion will result in instantaneous 
and loud complaints''; I think GDB has an accepted convention of not 
committing patches until all problems/questions have been addressed; the 
above strengthened the sanity check bit to require (not just suggest) a 
build!

Risks?  The obvious risk is if two or more people get together and start 
submitting / approving patches that aren't up to scratch.  Then again, 
if two people are doing this but still meeting all of the above I can't 
see them doing too much damage :-)

thoughts?
Andrew

[maint] Commit rules for un-maintained targets ....

[Andrew Cagney]

Hello,

The current commit rule for un-maintained targets is:

> All maintainers can make arbitrary changes to OBSOLETE targets.
> 
> All maintainers can make mechanical (params, spelling, indentation,
> multi-arch, -W..., ....) changes to ``maintenance only'' targets.
> Please sanity check the change by compiling with one of the listed
> targets.
> 
> The GAWK segment:
> 
>   awk < "${maintainers}" '
>   $2 ~ /--target=.*/ {
>     targets = gensub (/^.*--target=/, "", 1, $2)
>     warnings = gensub (/[)]*$/, "", 1, $3)
>     split (targets, targ, /,/)
>     for (i in targ) {
>         print targ[i], warnings
>     }
>   }'
> 
> can be used to generate a full list of --target=
> --enable-gdb-build-warning= pairs.


I'd like to propose a change so that it is something like:


 > All recognized developers can make arbitrary changes to OBSOLETE targets.
 >
 > All maintainers can test and thence approve non-trivial changes to 
``maintenance only'' targets submitted by recognized developers.
 >
 > All recognized developers can make mechanical changes (by virtue of 
the obvious fix rule) to ``maintenance only'' targets.  The change shall 
  be sanity checked by compiling with one of the listed targets.
 >
 > The GAWK segment: ....

(I am not a lawyer)

Anyway, the motivation is pretty simple: I can't see any point in 
someone waiting for approval of their patch from me (or another global 
write maintainer?) when all I'm going to do is check for codeing, style 
and curent conventions.  Hmm, gdb_indent.sh and the nasty 
http://sources.redhat.com/gdb/ari/ do this - I'm kind of redundant.

I think it is better that someone in a position to build / test the 
change be given the oportunity to give the thumbs up.  (The emphasis 
being on _test_ :-)

Clearly the more popular / complex targets (MIPS, ARM, x86, PPC) are 
going to have maintainers and hence this change won't apply.

Depending on how this is received, I guess I should probably look at 
doing similar to the native platforms.

Several things to note: the obvious fix rule contains the clause 
``Something like changing or bypassing an interface is _not_ an obvious 
fix, since such a change without discussion will result in instantaneous 
and loud complaints''; I think GDB has an accepted convention of not 
committing patches until all problems/questions have been addressed; the 
above strengthened the sanity check bit to require (not just suggest) a 
build!

Risks?  The obvious risk is if two or more people get together and start 
submitting / approving patches that aren't up to scratch.  Then again, 
if two people are doing this but still meeting all of the above I can't 
see them doing too much damage :-)

thoughts?
Andrew

[repost] [maint] Commit rules for un-maintained targets ....

[Andrew Cagney]

Hello,

The current commit rule for un-maintained targets is:

All maintainers can make arbitrary changes to OBSOLETE targets.

All maintainers can make mechanical (params, spelling, indentation,
multi-arch, -W..., ....) changes to ``maintenance only'' targets.
Please sanity check the change by compiling with one of the listed
targets.

The GAWK segment:

  awk < "${maintainers}" '
  $2 ~ /--target=.*/ {
    targets = gensub (/^.*--target=/, "", 1, $2)
    warnings = gensub (/[)]*$/, "", 1, $3)
    split (targets, targ, /,/)
    for (i in targ) {
        print targ[i], warnings
    }
  }'

can be used to generate a full list of --target=
--enable-gdb-build-warning= pairs.


I'd like to propose a change so that it is something like:


> All recognized developers can make arbitrary changes to OBSOLETE targets.
>
> All maintainers can test and thence approve non-trivial changes to ``maintenance only'' targets submitted by recognized developers.
>
> All recognized developers can make mechanical changes (by virtue of the obvious fix rule) to ``maintenance only'' targets.  The change shall  be sanity checked by compiling with one of the listed targets.
>
> The GAWK segment: ....

(I am not a lawyer)

Anyway, the motivation is pretty simple: I can't see any point in someone waiting for approval of their patch from me (or another global write maintainer?) when all I'm going to do is check for codeing, style and curent conventions.  Hmm, gdb_indent.sh and the nasty http://sources.redhat.com/gdb/ari/ do this - I'm kind of redundant.

I think it is better that someone in a position to build / test the change be given the oportunity to give the thumbs up.  (The emphasis being on _test_ :-)

Clearly the more popular / complex targets (MIPS, ARM, x86, PPC) are going to have maintainers and hence this change won't apply.

Depending on how this is received, I guess I should probably look at doing similar to the native platforms.

Several things to note: the obvious fix rule contains the clause ``Something like changing or bypassing an interface is _not_ an obvious fix, since such a change without discussion will result in instantaneous and loud complaints''; I think GDB has an accepted convention of not committing patches until all problems/questions have been addressed; the above strengthened the sanity check bit to require (not just suggest) a build!

Risks?  The obvious risk is if two or more people get together and start submitting / approving patches that aren't up to scratch.  Then again, if two people are doing this but still meeting all of the above I can't see them doing too much damage :-)

thoughts?
Andrew