public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Joel Sherrill <joel.sherrill@oarcorp.com>
To: Jeff Johnston <jjohnstn@redhat.com>, Newlib <newlib@sourceware.org>
Subject: Re: [PATCH] newlib/MAINTAINERS: Add OS maintainers section and myself for RTEMS and Write After Approval.
Date: Wed, 14 Jun 2017 16:07:00 -0000	[thread overview]
Message-ID: <35bd4a26-95e3-9640-9383-773282cdfdee@oarcorp.com> (raw)
In-Reply-To: <CAOox84uLfx-KNaCyZq=andhtdaN0CkCRUX4Y+Jz6pvVQ4X5E+Q@mail.gmail.com>



On 6/14/2017 10:49 AM, Jeff Johnston wrote:
> It would have been nicer to ask first, but that said, I am ok with a
> clarification added to the definition.
> 
> For an OS maintainer, changes that add OS-specific changes to existing
> shared files need approval.  That means you may
> make changes to an existing RTEMS section of a header file, but you cannot
> add an RTEMS section to a
> header or source file that did not have such a section without approval.  I
> don't want to have RTEMS stuff added all over the
> place to save you having to have your own version in your directory.

It wasn't a power grab and I am sorry if it was perceived as such.
I didn't intend it to change anything in how anyone in the RTEMS
community approached newlib. We have been users for since before
1995 and have always submitted patches for review before merging.
I am pretty sure I have had the equivalent of write after approval
for 20 years.

I viewed updating that as contact information and a reflection
of existing practice. I post patches and wait for approval
(even for RTEMS specific parts) before committing.

I agree 100% that caution should be exercised when touching
common files. At the same time, sharing common source/header
files has value so it is worth posting patches and going
back and forth.

Again I apologize that more was read into that patch than
was intended.

--joel

> 
> -- Jeff J.
> 
> On Wed, Jun 14, 2017 at 4:50 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
>> On Jun 13 16:30, Joel Sherrill wrote:
>>> ---
>>>   newlib/MAINTAINERS | 7 +++++++
>>>   1 file changed, 7 insertions(+)
>>>
>>> diff --git a/newlib/MAINTAINERS b/newlib/MAINTAINERS
>>> index 6117ff4..0bd93ff 100644
>>> --- a/newlib/MAINTAINERS
>>> +++ b/newlib/MAINTAINERS
>>> @@ -45,6 +45,12 @@ aarch64                    Richard Earnshaw        richard.earnshaw@arm.com
>>>   msp430                       DJ Delorie              dj@redhat.com
>>>                        Nick Clifton            nickc@redhat.com
>>>
>>> +                     OS Port Maintainers     (OS alphabetical order)
>>> +
>>> +OS port maintainers may make changes in OS-specific directories, as
>>> +well as OS-specific portions of the build system, without approval.
>>> +
>>> +RTEMS                        Joel Sherrill           joel.sherrill@oarcorp.com
>>>
>>>                        Write After Approval
>>>
>>> @@ -57,3 +63,4 @@ Nick Clifton                        nickc@redhat.com
>>>   Eric Blake                   eblake@redhat.com
>>>   Will Newton                  will.newton@linaro.org
>>>   Sebastian Huber                      sebastian.huber@embedded-brains.de
>>> +Joel Sherrill                        joel.sherrill@oarcorp.com
>>> --
>>> 1.8.3.1
>>
>> On hold.  I'm still discussing this with Jeff.
>>
>>
>> Corinna
>>
>> --
>> Corinna Vinschen
>> Cygwin Maintainer
>> Red Hat

  reply	other threads:[~2017-06-14 16:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-13 19:31 Joel Sherrill
2017-06-14  8:50 ` Corinna Vinschen
2017-06-14 15:49   ` Jeff Johnston
2017-06-14 16:07     ` Joel Sherrill [this message]
2017-06-22  8:06     ` Sebastian Huber
2017-10-10 14:36 [PATCH 1/2] newlib/configure.host: Remove obsolete definition of _I386MACH_ALLOW_HW_INTERRUPTS Joel Sherrill
2017-10-10 14:36 ` [PATCH] newlib/MAINTAINERS: Add OS maintainers section and myself for RTEMS and Write After Approval Joel Sherrill
2017-10-11 10:53   ` Joel Sherrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=35bd4a26-95e3-9640-9383-773282cdfdee@oarcorp.com \
    --to=joel.sherrill@oarcorp.com \
    --cc=jjohnstn@redhat.com \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).