[OPEN-ILS-DEV] Understanding Launchpad Bugs
Ben Shum
bshum at biblio.org
Fri May 2 09:10:07 EDT 2014
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 <tjspindler at gmail.com> 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 <tjspindler at gmail.com> 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
>> tjspindler at gmail.com
>>
>> *P** Go Green - **Save a tree! Please don't print this e-mail unless
>> it's really necessary.*
>>
>>
>>
>
>
>
> --
> Tim Spindler
> tjspindler at gmail.com
>
> *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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140502/9026ca26/attachment-0001.htm>
More information about the Open-ils-dev
mailing list