Tickets: Milestone vs. Version

[Chris Johns]

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.

Chris