Hi, John,

Thank you for your perspective. There are a few things in here that I
wanted to respond, as the creator of Jenkins.

First, I totally understand the frustration you and Thomas, the original
poster have. This feeling of fear of upgrade and breakage it might create
is something we hear from many people. Your Jenkins is mission critical,
and when an upgrade breaks Jenkins admins like you and Thomas would be
under a lot of pressure to resolve it quickly. One breakage is one too
many. Believe it or not, a lot of contributors deeply care about not making
that happen.

So the part of your message that tries to call them out is appreciated, and
so is illustration of the pain it’s causing and why that’s important to
you. Please keep those coming. However, an insult like “it’s a bunch of
amateurs driving the bus” shouldn’t be a part of that message and it
doesn't belong in this community. For one, at a practical level, it doesn’t
help you move your cause forward, and if anything it distracts away from
your core message. But perhaps more importantly to me, it also goes against
the philosophy and the ethos of this project. This open-source community
critically depends on volunteer contributors, and it is very important for
me that this project be a welcoming, vibrant, and open community. Without
everyone’s continued participation, and influx of new people, we simply
won’t be able to solve the kind of challenges you are raising. This is so
important to us that we even created code of conduct

I saw that you put the “rant” marker to block the segment of your message
that contained that phase, so I think you just slipped a bit too far in
your frustration, in a moment of heat. And that happens to all of us.

Now, I mentioned that a lot of contributors actually deeply care about not
breaking people’s installations. I wanted to shed some light into what we
are actually doing there.

Changes to the core gets a great deal of scrutiny to explore the backward
compatibility impact. Look at this one PR
<https://github.com/jenkinsci/jenkins/pull/3380> that started yesterday and
you’ll see discussion about fallback, backward compatibility, etc.
Here’s another
one <https://github.com/jenkinsci/jenkins/pull/2831> and I’ll throw in one
more <https://github.com/jenkinsci/jenkins/pull/2759>. This is the norm and
not the exception.

>From time to time, we have no choice but to break backward compatibility.
Many of those are security related, because those tend to be the kind of
bugs that require a fix at the design level. But we do this very cautiously
knowing the impact it can cause. JEP-200 is the most recent one, so let me
explain how we approached this. First, we worked on a design document
<https://github.com/jenkinsci/jep/tree/master/jep/200>, convincing
ourselves collectively that this must be done and this is the best way to
do it. Each code change was reviewed carefully
There was a wiki page
used to track changes in plugins and to collaborate with plugin
maintainers. Announcements are made
<https://jenkins.io/blog/2018/01/13/jep-200/> to users & contributors
calling out what this means and what steps to take, and yet another one
<https://jenkins.io/blog/2018/03/15/jep-200-lts/> as the change landed to
LTS. Slides
<https://speakerdeck.com/player/f2b7e049ec46424b98ec4f0b58fd33bf#> and
videos <https://youtu.be/Vfnc9t1RuYA> are created. This has been a
<https://twitter.com/jenkinsci/status/973328720718045185> recurring
<https://twitter.com/jenkinsci/status/974352667890855936> topic
<https://twitter.com/jenkinsci/status/952297245910724608> on our official
twitter account. Oleg and Jesse led a heroic effort to contain the impact
as much as possible.

And we are also not stopping there. The contributors of the project agrees
that this requires a bigger measure. We want to move away from the need of
assembling plugins and we want to offer something that just works and will
keep working. Take a look at the goal and the mission of Jenkins Essentials
<https://github.com/jenkinsci/jep/tree/master/jep/300>. One of the key
motivations of this ongoing effort is to speak directly to the pain you
raised. I invite you and others to join in those conversations in a
constructive way.

Hope that helps,
On Mon, Apr 2, 2018 at 7:14 AM John Mellor <john.mel...@esentire.com> wrote:

> On Fri, 2018-03-30 at 11:01 -0700, Thomas Dunlap wrote:
> I have inherited an AccuRev Jankins/Hudson CI.  Jenkins version 1.472.
> The previous developer stopped programming in 2012.  I am trying to
> determine the best way to upgrade the software. Since the development is
> old I thought it would be best to see if I can get the 2 applications to
> talk.
> I have updated the licensing for Accurev and can access the CI development
> platform through the AccurRev WebGUI.  So half the problem is functioning.
> We are operating in the Windows OS environment.  I tried to execute
> Jenkins with  no luck.
> I checked the Hudson services and the Event Viewer and have determined
> that the service will not start. From the Services.cpl I start the Hudson
> services and it immediately crashes. Whether run as a location system
> account or an admin account.
> Can it be fixed by replacing the Hudson WAR file with the same version WAR
> file.
> Any help would be appreciated.
> I sympathize with you. I have one Jenkins instance in the same scenario,
> stuck back at Jenkins 1.656 release. I cannot move it forward without
> breaking 300+ mission-critical jobs.
> <rant mode=on/>
> One of the most serious problems with Jenkins today is that API breakage
> is routine, making it very difficult to even do minor upgrades without
> breaking your builds. The root cause appears to be the team not checking
> that a change works against all 2000+ plugins. Test cases are usually
> inadequate or nonexistant, which does not help. Virtually every upgrade
> breaks something unexpectedly. Backward compatibility seems to be a new
> concept for some reason. E.g. the decision to change a blacklist into a
> whitelist without fixing the 2000+ dependent plugins is clearly
> irresponsible. Or git or gerrit or github breakage because someone does not
> understand it. Or the repeated security "cleanups" that break selected
> builds without fixup changes. IMHO, its a bunch of amateurs driving the bus.
> Another part of the problem is probably the language that Jenkins is
> written in.   Bugs per kloc is essentially fixed, independent of the
> language, so it is clear that Java is not the correct choice, resulting in
> far too much code to get the job done correctly.
> <rant mode=off/>
> Realistically, in order to move up to current, you are going to have to
> revisit every one of your workflows and redesign them as either the
> underlying assumptions have been broken, or the API no longer works the
> same way. Many will port forward easily, while others will need a complete
> redesign. Keeping on top of updates is a full-time dedicated job here for
> one person, which tells youjust how bad the issue is. If there was a
> better-managed orchestration engine, we would have moved there a long time
> ago in order to fix the complacency about the routine breakages.
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/1522678461.3049.113.camel%40esentire.com
> <https://groups.google.com/d/msgid/jenkinsci-users/1522678461.3049.113.camel%40esentire.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
Kohsuke Kawaguchi

You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to