ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
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
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
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 [~firstname.lastname@example.org] 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
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
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
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 [~email@example.com] 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 [~firstname.lastname@example.org] 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
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
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 [~email@example.com] 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 [~firstname.lastname@example.org] 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
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!