RSB repo commits need approval

Chris Johns chrisj at rtems.org
Sun Apr 30 21:53:45 UTC 2023



On 29/4/2023 3:48 am, oss at c-mauderer.de wrote:
> Hello Joel,
> 
> Am 28.04.23 um 00:19 schrieb Joel Sherrill:
>>
>>
>> On Wed, Apr 26, 2023 at 7:06 PM Chris Johns <chrisj at rtems.org
>> <mailto:chrisj at rtems.org>> wrote:
>>
>>     Hi,
>>
>>     All RSB repo commits need to be posted for review and independent
>>     approval given
>>     before being pushed to the top level repo.
>>
>>
>> I thought this was the policy for all top level repositories. There is a
>> degree of trust
>> on any posted patch that it has been tested by the submitter with the
>> understanding
>> that things do slip through. If someone is regularly submitting modifications
>> without
>> testing them, then we have a larger problem.
> 
> Regarding the policy: I think that is documented in the rtems.git in the
> MAINTAINERS-file:
> 
>   https://git.rtems.org/rtems/tree/MAINTAINERS
> 
> We have a few people who are trusted to distinguish between patches that can be
> pushed without review and patches that should get a review while all other
> should post a patch for review and wait at least for a few days before pushing
> it (for BSP specific stuff) or need an acknowledge (for general stuff).
> 
> 
> Chris: Is that a temporary rule for the blanket write privilege maintainers
> while trying to reach a stable release version? Is there a difference between
> the tools starting with "6/" (which should be the release version) and the ones
> that start with "7/" (which are more or less an unstable test version)?

I think we should post all because it is simpler but it is a good and valid
question. A reason to post all changes is questions or a wrong interpretation
can be resolved up front. I also understand how much better and simpler a pull
request system would have on this process but it is not up and running at the
moment.

I only addressed the RSB with this post and it was done with the agreement of
Joel and Gedare. I did not just make the decision myself. We would like more
detail in some commit messages and a review may be a way to handle that.

Chris


More information about the devel mailing list