18:04:32 #startmeeting 18:04:32 Let the Jenkins meeting commence! 18:04:39 kohsuke: I agree 18:04:41 #chair abayer rtyler hare_brain 18:04:41 Current chairs: abayer hare_brain kohsuke rtyler 18:05:13 #info I apologize for the lack of preparation for this. I didn't even have the agenda page up for this until today. 18:05:24 heh 18:05:31 #topic foundation update 18:06:14 I'd like abayer, hare_brain, and myself to follow up with the action, namely to hash out ASF details once and for all. 18:06:28 weren't you all going to have a literal sit-down meeting? 18:06:50 Yes, haven't done so yet, and we should do it soon, since SPI clock is ticking. 18:06:56 indeed 18:07:12 For what it's worth, I tend to agree with the sentiment I read from last meeting - SPI for now, consider ASF in the future when they've got all the infrastructural issues we'd need resolved. 18:07:17 Namely, git/github questions. 18:07:24 A part of it is also about me and abayer writing down the notes from our previous meeting with Doug. 18:07:52 And I'm saying this as a strong advocate of ASF as the right long-term home. 18:08:52 * rtyler nods 18:08:53 OK. Hearing that from abayer pretty much decides what we should do, in my mind. 18:08:56 haha 18:09:39 And I suppose there's no chance hare_brain can join us tomorrow evening in San Francisco? 18:09:57 I haven't heard from him recently on the subject 18:10:07 Sorry, not tomorrow. 18:10:22 I'm not keen on SFC for some political/philosophical reasons, but SPI seems to do its job nice and apolitically. Getting a legal umbrella is the most important thing for us in re: a foundation, ASF isn't ready for our infra reqs yet, and SPI is right there. And there's no lock-in at SPI so far as I can tell. 18:10:46 Right. 18:11:19 OK, in that case, any reason we shouldn't make the binding decision right now right here? 18:11:32 I think I said this at the last meeting, but we should pick a foundation with the intent of staying there. If we're going into SPI with the intent that it's merely a "placeholder", how is that going to look? 18:11:43 don't all board members need to physically insert their Jenkins Key into the reactor core? 18:12:20 hare_brain: I think it looks alright, actually. We need a legal umbrella, we're not 100% sure what our long-term home would be, but we need that umbrella now. SPI's willing to provide that. Why not take it? 18:13:07 I just don't think it's in the project's best interest for us to wait another 4-6 months to get a legal home, interim or otherwise. 18:13:30 (speaking of - any trademark update, kohsuke?) 18:13:45 i'm guessing the jdk6u13 issue may have something to do with the fact that there was already a separate install of jdk6u13 on the machine at ProgramFiles? 18:13:46 No, sorry. I feel bad, but no. 18:13:51 I agree with that. But how does it help to project if we move to Apache in 4-6 months? 18:14:12 "help the project" 18:14:38 In other words, if SPI is good enough, why wouldn't we stay there forever? 18:14:44 hare_brain: Well, it's not like we definitely would move. I just want to be sure we don't choose something now based on short-term requirements that blocks us from future moves if we so choose. 18:15:09 hare_brain: I think what will happen is that we'll stay at SPI anyways, since we won't feel like moving in the future :P 18:15:27 rtyler: heh. 18:15:28 I think it is very possible that we'll stay with SPI forever. 18:15:43 * stephenc wonders has he actually arrived for a board meeting 18:15:52 stephenc: you may have! 18:15:59 I mean, if things really work out well, we might be swamped by other things and urge to move might not cross the threshold. 18:16:00 wooot! 18:16:08 Think about our move to GitHub. 18:16:31 I'm just saying that I don't oppose the SPI option, even though I personally think ASF is a better long-term option, because SPI's the one we actually have available now, and going with SPI now doesn't mean we *can't* go to ASF in the future. 18:16:54 I think ASF right now is not a good fit for our dev model 18:17:11 And I'm with abayer that we really want some legal umbrella and other normalizations. 18:17:17 ... sooner than later 18:17:19 +1 18:17:20 +1000 18:17:32 you don't get that many votes! 18:17:39 * rtyler subtracts 2000 from stephenc's register 18:17:56 * stephenc claims bonus votes for actually getting to a meeting 18:18:28 I am +1 for moving to SPI now. I am 0 for waiting until ASF is ready for us. I am -1 for moving to SPI now and then moving again to ASF in the future. 18:19:12 well what is needed for ASF to be ready for us 18:19:24 as I see it most of the block is git 18:19:27 see the last meeting notes 18:19:47 yeah but for me the killer is svn being canonical 18:20:20 hare_brain: I'm the most pro-ASF voice here currently, and even I'm not saying SPI is only an interim home - I just don't want to close doors in the future. Inertia on its own will mean that if we go with SPI now, anything else would have to be really worth it to move again. 18:20:39 OK, that's what I wanted to hear from you. :) 18:21:06 =) 18:21:07 Yes, kind of hard to commit to our future actions when they depend on things unknown to us yet 18:21:28 do we have a unanimous vote to accept the SPI invitation? 18:21:52 I'm +1 on accepting. 18:21:54 +1 from me 18:22:14 +1 from me 18:22:25 And I'll reiterate my +1 18:22:38 stephenc: I meant from the board ;) 18:22:56 #info The board has unanimously agreed to accept the invitation to join the SPI 18:22:59 next? 18:23:07 :) 18:23:13 I can do some quick updates on LTS release 18:23:16 #topic Trademark 18:23:22 DERP 18:23:23 Just to quickly touch on this again. =) 18:23:33 I don't think kutzi is here today to talk about test harness. 18:23:35 Is there anything we can do to help getting the ball rolling on it? 18:24:03 I'll really get that going. My apologies. I'll write to Sacha right away. 18:24:27 Thanks. 18:24:35 #topic LTS release update 18:24:35 And I'll CC you, as an added pressure :-) 18:25:21 #info As folks might have noticed, vjuranek from RedHat has been really pushing this ball rolling 18:25:30 * rtyler applauds 18:25:31 He isn't here but wanted to put the credit where it's due. 18:25:38 #save 18:25:42 And a release is now created and bits staged. 18:25:52 Hooray! 18:25:55 It's 1.409.1 right? 18:26:02 I need to mirror it before I make it visible in the top page. 18:26:04 Yes, it's 1.409.1 18:26:10 let's not forget our #info tags gentlemen :) 18:26:10 Excellent 18:26:20 #info LTS is 1.409.1 18:26:31 * rtyler grins 18:26:52 #action I'll do the mirroring today and update the top page. 18:27:23 If people click on the LTS tab on the changelog, will the changelog reflect what went into the LTS release? 18:27:23 People also wanted to me to remove RCs from the top page, so I need to think about where to put them 18:27:48 well, we can shuffle it maybe 18:28:00 #info no changelog generation taken care of yet. For the time being I'll compose it manually until we automate that. 18:28:05 keep that box: Release / Long Term Release 18:28:12 then add a new box just for release candidates? 18:28:37 or "changelog | past releases" to "changelog | past releases | upcoming RC" 18:28:44 that too 18:28:52 is all the update center work in place for LTS? 18:29:23 That's taken care of already, but wouldn't hurt to test sanity 18:29:40 The UC feed for LTS only serves bits compatible with 1.409 18:29:51 is there any plans to allow plugin developers to target LTS specifically? 18:30:07 Yes, they just need to release with parent POM 1.409.1 18:30:07 kohsuke: That's the same UC logic you set up for the 1.395 UC, right? 18:30:27 #info the backend is different from 1.395, actually. 18:30:29 kohsuke: that sounds good to me, something to clearly document for folks 18:30:40 Regarding the Release/RC/LTS box, I think part of the confusion may stem from "Download" being inside the tabbed box. Download should be the div heading, and the tabs for each type of download inside. 18:31:01 That makes sense. 18:31:06 #action rtyler to update the LTS wiki pages with some plugin developer notes 18:32:13 I think we need to boot the train model going for LTS as well. Ideally I'd have liked to cut the RC for 1.409.2 at the same time I release 1.409.1 18:32:24 but today there's no backported changes yet 18:32:46 (afk a few minutes) 18:32:56 kohsuke: you should backport the versionnumber changes 18:33:04 I'll do some this week and create an RC branch. 18:33:21 Really? That implies that we'd be revving the LTS branch frequently. I thought the intent was major bug fixes only. 18:33:22 that would allow you to start numbering the rc's for lts with version numbers like 1.409.2-rc-1 18:33:38 stephenc: it'll have to wait for a week or so minimum. We need more soaking on changes. 18:33:45 oh yeah 18:33:54 i'm just saying it should be on the list 18:33:59 must resist the urge to push LTS often ;) 18:34:06 hare_brain: OK, so let's put the question differently. When should we target 1.409.2? 18:34:23 have we got a bug severity criteria 18:34:26 When there's a bad bug that needs to be fixed? 18:34:28 Exactly. 18:34:41 S1 -> jenkins blows up 18:34:57 More generally, criteria around what bugs to backport. 18:34:59 S2 -> builds fail to build / plugin blows up 18:35:08 S3 -> something less 18:35:12 S4 -> trivial 18:35:26 S1 -> rev LTS asap 18:35:38 S2 -> rev LTS within 1 week of fix 18:35:47 OK, so we'll wait for some important bugs to show up and then cut the RC at that point? 18:35:49 S3 -> out of scope 18:36:03 I can sweep through 1.409-1.415 to see if there has been any. 18:36:11 suspect winstone help still says it's hudson, might be wise to get that into LTS before 1st release 18:36:54 that would be S3 though 18:37:02 or even S4 18:37:05 My assumption was that anything worthy of the major bug style in the changelog would make up the candidate pool for backporting. 18:37:09 as it is cosmetic 18:37:21 yeah but when do we call it major 18:37:24 ... but not yet released 18:37:25 need a criteria 18:37:39 hare_brain: the other temptation is to backport fixes that's low hanging. 18:37:42 Yeah, agree. I liked your tiers. 18:39:23 Isn't the point of LTS to cater to people who want to minimize change? So while the idea of fixing bugs is personally appealing, IMO, the spirit of LTS is to not change it until something major crops up. 18:39:25 hare_brain: how do you backport fixes into your internal branch? Got any criteria? 18:39:48 Based on how vocally people complain? 18:40:15 Pretty much. We generally avoid cherry picking. We've only backported 2 or 3 times in 3 years, that I can remember. 18:41:46 OK, I think that's a workable model. Sounds like for the time being we wait for 1.409.1 users to start complaining about something then. 18:41:57 +1 18:42:06 Less work for you, too. :) 18:42:09 Maybe I can get a thread going in the dev list so that we hear from vjuranek. 18:42:11 Exactly :-) 18:42:33 Anything else we want to talk about? 18:42:48 any status about eclipse.org ? 18:42:55 lolwut 18:42:59 LOL 18:43:09 last meeting there was a lot of work that resulted from hudson->eclipse, and possibility of reunite .. is that fish fully dead now? 18:43:12 shall I give an infra updating? 18:43:23 jieryn: zed's dead baby 18:43:27 good 18:43:29 haha 18:43:44 jieryn: yes, the consensus was that we won't be doing it. 18:43:58 #topic infra update 18:44:01 jieryn: I haven't heard anything from anyone on the Hudson side of things on reunion, so I'm willing to guess they're not actually interested either. 18:44:20 https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Hudson+Reconciliation+Requirements should be updated? 18:44:22 alright, this will be short and sweet 18:44:30 * rtyler bangs his gavel 18:44:40 #action abayer to update https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Hudson+Reconciliation+Requirements 18:45:13 #info both lettuce and cabbage are racked and at least one of them has an OS installed on it 18:45:26 the OSUOSL has either been swamped, or I've not been very effective at whining 18:45:36 You might want to mention what lettuce and cabbage are. =) 18:46:02 #info lettuce and cabbage are a 3U and 2U multi-core machines donated to the project 18:46:39 #action rtyler to publish a post thanking Rackspace for their generous donation of a build machine which we've been relying heavily on 18:46:48 yes, I was going to nag you on that 18:46:56 thanks for taking the action. 18:46:58 #info Backups at Contegix are stalled waiting for a part to arrive 18:47:16 Put the thank you in the dog-food notifications. ;) 18:47:33 backups are in my queue, but lower priority than some of these other tasks since I have manual backups running 18:47:59 #topic minor office hours update 18:48:13 #info the first series of user and dev office hours went exceptionally well 18:48:23 finding time, and speakers it turns out is incredibly difficult 18:48:42 #info Need to investigate Fuze instead of WebEx: http://www.fuzemeeting.com/ 18:49:02 I think I might try to push for a monthly session, since everybody's schedules are very hectic this summer 18:49:28 any other notes on office hours before I pass the mic? 18:49:31 #idea I think it's OK to do it without any fixed agenda, at least the dev session. I'm willing to hang around. 18:49:35 Regarding backups, I was watching the WWDC keynote earlier this week, and my first thought was, Hudson masters should run on OS X Lion. 18:49:50 heh 18:50:02 kohsuke: if you're cool with doing that, that'd be great 18:50:08 the guy that does minecraft does that sometimes 18:50:16 but more in the "look at me code you voyeurs!" 18:50:18 kohsuke, rtyler: I'm up for doing a dev session on the groovy view stuff once I get back from Europe and have written the tutorial/docs stuff on it. =) 18:50:23 hare_brain: it does run. I guess you mean something new that we should be taking advantages of? 18:51:00 kohsuke: Yeah. Auto-file versioning. Good way to version configurations. 18:51:01 Did we have any Cisco folks willing to sponsor WebEx? 18:51:21 kohsuke: we'd still have the recording problem with webex 18:51:23 * kohsuke mumbles zfs having it for years! 18:51:31 LOL 18:51:33 unless we always start with windows machine alwasy 18:51:41 kohsuke: it's only innovation when apple does it, not sun ;) 18:52:20 What do people say? Apple's best product is its marketing team? 18:52:41 * hare_brain apologizes for the tangent 18:52:44 heh 18:53:00 kohsuke: if you're willing to host weekly dev sessions, even without agenda, I think that'd be fantastic 18:53:05 No, generally we try to take advantage of the underlying platform features. We have libraries that enable us to do so. 18:53:16 user sessions I think require some semblence of an agenda to be marketed effectively 18:53:20 So if there's something in Lion that get people excited, we should do it. 18:53:27 ZOMG TANGENT 18:53:27 rtyler: yes, I'm willing. 18:53:39 But let's do biweekly 18:54:18 #action kohsuke to host a dev session bi-weekly 18:54:26 sounds good. 18:54:30 #action rtyler to get a bloody subscribe-able calendar functioning 18:54:39 * rtyler sighs 18:55:00 #topic next meeting time 18:55:03 any other topics other than 'next meeting' 18:55:05 heh 18:55:07 guess not 18:55:14 i have some issues 18:55:21 abayer is out of the country, so that will be tricky 18:55:23 oh boy 18:55:30 I'd like to start a big refactoring of the build 18:55:41 get things more aligned with the maven way 18:55:55 rtyler: meh, I'll be in Paris. I can probably make it. 18:56:05 there are a number of things "done wrong" for use maven heads 18:56:14 stephenc: can we do the "next meeting time" topic then swing around to the builds? 18:56:18 ok 18:56:31 as long as N does not crap all over the later topic 18:56:33 hare_brain: how about you, same time same place, 22nd? 18:56:34 So in 2 weeks? At the same time? 18:56:38 +1 18:56:49 there was some interest from Tokyo folks to try one-off Asian friendly time. 18:56:50 +1 for me. That's 8pm Paris time, yes? 18:57:06 minor req: could @jenkinsci send out a reminder .. 18:57:17 magnayn: heh, yeah, I forgot entirely this week 18:57:36 #agreed next meeting in two weeks same time. 18:57:48 added to the wiki page 18:58:08 #topic refactoring the jenkins build? 18:58:12 stephenc: SPEAK NOW 18:58:15 :) 18:58:20 Gotta drop. 18:58:29 ciao 18:58:30 ok, so there be a lot of "not the maven way"isms in the current build 18:58:37 I have two choices.... 18:58:45 feature branch or incremental 18:59:09 given the s/hudson.model.Hudson/jenkins.model.Jenkins/ going on at the moment 18:59:21 I fear a feature branch too brittle 18:59:38 though i'll be sticking at the pom & plugin level 18:59:55 can you describe some of the changes to be made? 18:59:58 I don't think there's any more s/Hudson/Jenkins/g change. It's all integrated. 19:00:11 Either's fine by me - I just want to see the groovy view stuff make it out in a reasonably stable release before we do any more major changes to core or the build process, so I can go nuts with that. =) 19:00:23 OK, first off I think there is a need to align the hpi plugin with the maven way 19:00:44 that will probably involve me doing a bit of NIH... (pot calling kettle) 19:01:17 then there is stripping out most of the antrun stuff (to be replaced with better mojos in hpi plugin replacement) 19:01:20 Make it work and I don't care what you did. =) 19:01:38 It should also have nice dev mode for working on core 19:01:50 Knowing stephenc, I think a branch is better. 19:01:53 i.e. auto pick-up changes in the core 19:02:11 knowing kk we need reigns to stop you adding features to the build 19:02:22 As long as other folks know that they shouldn't be messing too much with POMs in the trunk, there shouldn't be any merge conflicts, right? 19:02:26 poms are pretty stable, changewise, i think 19:02:32 i don't want a big goalpost move in the plugins 19:02:54 and I need to sync up with kk as to what that whole jenkins-module packaging type is for 19:03:00 i made a large change to the master pom.xml to try and impose some OCD discipline to versions, e.g. 19:03:16 And aheritier did something similar with Maven plugin versions. 19:03:27 then aheritier duplicated almost the entire work in jenkins master :-/ 19:03:27 i'll probably run tidy:pom on everything first 19:03:45 I didn't know :( 19:03:45 so that merging changes will be easier 19:03:48 That way we have freedom to choose when to merge, so if we need a couple more releases to solidify groovy-view, we can do so without having another potential destabilizer going on. 19:04:00 ok so feature-branch 19:04:17 but alert everyone that they need to ping me if they are making changes in the build/plugin* 19:04:28 you can override my work if necessary. I won't be angry 19:04:31 same 19:04:40 if they are just touching versions in dep/depMgmt fine by me 19:04:45 adding deps, fine 19:04:54 adding plugins or reving plugins, ping me 19:05:02 and give me 24h to respond 19:05:11 no response means I'm +1 19:05:14 unless at weekend 19:05:15 #action stephenc to send in an announcement requesting people to kindly refrain from big POM changes to simplify the merge later. 19:05:27 i even invoke versions plugin to check for updates, e.g. http://ci.jenkins-ci.org/job/jenkins_pom/lastBuild/console 19:05:56 I'm sure people will also want to know about the kind of changes you'll be making. 19:05:59 jieryn: I need to rev versions-m-p once I get its tests stabilised 19:06:13 kk: I will probably blog about it when I have a feel 19:06:23 cool :) 19:06:25 thanks 19:06:29 there is a lot of technical debt built up in the build process 19:06:41 I think my changes will make working on jenkins a lot easier 19:06:48 does that count as irony? 19:06:59 wait until you wee 19:07:05 s/wee/see/ 19:07:09 O_o 19:07:31 Every so often I entertain the idea of using Gradle. Is that out of question? 19:07:41 If somebody else wants to 19:07:55 olamy/aheritier/me will want maven 19:08:04 Me too. 19:08:12 My convention over configuration nerdiness is strong. 19:08:18 yeah and you are not biased in favour of maven 19:08:26 OK. I'll keep it as my dream then. 19:08:30 heh 19:08:33 Well, I am biased, but not as a result of being a Maven dev. =) 19:08:33 I'd like to see gradle... 19:08:41 ... but not to force it on anyone else 19:08:50 (IE: academic interest) 19:09:08 do not hesitate to test gradle elsewhere. You'll be happy to come back on maven later :-) 19:09:15 kohsuke: I don't see any reason you couldn't come up with an optional Gradle build for plugins. 19:09:18 two parallel build systems never works 19:09:57 Yeah, like I said, I'll keep it as my dream 19:09:57 it could be possible for plugins to use gradle. The problem is to reuse existing plugins (hpi & co) 19:10:01 the cost is high 19:10:31 Yes, from practical point of view, it's hard for us. 19:10:51 my feeling is that a build done Maven right will have you happy 19:11:00 gradle is grand for the person writing the build 19:11:15 but if you have to take over maintenance of that build it's like an ANT build 19:11:26 you have to read it to figure out what it is doing 19:11:52 what we have with our maven build is a hybrid 19:12:01 which is the worst of all worlds 19:12:15 getting to pure maven build will make life easier 19:12:27 _and_ make it easier to transition away from maven if you want to 19:12:42 * stephenc knows that is a paradox... but that is the truth of a good maven build 19:13:01 Anything else or shall we close the meeting? 19:13:10 i'm good 19:13:13 book'em danno 19:13:26 #endmeeting