ChiliProject - chiliproject-development-meeting-2011-03-18.txt

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.

chiliproject-development-meeting-2011-03-18.txt

Eric Davis, 2011-03-18 05:47 pm

Download (27.6 kB)

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