On 20. Jun, 2013, at 19:45, Ryan Ollos wrote: > On Mon, Jun 17, 2013 at 4:42 AM, Ryan Ollos <[email protected]> wrote: > >> On Mon, Jun 17, 2013 at 4:31 AM, Matevž Bradač <[email protected]>wrote: >> >>> >>> On 17. Jun, 2013, at 11:25, Ryan Ollos wrote: >>> >>>> On Wed, May 29, 2013 at 8:20 PM, Ryan Ollos <[email protected]> >>> wrote: >>>> >>>>> On Sun, May 19, 2013 at 6:05 PM, Ryan Ollos <[email protected] >>>> wrote: >>>>> >>>>>> On Fri, May 17, 2013 at 3:53 AM, Joachim Dreimann < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Regarding the 0.6 release: >>>>>>> >>>>>>> I've not seen any specific objections in this thread to that being >>>>>>> released >>>>>>> - other than relations being "about two weeks away". That as about >>> two >>>>>>> weeks ago. It appears to be in a stable state judging by our latest >>>>>>> nightly >>>>>>> build[1]. >>>>>>> >>>>>>> Our last release has now been over a month ago (a bug fix), while out >>>>>>> last >>>>>>> 0.x release was packaged up over two months ago. Any improvements >>> that >>>>>>> have >>>>>>> gone into trunk since are not available to those downloading >>> Bloodhound >>>>>>> every day[2]. >>>>>>> >>>>>>> I believe we should package up a release in the next few days, then >>> move >>>>>>> on >>>>>>> to working towards 0.7. Are there any volunteers for release manager? >>>>>>> >>>>>>> Cheers, >>>>>>> Joe >>>>>>> >>>>>>> [1] https://bh-demo1.apache.org/products/%40/ticket/156 >>>>>>> [2] http://goo.gl/#analytics/goo.gl/D4hf5/month >>>>>> >>>>>> >>>>>> I'm happy to do this release if others are busy working on the final >>>>>> features. >>>>>> >>>>> >>>>> I'm thinking of starting to prepare the release on Saturday since I >>> have a >>>>> solid 2 days free before then to do testing, and about a dozen minor >>> things >>>>> I'd like to fix before the release. Please let me know if you see any >>>>> issues with this plan. >>>>> >>>>> Thanks, >>>>> - Ryan >>>>> >>>> >>>> >>>> You will no doubt have noticed that I still have not started the release >>>> process. I believe there are still too many important issues that need >>> to >>>> be resolved, and through last week the number of issues was increasing >>>> rather than decreasing as we got feedback from users on IRC and the >>> mailing >>>> list. >>>> >>>> The 14 open tickets in Milestone Release 6 represents the issues that I >>>> think should be resolved. There are a few that could be rolled forward: >>>> #501, #461, #444, #201; but I've left those in the milestone because >>> they >>>> are close to being resolved. At least two of those 14 tickets have >>> patches >>>> from Olemis that just need to be reviewed and applied, and several other >>>> tickets just need minor follow-up. >>>> >>>> There are two important issues, #554 and #548, that I'm giving priority >>> to >>>> at the moment, and I also have a bloodhound.db file from avp that came >>> out >>>> of a discussion on IRC. He had a fairly complex series of problems that >>>> started with the "qct not defined" error that was resolved in #544, but >>>> even after that issue is resolved he still cannot create tickets. I will >>>> open a ticket for that after I have some time to sort out the discussion >>>> that took place on the mailing list and can describe the issue in >>> detail. >>>> >>>> It would be nice to get the release out as soon as possible, but I feel >>> it >>>> is more important to resolve these issues, otherwise we will cause our >>>> users problems and end up devoting more of our time supporting users >>> that >>>> experience those problems. >>>> >>>> - Ryan >>> >>> I see that most of the tickets for Milestone Release 6 are assigned to >>> you. >>> Would it help if others try to tackle at least some of them? >>> >> >> Yes, definitely. #548 and #554 would probably be solved much quicker by >> anyone that is more familiar with the MultiProduct architecture. Thanks! >> > > #568 and #569 are both potential blockers for the release. Please take a > look and let me know if you consider them to be blockers. > > https://issues.apache.org/bloodhound/ticket/568 > https://issues.apache.org/bloodhound/ticket/569
The #568 I think is a blocker, since we allow setting default_product to a non-existing product prefix. This causes tickets to be created in that (non-existing) scope, and also results in widget and query errors (TicketQuery -> LookupError). IMO, if the default_product does not exist, we should: 1. check whether the preset default (@) exists and use that 2. if @ is not available, use the first product in the DB (and a warning to the user would also be nice) For the #569 I'm not sure, it has less dire consequences. I suppose we could move it to 0.7 and list it under known issues if everyone agrees. -- matevz
