18:02:08 <kohsuke> #startmeeting
18:02:08 <robobutler> Let the Jenkins meeting commence!
18:02:34 <kohsuke> #info https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda
18:02:48 <kohsuke> #topic Using stable vs stable-x branch for core LTS.
18:03:13 <kohsuke> jglick: ogondza: ^^
18:03:27 * kohsuke tries to find the commit where this discussion happened
18:03:42 <ogondza> I welcome the idea of getting rid of ours merging
18:03:50 <jglick> my vote: stable-x only, stable as a ref alias if that is possible, else drop it
18:04:04 <kohsuke> #info https://github.com/jenkinsci/jenkins/commit/fb48185875c3c188e206d55ec66d360b20560d4a
18:05:00 <kohsuke> OK, then let's do 'stable-x' only
18:05:13 <ogondza> jglick: If we use ref alias then existing automation will work or blow up?
18:05:24 <ogondza> so it will not be neglected, right?
18:05:26 <jglick> Not sure.
18:05:31 <kohsuke> ogondza: I did an experiment and symbolic ref did not work
18:05:41 <kohsuke> ... as in, one cannot push such a ref to a remote repository
18:05:55 <ogondza> oh, it can not be pushed
18:06:26 <ogondza> kohsuke: should be remove the stable branch, or make it not-buildable?
18:06:27 <kohsuke> My closest approximation is to create a tag named 'stable' that a Jenkins job would meticulously sync to the latest 'stable-x'
18:07:02 <kohsuke> I didn't think about that, but that's another idea
18:07:14 <jglick> A tag would work well enough I think.
18:08:16 <ogondza> works fine for me
18:08:25 <kohsuke> So to summarize, we'll all commit to 'stable-1.x', and we'll turn 'stable' into a tag that gets automatically linked to the latest stable-1.x
18:08:48 <danielbeck> who keeps that running?
18:08:54 <jglick> Sounds good.
18:09:00 <kohsuke> danielbeck:  ci.jenkins-ci.org
18:09:11 <danielbeck> I mean when it inevitably breaks
18:09:28 <danielbeck> who reconfigures it for new stable-x branch
18:09:41 <danielbeck> IOW, does the value outweigh the effort to keep it working?
18:09:43 <jglick> Part of LTS manager’s job.
18:09:58 <kohsuke> I was going to write a script that finds the biggest x in stable-x
18:10:17 <kohsuke> But yes, if it turns out to be too much work, i guess the plan B is to make 'stable' unbuildable by having it point to an empty commit or something
18:10:37 <ogondza> kohsuke: will every commit on stable-x be tagged or just releases?
18:11:12 <jglick> Ideally every commit, so you can do CI on the current stable branch.
18:11:19 <kohsuke> the Jenkins job I was thinking gets triggered on every push and do "x=figureOutX(); git tag -f stable stable-1.x; git push origin stable"
18:11:56 <ogondza> then it should be fairly transparent change
18:11:58 <jglick> git push -f origin :stable
18:12:05 <ogondza> my work just get a bit simpler
18:12:09 <ogondza> +1 from me
18:12:26 <kohsuke> danielbeck: is this OK enough with you?
18:12:33 <danielbeck> sure
18:12:48 <kohsuke> #agreed we'll all commit to 'stable-1.x', and we'll turn 'stable' into a tag that gets automatically linked to the latest stable-1.x
18:13:16 <kohsuke> #agreed a jenkins job will maintain 'stable' as a tag to point to the latest stable-x whenever there's a push
18:13:28 <kohsuke> #agreed if that script turns out to be flaky, we'll just make 'stable' unbuildable
18:13:46 <kohsuke> #topic Update on plugins not getting forked into jenkinsci, or not getting released from there
18:14:19 <danielbeck> I brought this up last time, and we decided to figure out how many plugins are affected
18:14:51 <danielbeck> So I wrote a script that basically downloads everything offered in update center, and checks the bundled pom.xml file
18:15:15 <danielbeck> Out of 1005 plugins, 30 don't bundle a pom.xml, and 138 have some kind of problem
18:15:19 <danielbeck> 12 specify repo in jenkinsci GitHub org that does not exist
18:15:23 <danielbeck> 42 specify repo in GitHub that has no fork to jenkinsci (but there may be the occasional fork of a fork)
18:15:33 <danielbeck> 67 plugins have no tag in GitHub jenkinci org corresponding to offered version
18:15:39 <danielbeck> 8 plugins specify no SCM URL in their POM
18:15:46 <danielbeck> 9 plugins are hosted somewhere else, e.g. beanstalk, bitbucket, or local disk
18:15:55 <kohsuke> local disk :-)
18:15:59 <danielbeck> Independent of SCM, I also checked wiki URL
18:16:04 <danielbeck> 35 plugins specify no wiki URL, leaving the update center to guess or not specify an URL
18:16:08 <danielbeck> 9 plugins specify URLs (linked from update center) that aren't wiki.jenkins-ci.org / wiki.hudson-ci.org
18:16:22 <danielbeck> (the latter obviously being outdated, but we could rewrite in UC)
18:17:20 <danielbeck> so the good news is that the vast majority of plugins are "clean" wrt these checks
18:17:30 <kohsuke> Indeed
18:17:31 <danielbeck> now the question is, how to proceed (if at all)
18:17:53 <kohsuke> I guess we can try some outreach?
18:18:23 <kohsuke> If we know who deployed them, we can reach out to those 42 plugins
18:18:41 <kohsuke> Actually, can we tell who deployed those bits?
18:18:45 <kohsuke> Maybe we can't
18:18:50 <danielbeck> it's in artifactory
18:19:33 <danielbeck> not sure whether it's in the free API though
18:19:39 <kohsuke> ah indeed
18:19:44 <kohsuke> I see "deployer: kohsuke"
18:20:18 <kohsuke> If it's a newer plugin we can tell
18:20:29 <kohsuke> If it's before we switched to artifactory, it'll say "jfrog"
18:20:38 <danielbeck> you specifically mean the 42 unforked ones now?
18:20:56 <kohsuke> Yes
18:21:15 <kohsuke> The same is probably useful with "67 plugins have no tag in GitHub jenkinci org corresponding to offered version"
18:21:23 <kohsuke> presumably their Maven settings do not push tags automatically
18:21:34 <danielbeck> some of these release in their own org/account
18:21:46 <danielbeck> e.g. most recent DotCi
18:22:30 <danielbeck> https://github.com/jenkinsci/DotCi/releases vs https://github.com/groupon/DotCi/releases
18:22:43 <danielbeck> note the jenkinsci fork isn't updated either
18:23:10 <kohsuke> danielbeck: you have this analysis scripted, right?
18:23:27 <kohsuke> Maybe we can just auto pull tags into our repositories?
18:23:31 <danielbeck> kohsuke: Yes
18:24:31 <kohsuke> ... so that we know where to go to if the original author ceases development in his own repo?
18:25:18 <kohsuke> danielbeck: do you have any thoughts on what YOU want to do?
18:26:01 <danielbeck> As a user I'd really like the diff link (changes in latest version) to work in the wiki, which requires tags in jenkinsci to be up to date. I used this long before I started contributing to Jenkins.
18:26:31 <danielbeck> And I see no real reason why  this shouldn't work for all plugins that are made available by Jenkins plugin manager out of the box
18:27:06 <kohsuke> What diff link?
18:27:26 <kohsuke> Perhaps unreleased changes page?
18:27:40 <danielbeck> "In Latest Release" link on all plugin pages on the wiki
18:27:50 <danielbeck> links to e.g. https://github.com/jenkinsci/email-ext-plugin/compare/email-ext-2.38.1...email-ext-2.38.2
18:27:52 <kohsuke> oh wow
18:27:59 <kohsuke> I always learn something new
18:28:51 <danielbeck> helps troubleshooting after an update, or in deciding whether to update at all
18:28:52 <kohsuke> So if we auto fork/pull tags, then that would at least work
18:29:17 <danielbeck> for those that are on github
18:29:23 <kohsuke> And that'd let us do other machine analysis of plugin source tree and their changes between versions
18:29:52 <kohsuke> danielbeck: for those on Git, right? If you are going to just pull tag from repo specified in <scm>, doesn't matter if it's on github or bitbucket so long as it's publicly accessible
18:30:26 <kohsuke> And it looked like that'd cover the majority
18:30:29 <danielbeck> kohsuke: We cannot disable PRs AFAIK so autofork would just be confusing
18:32:14 <kohsuke> OK, so you'd rather want the diff link to point to their respective repos?
18:32:47 <danielbeck> I'd rather want the jenkinsci one to be used
18:33:15 <kohsuke> (FWIW, I don't think enabling PRs is all that confusing, and sadly PRs left pending forever is norm than exception right now)
18:33:40 <danielbeck> do we know the reasons not to use jenkinsci? Other than e.g. some companies wanting more stars in their github org?
18:34:09 <kohsuke> That one was the only real conversation I ever had with someone who's not doing that, I think
18:35:46 <danielbeck> So what now? Contact the users with the request to host and release in jenkinsci, and ask for reasons why not?
18:36:14 <kohsuke> I think that's one thing we can do if it's not too much effort
18:36:26 <kohsuke> I bet many of them would be just as happy to do that
18:37:14 <kohsuke> I thought auto-importing tags would be less tedious as I suspect most of those plugins are just one-off "scratch my itch" plugin that's not seeing active continuing development
18:37:24 <danielbeck> I think filtering these from the default UC config (users need to enable the "universe" switch) is a good idea, but it cannot hurt to find out what the reason is
18:38:03 <kohsuke> OK
18:38:30 <kohsuke> When you say "universe" UC, are you seeing us producing that UC?
18:38:55 <danielbeck> yes. Just hide by default and add an option similar to experimental
18:40:04 <kohsuke> So (1) we'll improve UC generator to be able to check the existence of a tag in the jenkinsci org, (2) use that check when generating the default UC, and (3) create another "universe" update center that doesn't use that check
18:40:22 <kohsuke> And it all basically goes into production at once at some future point in time
18:40:48 <kohsuke> And leading up to that, we'll talk to 109 folks who would miss the default UC
18:40:54 <kohsuke> 109 plugins I mean
18:41:10 <kohsuke> Sorry, 138 plugins
18:41:29 <danielbeck> right. FWIW I think "nonexisting repo" and "repo outside github" are worse
18:41:35 <danielbeck> some of the latter are private
18:41:44 <danielbeck> and we should not support that in the default UC config
18:42:30 <danielbeck> luckily these are very few (2 or so, but still)
18:42:48 <kohsuke> jglick: in relation to this, how easy/hard is it to enable plugin release job on http://jenkins.ci.cloudbees.com/ ?
18:43:17 <jglick> kohsuke: I think it is already enabled, but only available to people who are authenticated, and therein lies the problem.
18:43:18 <kohsuke> that'd let people "do the right thing" more easily without worrying about Maven settings for releases?
18:43:30 <kohsuke> jglick: ah yes, authentication system is separate
18:43:37 <kohsuke> So it's really not pratical to keep those two in sync
18:44:11 <jglick> Maybe we can set something up where by pushing to GitHub you indicate that you want a release?
18:44:28 <jglick> Not sure how exactly.
18:44:35 <KostyaSha> what is the topic?
18:45:01 <jglick> Sort of off topic.
18:45:05 <kohsuke> KostyaSha: see the room subtext
18:45:47 <KostyaSha> external repos and trackers must go to separate 3dparty repo :D
18:46:48 <kohsuke> I just thought making releasing easier would help reduce the # of brokenness
18:47:25 <danielbeck> FWIW I periodically check plugins' required Jenkins versions
18:47:46 <danielbeck> there are some plugins that require very recent cores for no reason and I comment on their repos explaining why that's a bad idea
18:47:57 <danielbeck> most appreciated the advice
18:48:28 <danielbeck> so for most of the 100 it may be as easy as explaining that a jenkinsci fork would be better for users and developers as well
18:48:43 <kohsuke> jglick: along the idea of pushing GitHub to indicate you want a release, maybe you file a ticket and assign it to the bot account?
18:49:16 <jglick> kohsuke: no, does not prove you are the maintainer of sources
18:49:30 <jglick> Want something that involves a push command to Git.
18:49:46 <jglick> For example, push a dummy tag with a magic name to the selected branch.
18:49:47 <kohsuke> danielbeck: OK, so sounds like we need to draw up the plan along the line of 3 bullet items I mentioned earlier
18:50:06 <danielbeck> first reach out, explain preference and ask why not
18:50:09 <kohsuke> we need something like that when we reach out to folks to explain why it's better for users & developers
18:50:51 <danielbeck> then filter UC -- could be as little as requiring github, or as much as requiring tags be present in jenkinsci org fork
18:50:57 <kohsuke> Right, so let me do this again, we need to produce some write-up that talks why we are trying to do this
18:51:12 <kohsuke> jglick: I can check if the reporter has the push access
18:52:13 <kohsuke> danielbeck: do you want to get that writeup started? I can pitch in points but I think you are the main driver of this effort
18:52:23 <jglick> Yeah, just am not fond of filling JIRA with junk tickets. Seems more natural to have the Git push be the actual trigger.
18:52:26 <danielbeck> I can try at least :-)
18:53:12 <danielbeck> some parts are already in the wiki, an example by stephenc IIRC
18:53:52 <jglick> Alternately, a plugin that actually uses OAuth to connect to GitHub and verify that you are supposed to have push permission to the affected repo. But this seems like more work.
18:53:57 <kohsuke> #action danielbeck to start writing a page explaining why we want plugins to be in the jenkinsci org, with the goal of reaching out to plugins who don't do that today
18:54:26 <kohsuke> jglick: oh that's neat
18:54:28 <jglick> (Of course getting away from maven-release-plugin altogether would be lovely.)
18:54:29 <kohsuke> agreed more work
18:54:51 <jglick> (But far more intrusive to established processes.)
18:55:08 <kohsuke> We should probably inform the dev list about this activity
18:55:19 <kohsuke> But I think enough for today
18:55:23 <jglick> Yup.
18:55:38 <kohsuke> I'm sure people will have opinions on this
18:55:43 <danielbeck> right
18:55:44 <ebag> So, I have a rather large php project that I'm currently deploying with Jenkins... I'm currently doing it wrong however, because the "archive artifacts" step takes a *very* long time to complete... what can I look at to try and either make this step faster, or do an alternative process for pushing changes through my pipeline?
18:55:47 <kohsuke> #topic next meeting
18:56:03 <kohsuke> #info Next meeting will be Oct 29th
18:56:14 <kohsuke> In the mean time, see you in JUC San Francisco
18:56:22 <kohsuke> #endmeeting