[PATCH] rfs: Remove erroneous call of rtems_disk_release()

[Sebastian Huber]

On 07/08/18 03:18, Chris Johns wrote:
> On 06/08/2018 23:21, Sebastian Huber wrote:
>> On 06/08/18 15:03, Joel Sherrill wrote:
>>> On Mon, Aug 6, 2018, 3:01 AM Sebastian Huber
>>> <sebastian.huber at embedded-brains.de
>>> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>>>
>>>      On 06/08/18 09:47, Chris Johns wrote:
>>>      > On 06/08/2018 16:13, Sebastian Huber wrote:
>>>      >> this needs a back port to 4.11 and 4.10.
>>>      >>
>>>      > I saw the ticket for 4.10 and assumed the patch was for 4.10. We
>>>      separate
>>>      > tickets for each branch.
>>>
>>>      This makes the ticket handling a bit more complicated. Why is this
>>>      necessary? Are different tickets for the same bug really great? I
>>>      think
>>>      the rational is that if a bug is fixed in version x, then it is also
>>>      fixed in all versions x + i.
>>>
>>>
>>> It is a human assumption but it doesn't work out right for using Trac to
>>> generate release reports. Each ticket has a single milestone. So it would be
>>> fixed in 4.10.n but we don't know where along the 4.11 series it got fixed
>>> based on Trac 4.11 release reports.
>> Creating an arbitrary number of tickets for one bug looks like a workaround for
>> a Trac or release note generator shortcoming. Each ticket should probably have a
>> list of milestones.
> I am not so sure. I originally thought this a while back when I encountered the
> same thing. I also looked around for add-ons for Trac to handle this and I could
> not find one. I suspect the complexity at a database level of mapping this would
> not be simple.

Yes, there seems to be some structural problem with this in Trac. At 
least this bug is open for 14 years:

https://trac.edgewall.org/ticket/221

>
> A branch is an instance of RTEMS and each branch has it's own life cycle. A bug
> report that extends across multiple branches would break that isolation. A
> ticket may require extra work, other changes or something else and if the ticket
> is shared across more than one branch the other branches would become polluted.
>
> I see the release notes being generated from the Trac data as a really good
> thing. It is making us ensure we follow a proper process.
>
>> There should be definitely some guideline for this since this was at least not
>> obvious to me.
> Yes I agree.

Since multiple milestones per ticket are unrealistic in Trac and what 
you wrote above I think this plug-in is still useful:

https://trac.edgewall.org/wiki/TicketClone

The basic work flow is:

1. Add a ticket for the master.

2. Clone it for every branch the bug is applicable and adjust the 
milestone accordingly.

-- 
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.