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)

 
1
Logged by edavis10. US/Pacific time (GMT -8)
2
3
09:05 < edavis10> Lets get started then.
4
09:05 < edavis10> Welcome to the first ChiliProject Development Meeting
5
09:05 < meineerde> \o/
6
09:06 < thegcat> /o\
7
09:06 < edavis10> Thanks for coming.
8
09:06 < thegcat> oh wait, no, wrong direction ^_^"
9
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
10
                  meeting.
11
09:06 < thegcat> for the record: the wiki page is wiki:Development_Meeting_0
12
09:06 < pepperbot> thegcat: wiki:Development_Meeting_0 is https://www.chiliproject.org/projects/chiliproject/wiki/Development_Meeting_0 "ChiliProject - Development
13
                   Meeting 0 - ChiliProject"
14
09:06 < edavis10> thegcat: thanks
15
09:07 < edavis10> The main topic today is "What are our goals for the 2.0 release"
16
09:07 < edavis10> I'll start with a bit of background.
17
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
18
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
19
09:08 < rchady> edavis10, you still looking for client work?
20
09:09 < edavis10> rchady: can we chat after the meeting?
21
09:09 < edavis10> The version page for 2.0.0 is at https://www.chiliproject.org/projects/chiliproject/versions/5 (for reference)
22
09:09 < rchady> oops, yes
23
09:10 < jschoolcraft> does 2.3.latest include bundler?
24
09:10 -!- dommeee [~Dominic@p5DDBA251.dip.t-dialin.net] has joined #chiliproject
25
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
26
                  making 2.0 a library-upgrade only release.
27
09:11 < thegcat> jschoolcraft: iirc rails-2.3.latest works with bundler
28
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
29
                  date in summer.?
30
09:12 < jschoolcraft> thegcat: it does, I mean, is CP going to use bundler
31
09:12 < edavis10> jschoolcraft: I don't think it's included but 2.3.latest can be made to work with it
32
09:12 < edavis10> jschoolcraft: that's something we were thinking about discussing too
33
09:12 < thegcat> jschoolcraft: that's one of the points of the current meeting :-)
34
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
35
09:13 < jschoolcraft> very well :)
36
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
37
                   code usable
38
09:13 < RLa> what's the current main case to still use this old rails?
39
09:13 < thegcat> edavis10: I vote for an earlier "library upgrade only" release
40
09:13 < meineerde> also, the reloader is broken in 2.3.x (and especially in 2.3.5
41
09:13 < thegcat> rails 2.3.5 is a pain, we could get bundler in, and so on
42
09:14 < edavis10> RLa: plugins and third party code. Thought with our 1.1.0 the i18n problems should be going away a bit.
43
09:14 < thegcat> RLa: I think backwards compat
44
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
45
09:15 < RLa> thegcat, you think plugins will be updated during the time when we get to 2.0 release?
46
09:15 -!- evtuhovich [~brun@94.198.48.35] has quit [Quit: Leaving.]
47
09:15 < thegcat> RLa: plugins should need only minor adjustments if any to work with 2.3.latest instead of 2.3.5
48
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.
49
09:16 < meineerde> then, in August we could release a 3.0 (or 2.1, depending on the featureset)
50
09:16 < edavis10> meineerde: what would that do to the release schedule? Make August 3.0? Bump 3.0 to 6.months.from.release?
51
09:16 < RLa> are there known issues with 2.3.11 without considering plugins
52
09:17 < RLa> and libraries
53
09:17 < meineerde> RLa: I'm not aware of any.
54
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
55
                  should go away (though you never really know)
56
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
57
                 features/workarounds would have problems
58
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
59
09:19 < happynoff> and, redmine trunk is currently on 2.3.latest… so there is probably no reason to worry about it...
60
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
61
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?
62
09:19 < RLa> but cp trunk is still 2.3.5?
63
09:20 < edavis10> RLa: yes, we are still 2.3.5
64
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.
65
09:21 < jschoolcraft> all the security fixes been back ported to 2.3.5?
66
09:21 < jschoolcraft> haven't there been several?
67
09:21 < RLa> maybe there should be 2.3.latest code out before, that might lead to updated plugins
68
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
69
                   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.
70
09:21 < happynoff> Maybe we could just make a vote
71
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.
72
09:22 < jschoolcraft> :)
73
09:22 < RLa> so final 1.3 will be last 2.3.5 version?
74
09:22 < edavis10> meineerde: then what about after that?
75
09:22 < meineerde> RLa: yes.
76
09:23 < meineerde> edavis10: after that, we "return" to our 6 month schedule for major releases
77
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.
78
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)?
79
09:24 < edavis10> ferggo: I think so too. plus we need to wait for Rails 3.1, which isn't out yet
80
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 :)
81
09:24 < jschoolcraft> and no ship date for 3.1 yet either, right?
82
09:24 < edavis10> jschoolcraft: "When it's done" ;)
83
09:25 < happynoff> Do we all agree on that schedule ?
84
09:25 < ferggo> Does Ruby 1.9 happen along with Rails 3?
85
09:25 < edavis10> Ok, here is what I was thinking. It's similar to meineerde's proposal.
86
09:26 < meineerde> ferggo: I would consider ruby 1.9 in beta support today. The test-suit passes today
87
09:27 < ferggo> meineerde: Oh cool, I wasn't aware of that.
88
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
89
                  "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
90
                  release.
91
09:27 < thegcat> edavis10: aye
92
09:27 < meineerde> edavis10: yay
93
09:27 < Khalsa> edavis10: +1
94
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
95
                  I'd like to add. :)
96
09:28 < ferggo> edavsi10: Agree
97
09:28 < happynoff> ok
98
09:28 < edavis10> ferggo: Ruby 1.9 is close. I'm going to start using it and try to catch some hidden bugs soon.
99
09:29 < meineerde> edavis10: I'm fine that include what's ready. I just want to set the focus on the library upgrade
100
09:29 < thegcat> ferggo: 1.9 will probably happen inbetween 2 and 3
101
09:29 < edavis10> Sounds like we are in agreement that 2.0 will be done when these features are done.  Now what features :)
102
09:29 < edavis10> meineerde: you want to talk about bundler? You guys have the most experience there.
103
09:29 < thegcat> ferggo: we don't need to wait for a major release for 1.9 because it doesn't break previous compat
104
09:29 < rchady> One thing I'd like to see is the completion of those areas of Redmine that always felt unfinished/hacked up
105
09:29 < thegcat> while we're on rubies: what about 1.8.6?
106
09:29 < thegcat> can we kill/drop it?
107
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
108
                production.
109
09:31 < meineerde> edavis10: schmidtwisser created a Gemfile at https://github.com/finnlabs/chiliproject-gemfile
110
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
111
                unfinished/hacked up
112
09:31 < meineerde> edavis10: this runs on ci.chiliproject.org to start the tests.
113
09:32 < edavis10> meineerde: do you think it could be ready in time for 2.0? Say this month or so?
114
09:32 < jschoolcraft> csv gets interesting in 1.9, FasterCSV got absorbed
115
09:32 < schmidtwisser> I guess we could integrate bundler -- after the update to 2.3.11 -- without hassles
116
09:32 < edavis10> jschoolcraft: we are requiring fastercsv already, unless it's 1.9
117
09:32 < schmidtwisser> we just need to update the docs accordingly -- and train our support staff
118
09:33  * jschoolcraft shuts up :)
119
09:33 < meineerde> thegcat: we would drop 1.8.6 support, as rails 2.3.11 doesn't support it itself
120
09:33 < meineerde> and it's broken anyways, so I'm fine with it :)
121
09:34 < thegcat> so 2.3.latest would mean +bundler -1.8.6 -bundled stuff if we manage to throw it out?
122
09:34 < meineerde> the only people who would be concerned by this anyways are RedHad 5.x and SuSE people (iirc)
123
09:34 < thegcat> I guess I'm liking this plan more and more :-P
124
09:34 < edavis10> thegcat: need to discuss the -bundled stuff still
125
09:34 < thegcat> edavis10: thus the conditional ;-)
126
09:35 < edavis10> table 1.8.6 for a second, should we require bundler in 2.0?
127
09:36 < meineerde> edavis10: I vote yes.
128
09:36 < ferggo> edavis10: What is the down-side other than adding a dependency?
129
09:36 < thegcat> seems most of the work for that seems to be available already, so aye
130
09:36 < jschoolcraft> it removes many dependencies by adding 1
131
09:36 < ferggo> jschoolcraft: my point exactly
132
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.
133
09:37 < ferggo> It seems like the Ruby community is converging on 'bundle install
134
09:37 < ferggo> ' being standard
135
09:37 < jschoolcraft> really hrad to beat: gem install bundler && bundle
136
09:37 < edavis10> Lets add bundler for 2.0. meineerde and schmidtwisser: you guys want to handle that part?
137
09:37 < schmidtwisser> sure, i would commit to that
138
09:38 < edavis10> great
139
09:38 < schmidtwisser> though I would probably need support for the docs part
140
09:38 < jschoolcraft> schmidtwisser: I'll pitch in with docs, just ping me
141
09:38 < edavis10> schmidtwisser: yea, by "handle" I mean lead. Everyone should help with each feature.
142
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.
143
09:39 < thegcat> so: "might work, but not guaranteed"?
144
09:40 < meineerde> edavis10: then we could also drop it. it is a pain to still have it.
145
09:40 < edavis10> thegcat: yea
146
09:40 < thegcat> meineerde: are there any workarounds for 1.8.6 currently in CP?
147
09:40 < edavis10> meineerde: except for RedHat and Suse people. It's not a hard depend
148
09:40 -!- gidogeek [~gidogeek@wirelab.isp.be.nl] has quit [Quit: gidogeek]
149
09:41 < edavis10> thegcat: I see two
150
09:41 < edavis10>     Fixed: r4417 breaks MercurialAdapter with ruby 1.8.6 (#5117).
151
09:41 < edavis10>     Fixes a NoMethodError in tests with ruby 1.8.6.
152
09:41 < edavis10> can't get the shas right now
153
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
154
09:41 < thegcat> ok, keep the ones we have, but don't work on new?
155
09:42 < edavis10> thegcat: yea. "It might work but we don't recommend or support it"
156
09:42 < thegcat> works for me
157
09:42 < edavis10> like maglev/rbx/jruby are right now
158
09:42 < schmidtwisser> the officially supported ruby versions would also be relevant for the gem file
159
09:42 < schmidtwisser> there are lots of incompatibilities in the database gems between versions
160
09:43 < schmidtwisser> e.g. latest pg gem dropped 1.8.6; latest mysql gem does not work with 1.8.6-latest
161
09:43 < schmidtwisser> what to do with these?
162
09:43 < jschoolcraft> mysql2 or mysql-latest ?
163
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
164
09:44 < schmidtwisser> edavis10: this would mean: it breaks out of the box
165
09:45 < edavis10> schmidtwisser: what do you propse then?
166
09:45 < schmidtwisser> i just wanted to make sure, that everybody is aware of the issue. i'm happy to drop 1.8.6
167
09:46 < schmidtwisser> IMO it is a security risk to run 1.8.6
168
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.
169
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.
170
09:47 < schmidtwisser> agreed
171
09:48 < edavis10> Related to the Rails upgrade: how often should we be pulling in code from Redmine's trunk?
172
09:48 < ferggo> Even Microsoft doesn't like IE6 anymore. At some point, you just have to move on. ;)
173
09:48 < Khalsa> edavis10: how often is convienient?
174
09:48 < ferggo> edavis10: Is it possible to just pull in any patches that look useful using Github or something?
175
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.
176
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
177
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
178
                  merge.... etc :(
179
09:49 < edavis10> meineerde: you have a source for 2.3.11 + 1.8.6? I couldn't find anything
180
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
181
                  close on some parts.
182
09:51 < edavis10> (50 minute mark)
183
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"
184
09:51 < thegcat> thing
185
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.
186
09:54 < meineerde> edavis10: hmmm, can't find it now either. But at least for 3.0 it's officialy dropped
187
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?
188
09:54 < Khalsa> seconded on the try it and find out :)
189
09:56 < meineerde> edavis10: libraries would be rubytree, net-ldap, awesome_nested_set, redcloth, coderay
190
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
191
09:56 < schmidtwisser> i already successfully removed rubytree in #269 https://github.com/chiliproject/chiliproject/pull/19
192
09:56 < pepperbot> schmidtwisser: #269 is https://www.chiliproject.org/issues/269 "ChiliProject - Feature #269: Refactor lib/redmine/menu_manager.rb to increase
193
                   extensibility - ChiliProject"
194
09:57 < thegcat> acts_as_journalized and the helpers would be my wishes for the time left
195
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.
196
09:58 < edavis10> helpers, release 1.3, and acts_as_journalized is left then
197
09:58 < edavis10> Helpers: "Add helpers :all to ApplicationController?" https://www.chiliproject.org/boards/2/topics/121
198
09:58 < thegcat> so the upside is to not to worry about them, what's the downside?
199
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
200
09:59 < thegcat> possible method name overlap and bigger lookup tables?
201
09:59 < edavis10> -: might cost a bit of memory or performance (probably nothing compared to normal though)
202
09:59 < happynoff> Sorry to interupt guys, but I have to go :( will you write a report on what has been decided here ?
203
09:59 < schmidtwisser> i guess the naming conflicts would be the only real issue here
204
09:59 < edavis10> thegcat: yea, possible name conflict though that should be found when switching
205
10:00 < thegcat> happynoff: I don't think anyone has announced he would write minutes yet
206
10:00 < edavis10> happynoff: I'm taking notes on major items. I think Khalsa has a logger setup too.
207
10:00 < thegcat> but there will be, yes
208
10:00 < thegcat> s/be/be some/
209
10:00 < pepperbot> thegcat meant: "but there will be some, yes"
210
10:00 < happynoff> Ok, thanks :)
211
10:01 < Khalsa> http://chat.chiliproject.org/log/irc.freenode.net/chiliproject/today
212
10:01 < happynoff> ok :)
213
10:01 < happynoff> see you then ;)
214
10:01 < edavis10> schmidtwisser: and actually, naming conflicts should be resolved anyways.
215
10:01 < meineerde> Personally, I like clear dependencies. But I guess it's mor convinient to have helpers :all.
216
10:01 -!- happynoff [~happynoff@gw-puteaux.linagora.com] has left #chiliproject []
217
10:02 < thegcat> I like clear dependencies better too, but I'd be OK to give helper :all a try
218
10:02 < meineerde> would helpers :all also apply to engine helpers?
219
10:02 < edavis10> Sounds like we should try helpers :all then
220
10:03 < edavis10> meineerde: I think so but I'm not totally sure
221
10:03 < schmidtwisser> meineerde: afaik - engine helpers are not automatically included. i think i stumbled a related bug report
222
10:04 < edavis10> schmidtwisser: I'll try it out and see
223
10:04 < schmidtwisser> the safest bed would be to simly test it
224
10:05 < schmidtwisser> edavis10: yep
225
10:05 < meineerde> this should be consistent. So if we include it, it should be included (and if it just by a custom callback)
226
10:05 < meineerde> apart from that, I'd be fine with trying it.
227
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.
228
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.
229
10:07 < thegcat> I should have some time to go through some of it too
230
10:07 < thegcat> esp. the git-smart-http stuff
231
10:08 < edavis10> ok thanks
232
10:08 < edavis10> I think we can wrap up with the acts_as_journalized then
233
10:09 < thegcat> if it's compatible to the current interface, no objections
234
10:09 < edavis10> last I heard, it needs to be rebased onto unstable and then reviewed. Is that correct?
235
10:09 < thegcat> though I haven't had a close look yet, so I can't provide arguments for it either
236
10:10 < meineerde> edavis10: yes. It needs rebasing and is fine then.
237
10:10 < meineerde> what we'd need to decide is if we want to keep the legacy API.
238
10:10 < edavis10> what version should we target too?
239
10:11 < thegcat> regarding the legacy API: keep it in 2.0 but deprecate it, drop it in 3.0?
240
10:11 < thegcat> would that be feasible?
241
10:12 < edavis10> Tim isn't here is he?
242
10:12 < meineerde> phlebas: ?
243
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
244
                  fit.
245
10:13 < thegcat> mostly doesn't mean exclusively
246
10:14 < meineerde> edavis10: I'd like to have it in too. And I hink 3.0 would be too late
247
10:14 < thegcat> and I could also argue that aaj is an upgrade to the current stuff ;-)
248
10:14 < edavis10> thegcat: and I can argue that Rails 3 is an upgrade to Rails 1 but I won't ;)
249
10:15 < edavis10> if someone can rebase and squash aaj onto/into unstable, I can commit to reviewing and testing it.
250
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
251
                 another round
252
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.
253
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
254
10:17 < edavis10> so is anyone here able to commit to rebasing it?
255
10:18 < thegcat> whether to drop it in CP3 or later we can decide in time
256
10:18 < thegcat> +due
257
10:18 < edavis10> thegcat: I think it's wrapper methods. So the new code mimics the old code but uses the newer models/etc
258
10:18 < meineerde> edavis10: https://github.com/finnlabs/acts_as_journalized/blob/master/lib/redmine/acts/journalized/deprecated.rb
259
10:19 < meineerde> edavis10: I talked to phlebasand he volunteered to rebase it. I'm going to schedule it with him.
260
10:19 < edavis10> meineerde: thanks
261
10:19 < edavis10> x2
262
10:19 < meineerde> edavis10: the deprcated API is mostly one file which gets included
263
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.
264
10:20 < edavis10> meineerde: I want to review each commit separately instead of the whole thing because this is such a critical piece.
265
10:21 < meineerde> edavis10: the patches were developed with redmine 0.9 as a target and later rebased the trunk.
266
10:22 -!- dommeee [~Dominic@p5DDBA251.dip.t-dialin.net] has quit [Quit: Leaving.]
267
10:22 -!- jschoolcraft [~jschoolcr@pool-96-255-28-160.washdc.fios.verizon.net] has quit [Remote host closed the connection]
268
10:23 < edavis10> I think that's it then.
269
10:23 < meineerde> okay, do we have a consens to trying to add aaj to 2.0 with the deprecation api included?
270
10:23 < meineerde> (and to drop this in 3.0?)
271
10:24 < edavis10> meineerde: oh yea. Add aaj to 2.0 if it's ready in time. Maybe drop old api later on.
272
10:24 < meineerde> \o/
273
10:24 < meineerde> okay, final question, what is the target date for 2.0 then?
274
10:25 < edavis10> meineerde: I'd say keep it in August until things are done. Then we can set a new date.
275
10:25 < edavis10> meineerde: so it really depends on how fast everyone works
276
10:25 < thegcat> 1.3 + 1 week if we manage until then
277
10:25 < meineerde> edavis10: veto.
278
10:26 < meineerde> edavis10: I'd merely target mid-may. to have a target in sight
279
10:26 < edavis10> what's in scope?
280
10:26 < thegcat> aaj, 2.3.11, bundler
281
10:26 < edavis10> [Rails 2.3.11, Redmine patch pull, bundler, helpers :all, aaj]
282
10:27 < thegcat> ah, helpers
283
10:27 < meineerde> edavis10: that + all libraries we can pull out.
284
10:27 < thegcat> that'd throw the redesign out though
285
10:27 < edavis10> helpers :all are nothing, few minutes of my time
286
10:27 < edavis10> thegcat: yea, moving the redesign out
287
10:27 < schmidtwisser> FYI: helper :all breaks 2 functional tests in the attachments controller - ergo it should be doable
288
10:27 < schmidtwisser> at least on my machine
289
10:27 < meineerde> we can do the redesign in 2.x
290
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
291
10:28 < edavis10> schmidtwisser: thanks
292
10:28 < thegcat> edavis10: we should then either include the current theme or at least maintain it alognside chiliproject in gh.com/chiliproject
293
10:28 < edavis10> meineerde: redesign is still 2-3 weeks out plus a lot of discussion about depends.
294
10:28 < edavis10> notice how when a date is proposed, the scope starts to grow ;)
295
10:29 < meineerde> edavis10: but when we don't propose a date, the scope is infinite.
296
10:29 < meineerde> s/when/if/
297
10:29 < pepperbot> meineerde meant: "edavis10: but if we don't propose a date, the scope is infinite."
298
10:29 < edavis10> meineerde: such is software :)
299
10:29 < thegcat> edavis10: I didn't want to grow the scope, just to point that specific point out
300
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?
301
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
302
10:30 < schmidtwisser> should we try to stick to that or not?
303
10:31 < edavis10> schmidtwisser: I think "remove bundled stuff" is optional at this point
304
10:31 < edavis10> but yea, 2.3.11 before bundler
305
10:31 -!- jhulten [~jhulten@c-24-19-51-222.hsd1.wa.comcast.net] has joined #chiliproject
306
10:31 < edavis10> so bunlder can't start until I"m done, which is in 3-4 weeks out
307
10:31 < schmidtwisser> k - so that would mean, I need a week after your weeks - which is mid april, when I'm on holiday
308
10:32 < thegcat> so beginning of may?
309
10:33 < edavis10> is aaj dependant on anything?
310
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
311
10:33 < meineerde> edavis10: maybe on 2.3.11. Don't know if it targets anything specific...
312
10:34 < edavis10> schmidtwisser: I'm assuming the worst case. When it comes to dependencies, something always comes up.
313
10:34 < edavis10> meineerde: ok, how long to get aaj ready? (guess)
314
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...
315
10:35 < meineerde> (sorry)
316
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 :)
317
10:36 < Khalsa> is there anything that would help with the actual work?
318
10:36 < Khalsa> (that I could do)
319
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
320
10:36 < edavis10> so my critical path is 4-5 weeks
321
10:37 < edavis10> + bundler which might be done early
322
10:37 < thegcat> Khalsa: demo server? :->
323
10:37 < edavis10> Khalsa: docs for bundler once it's ready (new install/upgrade)
324
10:37 < edavis10> mabye 2-3 weeks to let the code settle and test before release?
325
10:38 < edavis10> 6-8 weeks as a guess
326
10:38 < edavis10> meineerde: end of May looks like it might work
327
10:38 < meineerde> edavis10: think so, just before whitsun :)
328
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
329
                  date (May).
330
10:41 < meineerde> edavis10: okay
331
10:41 < edavis10> I need to wrap up now
332
10:41 < edavis10> any other thoughts?
333
10:41 < thegcat> thank you :-)
334
10:42 < meineerde> okay. I think we are through. Thank you all.
335
10:43 < edavis10> Okay. Thanks everyone for coming.
336
10:43 < edavis10> I'll be posting a summary and the raw notes to the Wiki page in a few minutes
337
10:43 < edavis10> Any other discussions can happen on the Forums or Issues
338
10:43 < Khalsa> copy that
339
10:43 < Khalsa> good meeting
340
10:43 < Khalsa> congrats on a succesfull dev-stuff
341
10:43 < edavis10> I'll update the issues and versions in a few minutes too.
342
10:44 < edavis10> time to focus on getting 1.3 ready to go!
343