Hi Tim, So, there's different ways that the Evergreen Community has applied milestones for tracking over the years and some of the concepts have changed over time depending on the nature of the release process and the specific bugs involved. For some additional history, in the past, we used to apply milestones more frequently, but this led to massive email churn with frivolous bug report change emails being sent to all bug wranglers noting each time we moved milestones for bugs as timelines slipped and code was not made available for final review.
Generally speaking though, this is what I assume to happen at this point (and how I personally have decided to work with milestones): 1) Milestones for wishlist bugs for new features may be assigned to the next release for future review before they are fully finished. For example, assigning a new feature bug to 2.next may be appropriate if you expect that code may be ready by the time of the initial review process. This is intended for developers/contributors to show their plans ahead of time and work towards completion of those bugs prior to the start of the review process. As new milestones are added for the 2.7 series, bugs may shift milestone targets depending on how much work developers add to their bug tickets. So a bug might start with a target of 2.next, go to a more specific target of 2.7.0-alpha1, but slip in the timeline and get a final resting milestone of 2.7.0-beta1. 2) Bug reports / fixes may be assigned to the actual milestone where we plan to include the fix. These normally only get specific milestones now when there is working code to test and there is a "pullrequest" tag applied to the bug ticket. Occasionally, we may also add specific milestones where we intend to apply a bug ticket as a "blocker" against the release of that particular milestone, but this is reserved for the most severe bugs. The way to know whether a bug is applied to a specific release milestone is nominally controlled via the bug's status in LP (see http://evergreen-ils.org/dokuwiki/doku.php?id=dev:bug_wrangler:faq for more details on the meaning of various LP statuses). That said, what you're looking for is that the bug is either "Fix Committed" (meaning we've added the attached code to one of the official repos) or it's "Fix Released" meaning that we've actually made a tarball Evergreen release that's on the Downloads page of the Evergreen website and publicly available. Either of these statuses and the milestone attached to the given row should indicate that the bug is complete and in a particular tagged version of Evergreen. -- Ben On Fri, May 2, 2014 at 8:49 AM, Tim Spindler <[email protected]> wrote: > I hit send too quickly > > I'm trying to understand launchpad bugs and I see this one for instance. > > https://bugs.launchpad.net/evergreen/+bug/1086550 > > And i see text such as: > > Changed in evergreen:*milestone*:2.5.0-m1 → none > > I'm not sure what this means exactly. > > > and in another bug there is > > > Changed in evergreen:*milestone*:2.6.0-beta1 → 2.6.0-rc1 > > Does this mean the code has been included for 2.6? > > > Thanks, > > > > On Fri, May 2, 2014 at 8:47 AM, Tim Spindler <[email protected]> wrote: > >> I'm trying to understand launchpad bugs and I see this one for instance. >> >> https://bugs.launchpad.net/evergreen/+bug/1086550 >> >> And i see text such as: >> >> Changed in evergreen:*milestone*:2.6.0-beta1 → 2.6.0-rc1 >> >> -- >> Tim Spindler >> [email protected] >> >> *P** Go Green - **Save a tree! Please don't print this e-mail unless >> it's really necessary.* >> >> >> > > > > -- > Tim Spindler > [email protected] > > *P** Go Green - **Save a tree! Please don't print this e-mail unless > it's really necessary.* > > > -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
