Tickets: Milestone vs. Version

[Gedare Bloom]

On Sat, Aug 11, 2018 at 5:14 AM, Chris Johns <chrisj at rtems.org> wrote:
> On 11/8/18 6:31 am, Gedare Bloom wrote:
>> On Fri, Aug 10, 2018 at 2:10 AM, Chris Johns <chrisj at rtems.org> wrote:
>>> On 10/08/2018 15:41, Sebastian Huber wrote:
>>>> On 10/08/18 07:38, Chris Johns wrote:
>>>>> On 10/08/2018 15:03, Sebastian Huber wrote:
>>>>>> we want a ticket for each milestone in which it is resolved. What is now the
>>>>>> meaning of the version field?
>>>>>>
>>>>> A ticket may be assigned to a branch but not a milestone. Milestones lets us
>>>>> select which tickets we fix on branch. Once all tickets on a milestone are
>>>>> closed the release can be made.
>>>>>
>>>>> We do not work that way at the moment. I use the milestones when making releases
>>>>> to move tickets scheduled for a release that are not closed to the next release.
>>>>
>>>> This doesn't explain the version field. Is version the same as branch from your
>>>> point of view?
>>>>
>>>
>>> The branch is the version of RTEMS released from that branch. In trac it is
>>> called version, ie 4.11, 4.10, 5 etc. The term version is more accurate, the use
>>> of branch is actually a VC implementation detail.
>>>
>>
>> I had understood we should use 'version' field in Trac to indicate
>> when the bug first appeared.
>
> If a bug appears in 4.11 and we say the bug is no longer present on 5 because
> things has changed do we close the bug even it is still present on 4.11?
>
> If a bug is present in 4.11 and raised against it however is fixed in 5 is
> closing that bug valid if still present in 4.11?
>
> What happens if someone finds a bug in 5 that is also present on 4.11, etc,
> which is what started this thread, and it is only fixed on 4.11?
>
>> If this is not the case, then definitely
>> (a) we need more guidance,
>
> I think this discuss highlights we need to improve what we have. Thank you for
> questioning what is being said. The page I did was focused on the release
> process at the time. It is far from complete.
>
> and (b) we probably need a way to indicate
>> (our best guess about) when a bug appeared.
>
> Do we? If we decide what I have said above is correct, which is not a given,
> then we would need a ticket on each version (branch) it is present on. The bugs
> have the creation date.
>
> My understanding of Trac is the relationships are sort of direct and so I am not
> sure there is a way to view the complexity of a bug the way we see in it's
> database. Also I am fine with Trac. I suspect increasing a tool's complexity to
> handle what we want brings it's own set of issues.
>
> Maybe it would be helpful to list what I see we need:
>
> 1. View open tickets on any version of RTEMS.
> 2. View closed tickets on any version of RTEMS.
> 3. Machine generated release notes.
> 4. ??
>
> I see viewing open tickets on a version as a query for that version of RTEMS for
> any tickets that are not closed. Viewing closed tickets is a pretty simple
> query. Release note generation is keyed off the milestone.
>
> I am not saying what we have is prefect, optimal etc and it does mean we need to
> do more work cloning tickets when back porting fixes.
>

Thank you for the clarification. This set of requirements (1-3) makes
sense to me. I guess it is not worth the complexity to have the
ability to show when a bug is known to exist.

Gedare