Logged by edavis10. US/Pacific time (GMT -8) 09:05 < edavis10> Lets get started then. 09:05 < edavis10> Welcome to the first ChiliProject Development Meeting 09:05 < meineerde> \o/ 09:06 < thegcat> /o\ 09:06 < edavis10> Thanks for coming. 09:06 < thegcat> oh wait, no, wrong direction ^_^" 09:06 < edavis10> I want to keep this meeting focused so we can end in 60-90 minutes. If we don't get to everything we can discuss things in the forums or at the next meeting. 09:06 < thegcat> for the record: the wiki page is wiki:Development_Meeting_0 09:06 < pepperbot> thegcat: wiki:Development_Meeting_0 is https://www.chiliproject.org/projects/chiliproject/wiki/Development_Meeting_0 "ChiliProject - Development Meeting 0 - ChiliProject" 09:06 < edavis10> thegcat: thanks 09:07 < edavis10> The main topic today is "What are our goals for the 2.0 release" 09:07 < edavis10> I'll start with a bit of background. 09:07 < edavis10> 2.0.0 will be our first major release where we can start to break backwards compatibility with Redmine and ChiliProject 1.x 09:08 < edavis10> It's currently scheduled for the end of August (8/28ish) but we might move it up based on what we decide today 09:08 < rchady> edavis10, you still looking for client work? 09:09 < edavis10> rchady: can we chat after the meeting? 09:09 < edavis10> The version page for 2.0.0 is at https://www.chiliproject.org/projects/chiliproject/versions/5 (for reference) 09:09 < rchady> oops, yes 09:10 < jschoolcraft> does 2.3.latest include bundler? 09:10 -!- dommeee [~Dominic@p5DDBA251.dip.t-dialin.net] has joined #chiliproject 09:11 < edavis10> Originaly I was planning on having 2.0.0 include library upgrades (Rails) as well as some new features. But meineerde and Gregor mentioned the idea of making 2.0 a library-upgrade only release. 09:11 < thegcat> jschoolcraft: iirc rails-2.3.latest works with bundler 09:12 < edavis10> So the first thing we need to discuss is: should we release 2.0 early and focus on library upgrades OR focus on new features too and keep the release date in summer.? 09:12 < jschoolcraft> thegcat: it does, I mean, is CP going to use bundler 09:12 < edavis10> jschoolcraft: I don't think it's included but 2.3.latest can be made to work with it 09:12 < edavis10> jschoolcraft: that's something we were thinking about discussing too 09:12 < thegcat> jschoolcraft: that's one of the points of the current meeting :-) 09:13 < happynoff> I think that moving to the latest rails 2.3.x could be could to avoid hacking around to work with rubygems, for instance 09:13 < jschoolcraft> very well :) 09:13 < meineerde> The main current issue is that Rails 2.3.5 gets more and more oainfull to keep maintained. We have to patch increasingly unrelated areas to keep the code usable 09:13 < RLa> what's the current main case to still use this old rails? 09:13 < thegcat> edavis10: I vote for an earlier "library upgrade only" release 09:13 < meineerde> also, the reloader is broken in 2.3.x (and especially in 2.3.5 09:13 < thegcat> rails 2.3.5 is a pain, we could get bundler in, and so on 09:14 < edavis10> RLa: plugins and third party code. Thought with our 1.1.0 the i18n problems should be going away a bit. 09:14 < thegcat> RLa: I think backwards compat 09:15 < edavis10> RLa: and also we needed an easy upgrade path from Redmine 1.0 => ChiliProject 1.1 without having people install newer Rails etc 09:15 < RLa> thegcat, you think plugins will be updated during the time when we get to 2.0 release? 09:15 -!- evtuhovich [~brun@94.198.48.35] has quit [Quit: Leaving.] 09:15 < thegcat> RLa: plugins should need only minor adjustments if any to work with 2.3.latest instead of 2.3.5 09:15 < meineerde> The main idea is that we release earlier with 2.3.11 (and some librarie updates), not only in August to ease the pain. 09:16 < meineerde> then, in August we could release a 3.0 (or 2.1, depending on the featureset) 09:16 < edavis10> meineerde: what would that do to the release schedule? Make August 3.0? Bump 3.0 to 6.months.from.release? 09:16 < RLa> are there known issues with 2.3.11 without considering plugins 09:17 < RLa> and libraries 09:17 < meineerde> RLa: I'm not aware of any. 09:18 < edavis10> RLa: I think there are a few but those issues are from the core code being at 2.3.5 and someone forcing it to use 2.3.11. If we upgrade then those should go away (though you never really know) 09:18 < thegcat> RLa: the rails engines on which the redmine/cp plugins are based should work the same in 2.3.11, only plugins that used rails 2.3.5-specific features/workarounds would have problems 09:18 < meineerde> RLa: but 2.3.11 get's updates (in contrast to 2.3.5) and we can prepare the migration to 3.x 09:19 < happynoff> and, redmine trunk is currently on 2.3.latest… so there is probably no reason to worry about it... 09:19 < edavis10> If I recall 2.3.8-2.3.11 are meant to get people upgraded to Rails 3. They are more of "stable" releases than in the past of Rails 09:19 < thegcat> ok, can we recenter on: 2.0 earlier than summer? major after that 6 months later or in summer "instead" of 2.0? 09:19 < RLa> but cp trunk is still 2.3.5? 09:20 < edavis10> RLa: yes, we are still 2.3.5 09:20 < edavis10> It sounds like upgrading to 2.3.latest is a good plan. We just need to decide if we want to do a release for it early then. 09:21 < jschoolcraft> all the security fixes been back ported to 2.3.5? 09:21 < jschoolcraft> haven't there been several? 09:21 < RLa> maybe there should be 2.3.latest code out before, that might lead to updated plugins 09:21 < meineerde> Here's my proposal for the release schedule: We release CP 1.2 sometime this month with the current minor bugfixes. We start the upgrade to 2.3.11 and some librarie updates in unstable. Then in about a month (or when we are finished), we release a final 1.3 if necessary and the 2.0. 09:21 < happynoff> Maybe we could just make a vote 09:22 < edavis10> jschoolcraft: most of them. We were lucky, 2.3.5 was before Rails 3 so most of the security/refactoring bugs weren't introduced. 09:22 < jschoolcraft> :) 09:22 < RLa> so final 1.3 will be last 2.3.5 version? 09:22 < edavis10> meineerde: then what about after that? 09:22 < meineerde> RLa: yes. 09:23 < meineerde> edavis10: after that, we "return" to our 6 month schedule for major releases 09:23 < ferggo> Seems to me that it might be less confusing to users if the rails 3 switchover happens on CP version 3.0. 09:23 < edavis10> meineerde: so say 2.0 is done in May (5th month) we would have 3.0 in November (5+6=11th month)? 09:24 < edavis10> ferggo: I think so too. plus we need to wait for Rails 3.1, which isn't out yet 09:24 < meineerde> edavis10: yes. that way, we could have a release either before the holidays (to allow users to try it), or during the early holidays as a present :) 09:24 < jschoolcraft> and no ship date for 3.1 yet either, right? 09:24 < edavis10> jschoolcraft: "When it's done" ;) 09:25 < happynoff> Do we all agree on that schedule ? 09:25 < ferggo> Does Ruby 1.9 happen along with Rails 3? 09:25 < edavis10> Ok, here is what I was thinking. It's similar to meineerde's proposal. 09:26 < meineerde> ferggo: I would consider ruby 1.9 in beta support today. The test-suit passes today 09:27 < ferggo> meineerde: Oh cool, I wasn't aware of that. 09:27 < edavis10> We define 2.0 now as a set of features/libraries to upgrade [A,B,C,D] with some people signing up to work on each one. All of this goes into "unstable". We keep development in "master" like normal. Once all of the features are done, we cut a 2.0 release with the upgrades and a final 1.x release. 09:27 < thegcat> edavis10: aye 09:27 < meineerde> edavis10: yay 09:27 < Khalsa> edavis10: +1 09:27 < edavis10> only real difference between mine and meineerde's is that it's not only "upgrades". I have some features that have been done and tested for over a year I'd like to add. :) 09:28 < ferggo> edavsi10: Agree 09:28 < happynoff> ok 09:28 < edavis10> ferggo: Ruby 1.9 is close. I'm going to start using it and try to catch some hidden bugs soon. 09:29 < meineerde> edavis10: I'm fine that include what's ready. I just want to set the focus on the library upgrade 09:29 < thegcat> ferggo: 1.9 will probably happen inbetween 2 and 3 09:29 < edavis10> Sounds like we are in agreement that 2.0 will be done when these features are done. Now what features :) 09:29 < edavis10> meineerde: you want to talk about bundler? You guys have the most experience there. 09:29 < thegcat> ferggo: we don't need to wait for a major release for 1.9 because it doesn't break previous compat 09:29 < rchady> One thing I'd like to see is the completion of those areas of Redmine that always felt unfinished/hacked up 09:29 < thegcat> while we're on rubies: what about 1.8.6? 09:29 < thegcat> can we kill/drop it? 09:30 < ferggo> thegcat: Sure, but making sure it's supported will distract developers from getting other features ready, so we should plan for when it's supported in production. 09:31 < meineerde> edavis10: schmidtwisser created a Gemfile at https://github.com/finnlabs/chiliproject-gemfile 09:31 < ferggo> One pet-peeve feature of mine is that you can natively export issues to CSV but no native import. There are a few plugins but they're pretty unfinished/hacked up 09:31 < meineerde> edavis10: this runs on ci.chiliproject.org to start the tests. 09:32 < edavis10> meineerde: do you think it could be ready in time for 2.0? Say this month or so? 09:32 < jschoolcraft> csv gets interesting in 1.9, FasterCSV got absorbed 09:32 < schmidtwisser> I guess we could integrate bundler -- after the update to 2.3.11 -- without hassles 09:32 < edavis10> jschoolcraft: we are requiring fastercsv already, unless it's 1.9 09:32 < schmidtwisser> we just need to update the docs accordingly -- and train our support staff 09:33 * jschoolcraft shuts up :) 09:33 < meineerde> thegcat: we would drop 1.8.6 support, as rails 2.3.11 doesn't support it itself 09:33 < meineerde> and it's broken anyways, so I'm fine with it :) 09:34 < thegcat> so 2.3.latest would mean +bundler -1.8.6 -bundled stuff if we manage to throw it out? 09:34 < meineerde> the only people who would be concerned by this anyways are RedHad 5.x and SuSE people (iirc) 09:34 < thegcat> I guess I'm liking this plan more and more :-P 09:34 < edavis10> thegcat: need to discuss the -bundled stuff still 09:34 < thegcat> edavis10: thus the conditional ;-) 09:35 < edavis10> table 1.8.6 for a second, should we require bundler in 2.0? 09:36 < meineerde> edavis10: I vote yes. 09:36 < ferggo> edavis10: What is the down-side other than adding a dependency? 09:36 < thegcat> seems most of the work for that seems to be available already, so aye 09:36 < jschoolcraft> it removes many dependencies by adding 1 09:36 < ferggo> jschoolcraft: my point exactly 09:36 < edavis10> ferggo: few bugs with it, but there are bugs with the existing gem system anyways. I think it's mostly training and documentation issues. 09:37 < ferggo> It seems like the Ruby community is converging on 'bundle install 09:37 < ferggo> ' being standard 09:37 < jschoolcraft> really hrad to beat: gem install bundler && bundle 09:37 < edavis10> Lets add bundler for 2.0. meineerde and schmidtwisser: you guys want to handle that part? 09:37 < schmidtwisser> sure, i would commit to that 09:38 < edavis10> great 09:38 < schmidtwisser> though I would probably need support for the docs part 09:38 < jschoolcraft> schmidtwisser: I'll pitch in with docs, just ping me 09:38 < edavis10> schmidtwisser: yea, by "handle" I mean lead. Everyone should help with each feature. 09:39 < edavis10> Ruby 1.8.6 now. I'd say keep it but not fix any 1.8.6-only bugs. Like what we do with IE6. 09:39 < thegcat> so: "might work, but not guaranteed"? 09:40 < meineerde> edavis10: then we could also drop it. it is a pain to still have it. 09:40 < edavis10> thegcat: yea 09:40 < thegcat> meineerde: are there any workarounds for 1.8.6 currently in CP? 09:40 < edavis10> meineerde: except for RedHat and Suse people. It's not a hard depend 09:40 -!- gidogeek [~gidogeek@wirelab.isp.be.nl] has quit [Quit: gidogeek] 09:41 < edavis10> thegcat: I see two 09:41 < edavis10> Fixed: r4417 breaks MercurialAdapter with ruby 1.8.6 (#5117). 09:41 < edavis10> Fixes a NoMethodError in tests with ruby 1.8.6. 09:41 < edavis10> can't get the shas right now 09:41 < meineerde> but it could have the same rumoured status as MSSQL or Oracle, i.e. not officially supported, but if you know what you are doing, it could work 09:41 < thegcat> ok, keep the ones we have, but don't work on new? 09:42 < edavis10> thegcat: yea. "It might work but we don't recommend or support it" 09:42 < thegcat> works for me 09:42 < edavis10> like maglev/rbx/jruby are right now 09:42 < schmidtwisser> the officially supported ruby versions would also be relevant for the gem file 09:42 < schmidtwisser> there are lots of incompatibilities in the database gems between versions 09:43 < schmidtwisser> e.g. latest pg gem dropped 1.8.6; latest mysql gem does not work with 1.8.6-latest 09:43 < schmidtwisser> what to do with these? 09:43 < jschoolcraft> mysql2 or mysql-latest ? 09:43 < edavis10> schmidtwisser: I think that would be the "not officially supported, but if you know what you are doing" => then you can edit the Gemfile 09:44 < schmidtwisser> edavis10: this would mean: it breaks out of the box 09:45 < edavis10> schmidtwisser: what do you propse then? 09:45 < schmidtwisser> i just wanted to make sure, that everybody is aware of the issue. i'm happy to drop 1.8.6 09:46 < schmidtwisser> IMO it is a security risk to run 1.8.6 09:46 < edavis10> schmidtwisser: why don't you target the gemfile at 1.8.7+ and we can document how to change it to do 1.8.6 if there is no way to upgrade. 09:47 < edavis10> honestly, I think 1.8.6 is such a minority now. But we need to be clear so people can expect it to be phased out. 09:47 < schmidtwisser> agreed 09:48 < edavis10> Related to the Rails upgrade: how often should we be pulling in code from Redmine's trunk? 09:48 < ferggo> Even Microsoft doesn't like IE6 anymore. At some point, you just have to move on. ;) 09:48 < Khalsa> edavis10: how often is convienient? 09:48 < ferggo> edavis10: Is it possible to just pull in any patches that look useful using Github or something? 09:49 < edavis10> Khalsa: I was thinking every major release but we'd miss some bugfixes mid-release. Every minor is too difficult for me. 09:49 < meineerde> edavis10: also 2.3.11 doesn't support 1.8.6. Se support would needed to be dropped in cp 2.0 anyways 09:49 < edavis10> ferggo: possible yes, but we would need to keep track of what was pulled/no-pulled. e.g. this patch depends on those other 7 but we had to manually merge.... etc :( 09:49 < edavis10> meineerde: you have a source for 2.3.11 + 1.8.6? I couldn't find anything 09:50 < edavis10> What do you guys think about every other month for pulling in Redmine patches? That will give us some time to discuss and implement/skip but still keep close on some parts. 09:51 < edavis10> (50 minute mark) 09:51 < thegcat> edavis10: we could try it, but I think it's more a "let's try it and if it doesn't work, try it another way" 09:51 < thegcat> thing 09:52 < edavis10> thegcat: yea. Then I'll do another review at the beginning of April, which should pull in most of 2.3.11. 09:54 < meineerde> edavis10: hmmm, can't find it now either. But at least for 3.0 it's officialy dropped 09:54 < edavis10> Shall we go through the libraries now and 1) decide about un-bundling for 2.0 2) pick who will do the dev? 09:54 < Khalsa> seconded on the try it and find out :) 09:56 < meineerde> edavis10: libraries would be rubytree, net-ldap, awesome_nested_set, redcloth, coderay 09:56 < thegcat> edavis10: seeing how little time is left I'd say: if someone feels like unbundling, let him/her propose it and discuss in the ticket 09:56 < schmidtwisser> i already successfully removed rubytree in #269 https://github.com/chiliproject/chiliproject/pull/19 09:56 < pepperbot> schmidtwisser: #269 is https://www.chiliproject.org/issues/269 "ChiliProject - Feature #269: Refactor lib/redmine/menu_manager.rb to increase extensibility - ChiliProject" 09:57 < thegcat> acts_as_journalized and the helpers would be my wishes for the time left 09:57 < edavis10> I agree with thegcat. I don't think unbundling will give use much other than the ability to upgrade, which could be in a ticket. 09:58 < edavis10> helpers, release 1.3, and acts_as_journalized is left then 09:58 < edavis10> Helpers: "Add helpers :all to ApplicationController?" https://www.chiliproject.org/boards/2/topics/121 09:58 < thegcat> so the upside is to not to worry about them, what's the downside? 09:58 < edavis10> +: will make all bugs from missing helper methods go away, will make it easier for plugins to add their own helpers without patching controller 09:59 < thegcat> possible method name overlap and bigger lookup tables? 09:59 < edavis10> -: might cost a bit of memory or performance (probably nothing compared to normal though) 09:59 < happynoff> Sorry to interupt guys, but I have to go :( will you write a report on what has been decided here ? 09:59 < schmidtwisser> i guess the naming conflicts would be the only real issue here 09:59 < edavis10> thegcat: yea, possible name conflict though that should be found when switching 10:00 < thegcat> happynoff: I don't think anyone has announced he would write minutes yet 10:00 < edavis10> happynoff: I'm taking notes on major items. I think Khalsa has a logger setup too. 10:00 < thegcat> but there will be, yes 10:00 < thegcat> s/be/be some/ 10:00 < pepperbot> thegcat meant: "but there will be some, yes" 10:00 < happynoff> Ok, thanks :) 10:01 < Khalsa> http://chat.chiliproject.org/log/irc.freenode.net/chiliproject/today 10:01 < happynoff> ok :) 10:01 < happynoff> see you then ;) 10:01 < edavis10> schmidtwisser: and actually, naming conflicts should be resolved anyways. 10:01 < meineerde> Personally, I like clear dependencies. But I guess it's mor convinient to have helpers :all. 10:01 -!- happynoff [~happynoff@gw-puteaux.linagora.com] has left #chiliproject [] 10:02 < thegcat> I like clear dependencies better too, but I'd be OK to give helper :all a try 10:02 < meineerde> would helpers :all also apply to engine helpers? 10:02 < edavis10> Sounds like we should try helpers :all then 10:03 < edavis10> meineerde: I think so but I'm not totally sure 10:03 < schmidtwisser> meineerde: afaik - engine helpers are not automatically included. i think i stumbled a related bug report 10:04 < edavis10> schmidtwisser: I'll try it out and see 10:04 < schmidtwisser> the safest bed would be to simly test it 10:05 < schmidtwisser> edavis10: yep 10:05 < meineerde> this should be consistent. So if we include it, it should be included (and if it just by a custom callback) 10:05 < meineerde> apart from that, I'd be fine with trying it. 10:05 < edavis10> Release 1.2 - it's scheduled for next weekend-ish. So if there are any bug fixes or minor features, we need to get them in ASAP. 10:06 < edavis10> I have time set aside this weekend to review the issues and pull requests but I'd like some help if possible. 10:07 < thegcat> I should have some time to go through some of it too 10:07 < thegcat> esp. the git-smart-http stuff 10:08 < edavis10> ok thanks 10:08 < edavis10> I think we can wrap up with the acts_as_journalized then 10:09 < thegcat> if it's compatible to the current interface, no objections 10:09 < edavis10> last I heard, it needs to be rebased onto unstable and then reviewed. Is that correct? 10:09 < thegcat> though I haven't had a close look yet, so I can't provide arguments for it either 10:10 < meineerde> edavis10: yes. It needs rebasing and is fine then. 10:10 < meineerde> what we'd need to decide is if we want to keep the legacy API. 10:10 < edavis10> what version should we target too? 10:11 < thegcat> regarding the legacy API: keep it in 2.0 but deprecate it, drop it in 3.0? 10:11 < thegcat> would that be feasible? 10:12 < edavis10> Tim isn't here is he? 10:12 < meineerde> phlebas: ? 10:13 < edavis10> Here is my opinion: I'd like to get this feature in soon because I could use it. But if 2.0 is mostly an upgrade release, I'm not sure how that would fit. 10:13 < thegcat> mostly doesn't mean exclusively 10:14 < meineerde> edavis10: I'd like to have it in too. And I hink 3.0 would be too late 10:14 < thegcat> and I could also argue that aaj is an upgrade to the current stuff ;-) 10:14 < edavis10> thegcat: and I can argue that Rails 3 is an upgrade to Rails 1 but I won't ;) 10:15 < edavis10> if someone can rebase and squash aaj onto/into unstable, I can commit to reviewing and testing it. 10:15 < thegcat> so I'd say get it in, deprecate the "old" API in CP2 and plan to drop it in CP3, discuss before CP3 if we really can drop it or if we should keep it another round 10:16 < edavis10> thegcat: yea, I'd say table the "drop old API" for later. I still don't know which methods are the "old" API. 10:17 < thegcat> edavis10: well, if we include aaj in CP2 we should also deprecate what aaj replaces, otherwise there's no point in replacing it 10:17 < edavis10> so is anyone here able to commit to rebasing it? 10:18 < thegcat> whether to drop it in CP3 or later we can decide in time 10:18 < thegcat> +due 10:18 < edavis10> thegcat: I think it's wrapper methods. So the new code mimics the old code but uses the newer models/etc 10:18 < meineerde> edavis10: https://github.com/finnlabs/acts_as_journalized/blob/master/lib/redmine/acts/journalized/deprecated.rb 10:19 < meineerde> edavis10: I talked to phlebasand he volunteered to rebase it. I'm going to schedule it with him. 10:19 < edavis10> meineerde: thanks 10:19 < edavis10> x2 10:19 < meineerde> edavis10: the deprcated API is mostly one file which gets included 10:20 < edavis10> meineerde: when he rebases, can you have him squash commits too? I saw a bit of trial and error in the commits and I'd like to have them readable. 10:20 < edavis10> meineerde: I want to review each commit separately instead of the whole thing because this is such a critical piece. 10:21 < meineerde> edavis10: the patches were developed with redmine 0.9 as a target and later rebased the trunk. 10:22 -!- dommeee [~Dominic@p5DDBA251.dip.t-dialin.net] has quit [Quit: Leaving.] 10:22 -!- jschoolcraft [~jschoolcr@pool-96-255-28-160.washdc.fios.verizon.net] has quit [Remote host closed the connection] 10:23 < edavis10> I think that's it then. 10:23 < meineerde> okay, do we have a consens to trying to add aaj to 2.0 with the deprecation api included? 10:23 < meineerde> (and to drop this in 3.0?) 10:24 < edavis10> meineerde: oh yea. Add aaj to 2.0 if it's ready in time. Maybe drop old api later on. 10:24 < meineerde> \o/ 10:24 < meineerde> okay, final question, what is the target date for 2.0 then? 10:25 < edavis10> meineerde: I'd say keep it in August until things are done. Then we can set a new date. 10:25 < edavis10> meineerde: so it really depends on how fast everyone works 10:25 < thegcat> 1.3 + 1 week if we manage until then 10:25 < meineerde> edavis10: veto. 10:26 < meineerde> edavis10: I'd merely target mid-may. to have a target in sight 10:26 < edavis10> what's in scope? 10:26 < thegcat> aaj, 2.3.11, bundler 10:26 < edavis10> [Rails 2.3.11, Redmine patch pull, bundler, helpers :all, aaj] 10:27 < thegcat> ah, helpers 10:27 < meineerde> edavis10: that + all libraries we can pull out. 10:27 < thegcat> that'd throw the redesign out though 10:27 < edavis10> helpers :all are nothing, few minutes of my time 10:27 < edavis10> thegcat: yea, moving the redesign out 10:27 < schmidtwisser> FYI: helper :all breaks 2 functional tests in the attachments controller - ergo it should be doable 10:27 < schmidtwisser> at least on my machine 10:27 < meineerde> we can do the redesign in 2.x 10:28 < edavis10> I'm doing the Rails 2.3.11 and Redmine pull. It will take at least 2-3 weeks for that, assuming we can discuss things quickly in the Forums 10:28 < edavis10> schmidtwisser: thanks 10:28 < thegcat> edavis10: we should then either include the current theme or at least maintain it alognside chiliproject in gh.com/chiliproject 10:28 < edavis10> meineerde: redesign is still 2-3 weeks out plus a lot of discussion about depends. 10:28 < edavis10> notice how when a date is proposed, the scope starts to grow ;) 10:29 < meineerde> edavis10: but when we don't propose a date, the scope is infinite. 10:29 < meineerde> s/when/if/ 10:29 < pepperbot> meineerde meant: "edavis10: but if we don't propose a date, the scope is infinite." 10:29 < edavis10> meineerde: such is software :) 10:29 < thegcat> edavis10: I didn't want to grow the scope, just to point that specific point out 10:30 < edavis10> so for me, I need at least 3-4 weeks to get my 2.0 stuff dev'd. What about everyone else? 10:30 < schmidtwisser> edavis10: do you see a dependency between bundler and 2.3.11? In an ideal world, we would do 2.3.11, bundler, remove bundled stuff 10:30 < schmidtwisser> should we try to stick to that or not? 10:31 < edavis10> schmidtwisser: I think "remove bundled stuff" is optional at this point 10:31 < edavis10> but yea, 2.3.11 before bundler 10:31 -!- jhulten [~jhulten@c-24-19-51-222.hsd1.wa.comcast.net] has joined #chiliproject 10:31 < edavis10> so bunlder can't start until I"m done, which is in 3-4 weeks out 10:31 < schmidtwisser> k - so that would mean, I need a week after your weeks - which is mid april, when I'm on holiday 10:32 < thegcat> so beginning of may? 10:33 < edavis10> is aaj dependant on anything? 10:33 < schmidtwisser> not sure, if the dependency between 2.3.11 and bundler is that strong - I will prepare stuff, before 2.3.11 is ready 10:33 < meineerde> edavis10: maybe on 2.3.11. Don't know if it targets anything specific... 10:34 < edavis10> schmidtwisser: I'm assuming the worst case. When it comes to dependencies, something always comes up. 10:34 < edavis10> meineerde: ok, how long to get aaj ready? (guess) 10:35 < meineerde> edavis10: I have no idea. I will talk to tim, and tell you asap. But once he finds time, not THAT long... 10:35 < meineerde> (sorry) 10:36 < edavis10> meineerde: it's partially the "finding time" too. It only takes me several hours to review Redmine patches but those are spread out across 2-3 weeks :) 10:36 < Khalsa> is there anything that would help with the actual work? 10:36 < Khalsa> (that I could do) 10:36 < edavis10> lets assume aaj can be done in 3-4 weeks while I'm working on the Redmine patches. I'll need to review it once it's ready which is probably 1 week 10:36 < edavis10> so my critical path is 4-5 weeks 10:37 < edavis10> + bundler which might be done early 10:37 < thegcat> Khalsa: demo server? :-> 10:37 < edavis10> Khalsa: docs for bundler once it's ready (new install/upgrade) 10:37 < edavis10> mabye 2-3 weeks to let the code settle and test before release? 10:38 < edavis10> 6-8 weeks as a guess 10:38 < edavis10> meineerde: end of May looks like it might work 10:38 < meineerde> edavis10: think so, just before whitsun :) 10:40 < edavis10> I propose we shoot for end of May but still keep the August date as the release date. I'd rather release early (in May or June) than miss a release date (May). 10:41 < meineerde> edavis10: okay 10:41 < edavis10> I need to wrap up now 10:41 < edavis10> any other thoughts? 10:41 < thegcat> thank you :-) 10:42 < meineerde> okay. I think we are through. Thank you all. 10:43 < edavis10> Okay. Thanks everyone for coming. 10:43 < edavis10> I'll be posting a summary and the raw notes to the Wiki page in a few minutes 10:43 < edavis10> Any other discussions can happen on the Forums or Issues 10:43 < Khalsa> copy that 10:43 < Khalsa> good meeting 10:43 < Khalsa> congrats on a succesfull dev-stuff 10:43 < edavis10> I'll update the issues and versions in a few minutes too. 10:44 < edavis10> time to focus on getting 1.3 ready to go!