18:05:28 #startmeeting 18:05:28 Let the Jenkins meeting commence! 18:05:35 abayer: Jealous 18:05:51 no joy bap2000 .. new descriptor http://pastebin.com/X9Zm00y5 .... setShowJobConfig() is never invoked, ... neither is configure() 18:05:54 (But we probably won't notice the difference from usual. ;) 18:06:08 I once again failed to advertise this in advance. 18:06:24 =P 18:06:25 I wonder if Google calendar or something else can send in a reminder for me 18:06:27 kohsuke: trademark? =) 18:06:36 Yes sir, no sir. 18:06:45 heheheh 18:06:58 I did mention it to Sacha, but I promised to write him an e-mail and CC you and I haven't done that 18:07:01 I really do it now. 18:07:22 #action Kohsuke to really really get the trademark registration going 18:07:29 the meetings should be entered in the official Event Calendar! 18:07:37 Did you get sent a nexus pro key for dealing with Maven Central? 18:07:52 #info I believe I have the Nexus pro key in my inbox 18:08:01 #info still looking for a volunteer to take the work to the completion 18:08:16 Are you volunteering? 18:08:20 olamy and aheritier expressed interest as well. =) 18:08:32 Great 18:09:14 I'll CC the key to them and see if either of them could take it up 18:09:34 Fantastic! Getting core into Maven Central will be a very good thing. 18:09:57 Yes, it'd be good to get that back. 18:10:20 #action Kohsuke to write to olamy and aheritier to see if either one can volunteer for restoring Maven central sync 18:10:56 Do we want to go through the topics in the order? 18:11:17 abayer: want to talk about the commit message formatting? 18:11:36 Mind if I defer that 'til next time? I'm really not all here right now. =) 18:11:44 Works for me. 18:12:00 And kutzi isn't here 18:12:45 Sounds like it's going to be a short meeting... :) 18:12:54 =) 18:12:58 My apologies for failing to advertise this in time 18:13:14 I'm here 18:13:26 what about LTS? Any comment to my proposal? 18:13:54 vjuranek: I've been meaning to get to it 18:14:15 But I was swamped with preparations for a conference 18:14:45 ok, I'll help for the rsync to central 18:14:50 hooray! =) 18:15:06 thank you, aheritier 18:17:05 #info the LTS proposal from vjuranek is at http://jenkins.361315.n4.nabble.com/RFC-LTS-outlines-and-rules-td3605302.html 18:18:19 Shall we spend some time talking about it? 18:18:40 I see that some points are related to the ability to manage versions in Jira (ping rtyler) 18:19:34 Otherwise I think these are good practices but not all of them we'll be easy to automate/control 18:19:34 Historically it's been hard to commit to the target release for a given issue. 18:20:04 I agree 18:20:23 Instead it was more of a train model. 18:20:32 agree that it could be difficult... the proposal it rather "nice to have":-) 18:20:45 And in 1.409.1, the fixes to it mainly came from the fixes we already had in the trunk. 18:20:46 it's easy to say on which version it will be solved when it is committed, but to say it before ... 18:21:16 For LTS it will always a set of fixes already in master versions 18:23:26 But aside from some of "nice to have" being hard to do, it all makes sense. 18:23:32 at least it would be nice to have some rules which fixes should be backpoted... not to backport randomly some fixes 18:23:58 As I understand, the LTS should only get major/critical fixes, so does it need a 1 month minor release schedule? 18:24:39 Note that I believe JIRA marks all the issues as major by default. 18:25:10 bap2000: to me, the idea is that we need some soak time before releasing it. 18:25:31 So I was originally thinking about the train model. 18:25:49 yes by default they are major and I don't think that many people change the level 18:26:12 I always thought that default was weird. Can it be changed? 18:26:13 But I think the current thinking seems to be more like "release N days after fixes are backported" 18:26:16 yes, in JIRA default is "major"...and therefore there are a lot of major issues 18:27:12 So LTS isn't a train model, but more like "after N days of inactivity and no regression report" 18:27:14 I think that core developers can assess and update the severity of issues 18:27:58 #idea shall we use blocker for that? If some of us think the bug is important enough, push it up to the blocker status? 18:28:15 And similarly, downgrade from blocker if needed. 18:28:27 +1 18:28:30 +1 18:28:34 IIUC, the point of vjuranek is to use some automated tracking mechanism for changes we want to back port. 18:28:52 I think it makes sense, and I think this is simple enough to get started. 18:28:59 if we had labels in jira, which i think we wanted for other reasons, we could just tag them as LTS 18:29:00 kohsuke: well, I put some times as you discuss it on the last meeting, but in fact I like idea to put it first into release and "battle-tested" it 18:29:39 Right, I think we should still stick to the backporting model. 18:29:55 Agreed. 18:30:13 I understand your proposal to use JIRA severity to collectively remember which ones we wanted to backport. 18:30:34 precisely because there's going to be a delay till the fix gets battle-tested. 18:31:09 jieryn: label could work, too, but I think with severity we can expect angry users to help us triage. 18:31:26 labels are harder and only usable for those of us who know the convention. 18:31:41 kohsuke: yes, that's the simplest scenario, but can be more comlicated - e.g. check JIRA for blockers and major issues && git log for fixes which are already in the release 18:31:57 ok, that's a good point 18:31:59 +1 sev 18:32:10 vjuranek: Yes, we can and should eventually automate those. 18:32:15 will there be a separate changelog for the LTS releases? 18:32:33 ... like list up fixes to blocker tickets in the master branch that's not in the stable branch. 18:32:42 Those are back-porting candidates. Completely scriptable. 18:33:02 I think I like that. 18:33:49 #idea I think vjuranek should capture his write up with this and put it to Wiki 18:33:55 closed blocker tickets in the master and not in stable. 18:34:06 Yes 18:34:09 kohsuke: ok 18:34:35 I was supposed to do a separate scripted daemon to update the ticket with the version that the fix is released in. 18:34:42 I think there've been a couple of bug fixes that took a couple of commits, which happened to spread across weekly releases. 18:34:57 So we just need to make sure a fix is in its final form before backporting. 18:35:04 I think that can work both for master and stable, so people can see what releases the fix is in. 18:35:38 hare_brain: good point. I think so far we aren't thinking about automating backporting, so it should be easy to do. 18:36:04 (although come to think of it, automated backporting where we can would be kind of nice...) 18:36:22 but one step at a time. 18:36:30 Hmm. I think I need to find some time to draw a diagram to illustrate some cases for myself. I think better in pictures. I'll share those if I can find time to create them. 18:36:40 thanks 18:37:16 OK, anything else on this topic for now? 18:37:42 I guess not. 18:37:55 And before we adjourn, ... 18:38:07 #info I'm chasing two possibilities for companies to host office hours 18:38:12 Hopefully one of them will work out 18:38:26 Will let this forum know if it works out. 18:38:34 cool 18:38:43 And next meeting time? two weeks from now? 18:39:11 That's July 6? 18:39:13 ok for me 18:39:17 Yes 18:39:25 +1 18:39:35 I'll be missing it due to being at a Jenkins meetup in London. But that's ok. =) 18:39:44 not sure if I'll be able to attend, but we can discuss LTS on dev list 18:40:14 OK. So 2 weeks from now same time. 18:40:35 #agreed the next meeting is 2 weeks from now, same time. 18:40:46 Anything else? 18:41:06 If not, as always, thank you very much for coming 18:41:12 thx 18:41:16 nice 18:41:19 And oh, we need to get CLAs started... 18:41:24 #endmeeting