[rtems commit] posix: Fix pthread_spin_unlock()

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Oct 20 04:57:16 UTC 2020

On 20/10/2020 00:17, Chris Johns wrote:
> On 20/10/20 5:06 am, Gedare Bloom wrote:
>> On Mon, Oct 19, 2020 at 11:11 AM Sebastian Huber
>> <sebastian.huber at embedded-brains.de>  wrote:
>>> On 19/10/2020 18:53, Gedare Bloom wrote:
>>>> On Mon, Oct 19, 2020 at 9:48 AM Sebastian Huber
>>>> <sebastian.huber at embedded-brains.de>   wrote:
>>>>> On 19/10/2020 17:42, Joel Sherrill wrote:
>>>>>> This was reported against 4.11 which means it needs to be committed to
>>>>>> 4.11, 5, and master.
>>>>> It depends on the severity of the bug if I create tickets and back ports
>>>>> for this right now.
>>>> If we know the bug exists we should at least create tickets on the
>>>> open, affected branch(es).
>>>> When we know how to fix it, we should also at least reference that as
>>>> well. This way someone else can make the fix easier if they need it.
>>> I thought this is the purpose of the "version" field?
>> https://lists.rtems.org/pipermail/devel/2018-August/050685.html
>> The problem is that for example this ticket #4157 is closed. So how
>> does someone know the bug isn't fixed in 4.11 and 5?
>> It is a problem we face and why we end up duplicating all these
>> tickets in the first place. I don't know (if there is) a right answer.
> I think cloning tickets is the best solution we have. I cannot see a better path.

Not everything is equally important.

I did run the test suite in an unusual configuration, identified two 
unexpected test failures, debugged the tests, reported two issues with 
the first affected RTEMS version and a target milestone, and fixed the 
issues on the master. This is enough work for bugs which probably affect 
only one person on this planet.

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list