18:00:56 <kohsuke> #startmeeting
18:00:56 <robobutler> Let the Jenkins meeting commence!
18:01:09 <kohsuke> #chairs abayer rtyler
18:01:15 <kohsuke> #chair abayer rtyler
18:01:15 <robobutler> Current chairs: abayer kohsuke rtyler
18:01:19 <abayer> So we have an agenda! https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda
18:02:19 <abayer> What's the command to change subject?
18:02:25 <kohsuke> hang in there...
18:02:28 <abayer> =)
18:02:31 <kohsuke> #topic Plugin deprecations https://wiki.jenkins-ci.org/display/JENKINS/Proposed+Plugin+Deprecation
18:02:48 <kohsuke> The only command you should remember is pound-info and pound-idea
18:03:06 <abayer> #info Ok, this one's my baby. We've got a bunch of plugins that do more or less the same thing, and that's causing confusion, duplication of effort, etc.
18:03:45 <abayer> #idea I propose we comb the plugin list to find possible duplications and when possible, deprecate older plugins in favor of newer ones providing the same functionality and possibly more.
18:04:08 <kohsuke> what's the migration story for users using them?
18:04:16 <abayer> #info e.g., the ones that prompted this - envfile and setenv have all their behavior incorporated into envinject.
18:04:23 <myusuf3> abayer, it would be nice if there was a place to see all the available plugins
18:04:41 <abayer> In the case of envinject, gbois has already added automatic migration of config info from envfile and setsenv.
18:04:44 <kohsuke> myusuf3: that's your update center
18:04:50 <kohsuke> but I guess we can auto-generate Wiki page for it
18:05:01 <kohsuke> ah, nice
18:05:13 <kohsuke> let me see how that works...
18:05:40 <abayer> My work-in-progress proposal needs to get wrapped up and wiki'd, but the gist is that we'd record deprecated plugins and their replacements in a properties file in the update center generator.
18:05:42 <myusuf3> i am not sure how much effort you guys would like to put behind it
18:06:10 <myusuf3> but it would nice to have a clean changelog for plugins, without the super old comments.
18:06:19 <abayer> Along with an optional groovy migration script, so that we don't need to have the replacement plugins depend on the old ones or have all their config information defined, etc.
18:06:23 <myusuf3> confusing everyone.
18:07:03 <abayer> And then when generating the update center, the deprecated plugins' entries would magically be replaced (with the same key) with the new one, with a flag that it's a deprecation replacement and the optional migration script added.
18:07:32 <kohsuke> #info IIUC the migration implementation in envinject plugin is quite transparent and also backward compatible
18:07:39 <abayer> The UI for upgrades would say "Hey, plugin X is deprecated in favor of plugin Y - check here to migrate".
18:07:49 <abayer> And if there was a migration script, it'd be run.
18:07:50 <kohsuke> It doesn't modify configuration on disk eagerly, so you can upgrade/downgrade
18:08:01 <abayer> Then the old plugin gets disabled, but not removed.
18:08:06 <abayer> Like I said, very rough.
18:08:29 <abayer> I'll get the wiki entry up today. I just wanted to make sure we got this talked about, because we've got bloat problems in the plugin count.
18:08:56 <jieryn> even if we just mark plugins as deprecated, and have that appear somehow in the manage plugins area .... that'd be a good start
18:09:06 <rtyler> #agreed
18:09:16 <kutzi> +1
18:09:18 <abayer> jieryn: I still think there's no reason why we can't do more pretty easily. =)
18:09:21 <kohsuke> I'd like to point out that envinject is better than the git-plugin migration story you are thinking.
18:09:28 <jieryn> i'm all for that :)
18:09:35 <myusuf3> If you give me a way to get at the list for plugin database; I would write something that would help do this real quick in django
18:09:55 <abayer> kohsuke: Oh, it definitely is, but the git plugin situation is hairy since I want to junk the whole old one, including some config options, etc.
18:10:03 <kohsuke> In this case we can simply present envinject as an upgrade to any envfile.
18:10:19 <kohsuke> and likewise downgrade
18:11:03 <kohsuke> I'd personally love to see other deprecation upgrade path offer the same degree of experience.
18:11:04 <abayer> In any case, I'm not talking about this here for the git plugin - more for the cases that already exist.
18:11:19 <kohsuke> And have UX around this
18:11:41 <kohsuke> I guess what I'm saying is I'm not sure if you can treat this and your git-plugin situation in the same bucket
18:12:14 <harpreet> kohsuke: Hi, I have a small question, in multi configuration project (configured with multiple slaves per platform) is it possible to get same changelog with evry build (INFO: I have old hudson yet, so if that feature has been added in the newer releases then, thanks in advance).
18:13:02 <bap2000> kohsuke: with some of my plugins, I decided to create new names, and start again because I had zero confidence of the state of the original configuration, or of the actual behaviou
18:13:05 <harpreet> I am asking this as with the change in the slave the changelog changes accross slaves.
18:13:09 <kohsuke> IOW, wouldn't this call for two different mechanisms?
18:13:29 <rtyler> harpreet: we'll come back around to general support stuff after our project meeting
18:13:29 <kohsuke> harpreet: let's postpone questions until after the meeting
18:13:44 <sjakubowski> when are you guys expecting to finish?
18:13:52 <sjakubowski> the meeting
18:13:56 <rtyler> 45 minutes I would assume
18:13:57 <bap2000> I did not want to completely break someones setup, or start running code on a host that it was not expected to run on
18:13:58 <abayer> kohsuke, bap2000: Yeah. In some cases, it might just make sense to remove the existing plugin from the update center altogether.
18:14:02 <harpreet> sorry, will wait
18:14:10 <sjakubowski> 3pm EST? ok, thanks.
18:14:29 <abayer> #action abayer to write up his proposal for deprecated plugin behavior in the update center on the wiki
18:14:31 <jieryn> probably 3pm EDT
18:14:42 <bap2000> yep, allow an admin to make a concious choice of when and how to upgrade
18:14:46 <jieryn> EDT != EST .. sorry </nitpick>
18:15:11 <abayer> So are we agreed that the principle (by some method getting deprecated/obsolete/replaced plugins out of the update center) is a good one?
18:15:19 <abayer> With the question being implementation?
18:15:26 <bap2000> obviously a seamless automatic upgrade is preferable
18:15:57 <kohsuke> +1 to the upgrade story
18:16:11 <jieryn> maybe some custom MANIFEST entry for deprecated
18:16:28 <abayer> #idea Review deprecation implementation ideas next meeting?
18:16:34 <jieryn> k
18:16:45 <kohsuke> And +1 to marking deprecated plugins (in some loose sense) that signals people to go look another plugin.
18:16:51 <abayer> I just wanted to be sure this was worth pursuing in the first place. =)
18:17:05 <rtyler> seems so :)
18:17:06 <bap2000> abayer: yes
18:17:07 <olamy_> jieryn: agree why not modyfing hpi with adding a flag
18:17:32 <jieryn> that'd be better, no new release / deploy required
18:17:33 <abayer> #agreed Plugin deprecation is good. Implementation ideas are also good. Write 'em on the wiki, review 'em next week.
18:17:34 <kohsuke> I suppose another part of it is to help spread the techniques for plugin devs to preserve/migrate configuration
18:18:16 <kohsuke> We've identified at least two techniques thus far --- one that gbois used, another that we need for abayer
18:18:24 <kutzi> And also how to unit test thta the migration works ;)
18:18:34 <kohsuke> rigth
18:18:49 <kohsuke> that can be tested too already.
18:19:11 <kohsuke> Need to evangelize how
18:19:29 <abayer> Can we move to the next topic? I've got a meeting in not too long =)
18:19:41 <kohsuke> yes
18:19:48 <kohsuke> #topic Jenkins User Conference http://jenkins-ci.org/content/jenkins-user-conference
18:19:50 <bap2000> How do we handle the case where the old and the new are both installed?
18:20:02 <abayer> bap2000: see proposals to come. =)
18:20:09 <bap2000> k
18:20:10 <abayer> So yeah, JUC!
18:20:16 <abayer> October 2nd!
18:20:18 <abayer> Submit talks!
18:20:20 <kohsuke> bap2000: I expect the metadata in plugin to signal Jenkins to reject that
18:20:23 <abayer> Also come!
18:20:43 <kohsuke> #idea If we have a bit of time, I'd love to hear what kind of talks people want to hear
18:21:33 <kohsuke> It helps us reaching out to the right people.
18:21:54 <aheritier> kohsuke: I think they would like to see a lot of "Jenkins in action"
18:22:02 <aheritier> In many contexts
18:22:21 <kohsuke> So actual war stories from users about how they do it, what did/didn't work, etc?
18:22:25 <aheritier> And perhaps few of them could be interested to have hands in the code
18:22:46 <abayer> I love the idea of a cowboyd talk on Ruby plugins. =)
18:22:48 <aheritier> yes
18:23:14 <aheritier> perhaps you may find also someone who can compare Jenkins with others CI
18:23:24 <kohsuke> My assumptoin is that Hackathon won't fit very well with JUC, since it tends to work better with smaller number of people, and it takes a lot of time
18:23:34 <abayer> aheritier: That could get a bit…political. =)
18:23:36 <aheritier> kohsuke: I agree
18:23:58 <kohsuke> Does it make sense to schedule hackathon on another day?
18:24:09 <aheritier> abayer: Why ? because Jenkins is the best one ? I'm sure we can find some wrong things about it :-)
18:24:13 <abayer> heehee
18:24:18 <rtyler> kohsuke: probably, not sure how many folks will be in town for JUC and/or JavaOne
18:24:23 <rtyler> aheritier: I can list a LOT ;)
18:24:38 <rtyler> if you filter out ones that refer to the git plugin, it might be a much smaller list ;)
18:24:49 <aheritier> A User conf need to focus on users, not on contributors/developpers, thus use cases ....
18:24:57 <rtyler> agreed
18:25:11 <kohsuke> +1
18:25:25 <aheritier> and there are a lot of usecases
18:25:25 <rtyler> kohsuke: I think a later in the week hackathon is a good idea, but probably should be tabled until the javaone schedules are a bit clearer
18:25:28 <aheritier> various technos
18:25:34 <aheritier> build, continuous deployment ...
18:25:50 <aheritier> some are managing infra instead of a crontab ….
18:26:49 <kohsuke> All right, I think that was good input
18:26:56 <abayer> I actually have to run in a minute - could we quickly hit the olamy_ as owner on jenkinsci on github question? =)
18:27:15 <kohsuke> #topic olamy_ as owner on jenkinsci on github question
18:27:28 <abayer> #idea olamy_ should be added as an owner.
18:27:29 <abayer> =)
18:27:36 <olamy_> heh
18:27:39 <rtyler> #agreed
18:27:40 <rtyler> also
18:27:43 <rtyler> autocomplete, really
18:27:45 <aheritier> +1
18:27:57 <abayer> I'd like to get a European person with admin, and olamy seems the logical choice.
18:28:08 <kohsuke> Out of curiosity, what is that the current admin bot doesn't do that needs manual work?
18:28:30 <aheritier> reboot Confluence ?
18:28:34 <abayer> This was prompted when olamy_ needed some mail hook added or something, I don't remember the details. =)
18:28:41 <abayer> aheritier: here I'm actually just talking about Github.
18:28:44 <jieryn> +1 olamy
18:28:48 <aheritier> abayer: ok
18:28:52 <rtyler> IMHO not everything should/needs to be in jenkins-admin <_<
18:28:57 <aheritier> About GitHub I don't see
18:29:01 <abayer> I just like the idea of redundancy.
18:29:12 <abayer> Right now, it's just me, mindless, kohsuke.
18:29:13 <olamy_> follow the sun !
18:29:39 <aheritier> All those who are admin here can play with the bot ?
18:29:41 <abayer> It's not a huge deal, obviously, but if there's no opposition, it can't hurt. =)
18:29:47 <kohsuke> For example, bot sets up the email hook so that commit msgs come to the right list.
18:29:56 <abayer> Say, if the bot's down overnight US time or something.
18:29:56 <kohsuke> aheritier: anyone with voice
18:30:12 <kohsuke> so you included
18:30:16 <aheritier> ok thus there are many people with voice ?
18:30:21 <kohsuke> exactly.
18:30:33 <aheritier> in that case what loamy could do more ?
18:30:39 <abayer> Redundancy.
18:30:56 <abayer> Renaming repos, adding someone to core, etc.
18:31:02 <aheritier> abayer: I agree, if there is something he cannot do with the bot
18:31:03 <bap2000> aheritier: admin guthub org
18:31:38 <kohsuke> I'm not opposing it, but I want to make sure that the admin bot is used to do most of the work.
18:31:39 <aheritier> In any case I agree to give him more credentials
18:31:41 <abayer> I don't expect this'll almost ever be an issue,but just in case sort of thing.
18:31:43 <bap2000> olamy: GH org owner +1
18:31:53 <rtyler> let's move on,  I'm hungry :D
18:31:58 <abayer> kohsuke: Oh, agreed wholeheartedly. But for one-off tasks, etc.
18:32:01 <kohsuke> OK
18:32:05 <aheritier> but I'm not sure we have often some important/critical/urgent tasks with github
18:32:08 <abayer> #agreed olamy's an owner....now!
18:32:28 <kohsuke> next topic?
18:32:41 <abayer> Yup. And I'm going AFK for a meeting. =)
18:33:11 <kohsuke> #topic Trademark Registration Status
18:33:28 <kohsuke> #info so the ball started rolling between SPI and us
18:33:48 <kohsuke> It's been in limbo for a while as my e-mail waited moderator approval by their board list
18:34:03 <kohsuke> But I need to get back to that e-mail thread.
18:34:21 <kohsuke> So the cat isn't in the bag yet.
18:34:35 * rtyler isn't sure that's how the expression works
18:34:35 <kohsuke> That's the update from me.
18:35:00 <kohsuke> I keep saying you are my English teacher for a reason!
18:35:10 <rtyler> i'll explain after the meeting :)
18:35:16 <rtyler> anyways, what's up next, LTS?
18:35:23 <kohsuke> #topic Kohsuke wanted to discuss this (JENKINS-9488 - align topbar colors): https://github.com/jenkinsci/jenkins/pull/179
18:35:29 <rtyler> or that one
18:35:45 <kohsuke> #info so there's a pending request to change the color of the top bar of Jenkins UI
18:35:58 <jenkins-admin> JENKINS-9488:align color palette used in Jenkins with jenkins-ci.org and issues.jenkins-ci.org (Open) http://jenkins-ci.org/issue/9488
18:35:59 <aheritier> Funny 9488 : I remember having proposed it a long time ago in the chat.
18:35:59 <kohsuke> from current blue + orange to black + red, the same colors used in wiki and issues
18:36:09 <aheritier> +1 from me
18:36:41 <kohsuke> #info one point I'd like to make is that the current color came from the same palette that's used for all the other icons
18:36:42 <rtyler> I'm definitely on board, but the colors on the wiki are not pure black -_-
18:36:45 <aheritier> As it will be more coherent and it will make us a little bit different
18:37:02 * olamy tested the pull request and like it
18:37:05 <kohsuke> and the same color palette is used for hyperlinks, trend graphs, blue/red/yellow ball, etc.
18:37:16 <kohsuke> So I'm bit mixed about the change
18:37:26 <aheritier> kohsuke: the palette must be documented in the wiki
18:37:33 <rtyler> olamy: can you post a screenshot?'
18:37:38 <aheritier> and I agree we need to be sure to use it everywhere
18:37:56 <olamy> arf I have reverted locally
18:38:03 <jieryn> does this highlight a larger need for an easier to theme/skin jenkins?
18:38:38 <aheritier> I'm also interested in skinning capabilities but it is  a larger subject I think
18:38:38 <rtyler> jieryn: I don't think so, I think this is just a matter of our branding being woefully dated
18:38:46 <rtyler> (theming is a different can of worms)
18:39:14 <kohsuke> or does this mean we should look at changing other colors at the same time? The new palette uses different blue & red
18:39:43 <olamy> ahertiter: some company/organisations like to have their own design
18:40:14 <rtyler> kohsuke: we do have the color pallette up here: https://wiki.jenkins-ci.org/display/JENKINS/Logo
18:40:19 <rtyler> IMHO it's definitely time to start using it
18:40:25 <jieryn> ..this is possibly the first literal bike-shedding in a software project i've ever seen..
18:40:35 <jieryn> we are literally debating colors
18:40:38 <rtyler> woot!
18:40:42 <kohsuke> And this is the one currently in use http://tango.freedesktop.org/Tango_Icon_Theme_Guidelines
18:41:11 <rtyler> aha
18:42:22 <kohsuke> I'm fine either way but I was inclined to keep the current one
18:42:45 <jieryn> i'd prefer to keep the original one unless we're going to wholesale replace the ui for easy theming, via extension or whatever
18:44:02 <kohsuke> #info screenshot: http://postimage.org/image/2u9iq9v0k/
18:44:27 <rtyler> that looks good to me
18:44:42 <aheritier> +1 for me IF everything is updated (links …)
18:44:48 <kutzi> like it, too
18:45:15 <kutzi> should we ask the users as they will be using it?
18:45:16 <rtyler> kohsuke: do you think imod might be open to expanding his commit a bit? :)
18:45:31 <kohsuke> doesn't hurt to ask
18:45:36 <rtyler> kutzi: that's an even scarier bike shedding opportunity
18:45:38 <rtyler> xD
18:45:52 <kohsuke> OK, let's ask him or others to push this effort bit further then
18:46:03 <kohsuke> If enough people care to do it and it happens, then we'll swap
18:46:13 <bap2000> aren't the links the browser default?
18:46:23 <kohsuke> bap2000: actually, no
18:46:46 <bap2000> ok - looks like it to me o_O
18:46:47 <kohsuke> Shall we move on to next topic?
18:46:48 <kutzi> rtyler: you have to explain me later what that phrase means
18:46:55 * rtyler nods
18:47:03 <rtyler> kohsuke: IMHO yep
18:47:05 <kohsuke> #topic: When is it time to release a new LTS release?
18:47:14 <rtyler> where's hare_brain for this one :/
18:47:19 <kohsuke> vjuranek: ping
18:47:30 <kohsuke> Doesn't look like we have the right guys here
18:47:34 <rtyler> damnit
18:47:39 <kutzi> I've put that on the agenda
18:47:42 <bap2000> how long has the fix for the jdk download been in the wild?
18:47:42 <kohsuke> but there are a couple of good remoting changes that are nice candidate
18:47:49 <kohsuke> yes, and that one, too
18:48:03 <rtyler> you're talking backporting or jumping the LTS branch forward?
18:48:15 <kohsuke> I was thinking backporting
18:48:23 * rtyler nods
18:48:34 <kutzi> yes
18:49:10 <kohsuke> Although LTS release was June 8th, so according to our original plan of the record, it's time to start thinking about jumping to the next one
18:49:25 <kohsuke> one is due in 3 months.
18:49:38 <kohsuke> meaning Sep 8th
18:49:47 <vjuranek> kohsuke: pong I;m sorry, I was AFK
18:50:08 <kohsuke> So we are talking about the next patch release of LTS
18:50:28 <kohsuke> so far JDK installer change and remoting changes are identified as candidates
18:51:04 <kohsuke> Do you have any other candidates?
18:51:05 <olamy> I like the change we made with imod
18:51:14 <olamy> for config file provider
18:51:37 <kohsuke> ticket id, any other reference? It doesn't ring a bell for me
18:51:55 <vjuranek> I'll have to look, but probably not other candidate right now on my mind
18:52:00 <olamy> oups no ticket
18:52:18 <kutzi> I would like to have JENKINS-6700
18:52:22 <jenkins-admin> JENKINS-6700:Failure in test class constructor or @Before method is not reported (was: Maven plugin doesn't set build to unstable on SurefireExecutionException) (Resolved) http://jenkins-ci.org/issue/6700
18:52:58 <olamy> kohsuke : a new extension point see https://wiki.jenkins-ci.org/display/JENKINS/Config+File+Provider+Plugin
18:53:03 <kohsuke> #action Kohsuke to run his script to identify tickets that are (1) marked as critical and (2) reported fixed in the trunk
18:53:26 <kutzi> JENKINS-10346 might also be a candidate, but I cannot say if and how often it really shows in practice
18:53:27 <kohsuke> I was thinking the general rule of thumb is that this is bug fix only
18:53:29 <jenkins-admin> JENKINS-10346:Race condition in creating fingerprints for artifacts (Resolved) http://jenkins-ci.org/issue/10346
18:53:47 <kohsuke> ah yes, this is a good one
18:54:36 <kohsuke> vjuranek: would you be interested in backporting fixes? or would you like me to?
18:54:58 <vjuranek> kohsuke: if you are bussy, I can do it
18:55:09 <kohsuke> thanks, if you can take a shot at it, that'd be awesome
18:55:25 <vjuranek> kohsuke: ok, I'll do it
18:55:37 <vjuranek> I guess we talk about 1.409.2, right?
18:55:42 <kohsuke> yes
18:56:06 <kohsuke> when is the goal for a release? 3-4 weeks from now?
18:56:34 <kutzi> 3-4 weeks would be the next LTS branch, already, according to the original plan
18:57:58 <kohsuke> I guess I'm thinking 1.409.2, and then to 1.42x.1, so it won't happen in 3 month cycle, and I think that's OK.
18:57:59 <bap2000> kutzi: right, but surely there's still support (backporting) for an overlap
18:58:09 <vjuranek> originally yes, on the other hand, does it make sense to do the release of 1.409.2 and one or two weeks later new major release?
18:58:41 <kohsuke> I suppose the other option is to skip 1.409.2 and go straight to the next 1.42x.1
18:59:25 <kutzi> or the 3 month period was to ambitious and we shift 1.42x.1
18:59:31 <kohsuke> yeah
18:59:42 <bap2000> .. but then everyone on the stable cycle is forced to immediately upgrade to get the jdk download working, and I'm not sure that's a nice experience for those wanting a more stable platform
18:59:53 <vjuranek> personally I prefer 1.409.2 and pospone 1.42x.1
18:59:59 <bap2000> +1
19:00:00 <jieryn> arent they broken already?
19:00:07 <jieryn> w/r/t jdk auto install
19:00:09 <kohsuke> Yeah, let's do 1.409.2
19:00:32 <kohsuke> Yes, JDK install is already broken
19:00:56 <kutzi> So, there's agood reason to go to 1.42x.1 already, isn't it?
19:01:21 <kohsuke> But that's a fix planned to be backported into 409.2
19:01:28 <kohsuke> So either way users will get it
19:01:35 <kutzi> ah, yeah
19:02:12 <kutzi> okay, fine to have a 1.409.2 first
19:02:24 <kohsuke> #agreed aiming 1.409.2 in 3-4 weeks, and then move to rebumping to 1.42x after that.
19:02:41 <kohsuke> #topic next meeting time
19:03:07 <kohsuke> I'm assuming 8/17 will be office hours and the next project meeting will be 8/24
19:03:36 <kohsuke> and we are back to the usual Wednesday time
19:03:50 <kohsuke> Is that OK?
19:03:55 <olamy> k
19:04:02 <kutzi> ok
19:04:04 <vjuranek> I;m fine with it
19:04:36 <kohsuke> All right. With that, we are done for the day.
19:04:40 <rtyler> /win11
19:04:42 <rtyler> whoops xD
19:04:52 <kohsuke> #endmeeting