Tickets: Milestone vs. Version

Chris Johns chrisj at
Sat Aug 11 09:14:46 UTC 2018

On 11/8/18 6:31 am, Gedare Bloom wrote:
> On Fri, Aug 10, 2018 at 2:10 AM, Chris Johns <chrisj at> 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.


More information about the devel mailing list