Renaming Jenkins Essentials to 'Evergreen'

[R. Tyler Croy]

I wanted to send an broader email to the dev list indicating that I will be
changing the name of what we have thus far referred to as "Jenkins Essentials"
to "Evergreen." The latter has been the name of the distribution system since
day one, and as we near completion on "Milestone 1", which will be useable by
actual people, I wanted to fix the name to ensure that what "it" is, is clear
and understandable.


Since the early days, "Essentials" has unfortunately been a bit of a confusing
name for some folks. It tended to be related to the "Suggested Plugins" feature
far more than I had ever wanted. The key aspect of it is _not_ the selection of
plugins, but rather how those plugins get out there to users.


From my perspective, the always-automatically-up-to-date distribution aspect of
what we've built, *that* is the key take-away.


Evergreen captures that promise _far_ better in my opinion.

(with a nice hat-tip towards Green Balls and Blue Ocean's green status
indicator :))


The four pillars remain the same, but the key premise of Evergreen is being
highlighted much more with this change.


From a practical standpoint, I will be submitting updates to the JEPs we have
written thus far, add an update note to old blog posts, and post an blog post
explaining what Jenkins Evergreen (nee Essentials) is and how to use it as of
Milestone 1 (:clap:).




Let me know if you've got any questions, and of course, I look forward to
chatting with many of you about Evergreen at DevOps World - Jenkins World San
Francisco coming up soon :D


Cheers
-R Tyler Croy

[Matt Sicker]

I like the name change. I think I've seen both names lately, and I was confused which was what. Thanks for the clarification!

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/20180814220448.GI17800%40grape.lasagna.io.
For more options, visit https://groups.google.com/d/optout.

--

Matt Sicker

Software Engineer, CloudBees

[Jesse Glick]

On Tue, Aug 14, 2018 at 6:04 PM R. Tyler Croy <ty...@monkeypox.org> wrote:
> The key aspect of it is _not_ the selection of
> plugins, but rather how those plugins get out there to users.

That just means you are concealing one aspect behind another, since
the only plugins which would be distributed using the “evergreen”
mechanism are those we consider, well, “essential” enough to track.
Everything else comes from the update center (or is blocked outright).

While I certainly agree that having two names was confusing, I think
the selection of plugins is a critical concern that should not be
brushed aside as a detail. I recall KK discussing the notion of an
Essentials team broadly trusted to work on (review, merge) anything in
the transitive dependency closure of essential plugins (including core
and component libraries), to reduce the friction of deploying coherent
features via Evergreen, including tracking metrics, managing feature
flags, and so on.

That is of course a big effort and a major change to developer
workflow, but it is also much more of what users care about than the
fact that they no longer need to spend time on the *Updates* screen.
It is about defining and delivering a coherent product.

Perhaps you just mean to disclaim responsibility for that effort, and
someone else TBA is going to step in? Or are we really dropping the
overall goals that were proposed for Essentials initially?

[R. Tyler Croy]

(replies inline)

On Wed, 15 Aug 2018, Jesse Glick wrote:

> On Tue, Aug 14, 2018 at 6:04 PM R. Tyler Croy <ty...@monkeypox.org> wrote:
> > The key aspect of it is _not_ the selection of
> > plugins, but rather how those plugins get out there to users.
>
> That just means you are concealing one aspect behind another, since

> the only plugins which would be distributed using the ???evergreen???
> mechanism are those we consider, well, ???essential??? enough to track.

> Everything else comes from the update center (or is blocked outright).
>
> While I certainly agree that having two names was confusing, I think
> the selection of plugins is a critical concern that should not be
> brushed aside as a detail. I recall KK discussing the notion of an
> Essentials team broadly trusted to work on (review, merge) anything in
> the transitive dependency closure of essential plugins (including core
> and component libraries), to reduce the friction of deploying coherent
> features via Evergreen, including tracking metrics, managing feature
> flags, and so on.

As I mentioned in the original email, the four pillars described in JEP-300 are
in tact, but the mere selection of some set of the plugins is not the marquee
feature here..

Any such notion from Kohsuke about a blessed team merging code in this
'brighter line' of functionality was never something defined in the original
scope of this effort:
<https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc>

The classic case of "GitHub configuration consolidation" is something I agree
should be solved, but a team of wizards refactoring and consolidating code is
only one potential solution to that problem.

There's still work scoped around the "Automatically sane defaults" pillar which
is more than likely going to address these user problems with scripting,
configuration, or special functinality included in the Evergreen distribution

> Perhaps you just mean to disclaim responsibility for that effort, and
> someone else TBA is going to step in? Or are we really dropping the
> overall goals that were proposed for Essentials initially?

I am happy to disclaim the responsibility for a team in charge of maintaining
all sorts of plugins which I don't believe I ever signed up for :-P


Of course, this email thread is a notice about consolidation of a brand name
which users will see, not about potential long-term evolutions of the project



Cheers