On 11/8/18 6:31 am, Gedare Bloom wrote: > On Fri, Aug 10, 2018 at 2:10 AM, Chris Johns <chr...@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 _______________________________________________ devel mailing list firstname.lastname@example.org http://lists.rtems.org/mailman/listinfo/devel