[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.
Chris
More information about the devel
mailing list