On Sat, Aug 11, 2018 at 5:14 AM, Chris Johns <chr...@rtems.org> wrote: > 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. >
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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
