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

Chris Johns chrisj at rtems.org
Tue Aug 7 01:18:00 UTC 2018

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.

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.

> Chris used the blocked by field to link such tickets:
> https://devel.rtems.org/ticket/3323

I did this to make sure I knew which tickets are part of the same task.

> I used update commits in the past and a close commit for the first milestone, e.g.
> https://devel.rtems.org/ticket/2622

I have done similar things. We are improving how we work.


More information about the devel mailing list