On Sat, Jan 24, 2015 at 5:00 PM, Olemis Lang <[email protected]> wrote:
> On 1/24/15, Ryan J Ollos <[email protected]> wrote: > > So that we have a goal to work towards, Release 9 has been created with a > > moderate number (currently 10) of tickets, and the goal of releasing on > 01 > > March. > > > > Nice ! > > > Most of the tickets fit the following criteria: > > 1. High priority issues reported by the community (#813, #840, #845, > #846) > > Would be nice to fix these , yes > > > 2. In-progress tickets that were not complete for Release 8 (#695) > > I could test this , though test cases have been proposed afaicr ... > > > 3. Minor cosmetic issues that should be easy to fix (#634, #842) > > > > ... and try to take a look into these as well . > > > I hope devs will feel free to pick up and work any of these tickets, > > I'll try to follow your call on this subject . Nonetheless considering > the *apparent* synchronization of Trac + BH releases , would it be > worthy to upgrade the version of Trac distributed with BH and keep > them in sync ? > I think it is a worthy aim to continually pull Trac releases to Bloodhound. Before I retargetted tickets in the milestones, "Release 9" was full on tickets that are needed to integrate Trac 1.0.2 into Bloodhound. However, the list of tickets is not complete for 1.0.2 as I lost track of it after a while, and doesn't included any of the tickets needed for Trac 1.0.3 integration. The tickets for Trac 1.0.2 were moved to Release 10, and currently number 30. https://issues.apache.org/bloodhound/query?status=!closed&keywords=~trac-1.0.2 Trac maintains a stable API, but the Trac codebase has been hacked-up to make multi-product work, and the templates replaced as well, so the merge and integration is not trivial. That leaves me feeling that it's too much work to deal with the 30+ ticket needed for integration, and we are better off focusing in the short term on putting out a release with some critical fixes. If that happens, and we have some momentum, then we may be in a better position to look at integrating Trac 1.0.2 and 1.0.3. By that time there will have been at least one more Trac release, probably two releases since I introduced a regression in 1.0.3 that warrants immediate release of 1.0.4. > > > as > > well as target any other important issues to the milestone. > > > > It will be good > > to keep the scope of the milestone fairly small though, so that we can > > achieve the goal of releasing on March 1. > > > > yes , I do think that contributors will be much more motivated if the > project releases early and is constantly moving towards next milestone > . > > Nevertheless scheduling for April (i.e. one month after Trac's) might > help with testing BH core after merging latest Trac release , in case > that's something worth doing for Release 9 . We could also merge Trac > core twice a year (i.e. six month time window) > > p.s. I'm planning to attend PyCon this year too so I'm also hoping to > meet you (and others interested on Trac + BH development) there during > sprints . > I'll be at PyCon, but may only be able to stay for one-half day of the sprints. I do hope to make it to the two pre-conference days of training though. I'll be looking forward to meeting up with you again, and hope we can generate interest from others, even if just for a meeting and discussion.
