Request: Jenkins-STABLE branch

[Ed Randall]

Our organisation is a fairly heavy Hudson user. We have recently
hired a full-time build engineer with responsibility for migrating
a diverse variety of project environments to be managed under
Hudson control.

The Jenkins rename has been rather passionate and democratic,
now going forward we as a user need to decide what we are going
to do.

As I see it we have two options.
1) Do nothing, continue with the Oracle Hudson branch.
2) Put in a bit of effort and go with Jenkins.

The first option will be a lot easier to "sell" to my management.

One problem that we've encountered frequently in the past with Hudson
is stability after upgrades. Hudson's main screen effectively encourages
an upgrade to the latest release, but our experience is that release
often contains regressions and new bugs. On a number of occasions
we have upgraded in order to install a new plug-in but then had to
roll back due to other issues. We then spend time investigating
intermediate releases until we find a solid one with the new features
or fixes that we need but without the bleeding-edge bugs.

If Jenkins could improve the situation by releasing a -STABLE branch
which is tested more rigorously and updated less frequently, this
would be a real benefit to the user community. It would give me
something solid I can use to argue with management that we need to
make the switch.
(There's always a chance that Oracle could do this with Hudson I guess.)

Thanks and Best Regards,
Ed Randall
Senior Developer - JEE Systems Group
Wall Street Systems

____________________________________________________________
TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if5
Capture screenshots, upload images, edit and send them to your friends
through IMs, post on Twitter®, Facebook®, MySpace™, LinkedIn® – FAST!

[Rainer Weinhold]

Jup, the regression bugs are the biggest issue with hudson in a coporate environment, Can't tell how much time i wasted there. Would totally love to have two branches stable and dev.

My favourite solution would be :
- a small update-site-webapp in which one can manage the core and plugin versions beeing published
- one instance of this app should run on jenkins-ci.org, providing a stable and a dev branch

- now, having this webapp, it enables me to run my own instance inhouse and keep central control over all jenkins installations
  -> which then would lead to the request of a "auto-update to latests version" option

Cheers Rainer

hudso...@googlegroups.com schrieb am 01.02.2011 12:10:08:
> Von:
>
> Ed Randall <ed_ra...@ingenotech.com>
>
> An:
>
> hudso...@googlegroups.com
>
> Datum:
>
> 01.02.2011 12:10
>
> Betreff:
>
> Request: Jenkins-STABLE branch
>
> Gesendet von:
>
> hudso...@googlegroups.com

[Caraivan Constantin]

Hello,

 

Same situation here. Corporate user, installation with many slaves on many platforms. Each upgrade is a gamble.

 

Soon we will have to choose - Hudson vs Jenkins. Currently Jenkins seems ahead, but if Oracle comes up with a good plan for the future, including an increase in QA, it will be hard to sell Jenkins to management…

 

Regards,

_______________
Costin Caraivan

[Jason van Zyl]

On Feb 1, 2011, at 6:10 AM, Ed Randall wrote:

Our organisation is a fairly heavy Hudson user.  We have recently
hired a full-time build engineer with responsibility for migrating
a diverse variety of project environments to be managed under
Hudson control.

The Jenkins rename has been rather passionate and democratic,
now going forward we as a user need to decide what we are going
to do.

As I see it we have two options.
1) Do nothing, continue with the Oracle Hudson branch.
2) Put in a bit of effort and go with Jenkins.

The first option will be a lot easier to "sell" to my management.

One problem that we've encountered frequently in the past with Hudson
is stability after upgrades.  

This will be one of the areas of primary focus for Sonatype and when the rename happens today we will begin the process of merging most of our stabilization work back to Hudson. This will take a bit of time because we stepped off the train to decide how and who we wanted to continue working with. I think this whole situation is unfortunate, but ultimately Kohsuke has the right, like everyone else, to do what he feels is right. I honestly do not believe what has happened is in the best interest of users, but this is my opinion and only time will tell.

If anyone is interested in the work to be done on Hudson the java.net lists should be up, the @hudsonci twitter account will be very active, and I'll have a series of blog posts about the work Sonatype is planning to contribute, a critique of the current architecture, and proposed roadmap. While I'm sure we're not going to be very popular in the short term, continuing the Hudson with Oracle is what we feel is best. Our goals and motives have not changed since the first time I posted about Sonatype's potential involvement. We care about the IP, the provenance of the code, the stability of the core, helping to create a new architecture while maintaining backward compatibility, create great Maven integration and create a commercial product. We've done a lot of work for enterprise users and we hope to share this with the Hudson community as soon as we can.

I believe it is truly regrettable what has happened, but life goes on and I'm sure both projects will do well catering to their users.

Hudson's main screen effectively encourages
an upgrade to the latest release, but our experience is that release
often contains regressions and new bugs.  On a number of occasions
we have upgraded in order to install a new plug-in but then had to
roll back due to other issues.   We then spend time investigating
intermediate releases until we find a solid one with the new features
or fixes that we need but without the bleeding-edge bugs.

If Jenkins could improve the situation by releasing a -STABLE branch
which is tested more rigorously and updated less frequently, this
would be a real benefit to the user community.  It would give me
something solid I can use to argue with management that we need to
make the switch.
(There's always a chance that Oracle could do this with Hudson I guess.)

Thanks and Best Regards,
Ed Randall
Senior Developer - JEE Systems Group
Wall Street Systems

____________________________________________________________
TRY FREE IM TOOLPACK at http://www.imtoolpack.com/default.aspx?rc=if5
Capture screenshots, upload images, edit and send them to your friends
through IMs, post on Twitter®, Facebook®, MySpace™, LinkedIn® – FAST!

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

We all have problems. How we deal with them is a measure of our worth.

 -- Unknown

[Andrew Bayer]

I'm not sure if a stable branch, per se, is particularly viable - that presents the problem of triaging bug fixes to decide whether they go into the stable branch, rebuilding the plugin dependency logic to handle stable branches vs. normal releases, etc... But I am wholeheartedly behind having an endorsed "stable" build - not every week, obviously, but when a release has gotten 2-3+ weeks of use in the wild and has been tested enough to warrant it, it'd make sense to mark it as the latest "stable" release, with the update center displaying the option to upgrade to the stable release as well as the bleeding edge release. Does that sound like at least part of what you're looking for?

A.

[Ed Randall]

I was really hoping for a bit more than that.

Previously there was a hudson-download web page that showed some user-approval statistics
which gave a bit of an indication as to the stability of a build.  It was insufficient and I don't think
this proposal is an awful lot different. 

I was thinking of something more like many other open-source projects where they maintain a
stable branch somewhat independently of the main development trunk, but occasionally important
fixes are merged back  (Linux kernel odd/even numbered releases come to mind though I am
unfamiliar with their exact process).  The triage decision for this would have to be based on
both -STABLE user demand and testing.  Fixes to be proven in -DEV first.   From time to time
the development branch reaches a milestone and is stabilised,  after a period of intense testing
and fixing a major release is declared. That release is copied over to -STABLE and becomes
the new stable head version until the next development milestone.

We're on Git now and my understanding is that Git was written explicitly to handle this kind
of branch/merge scenario easily.

Having broken free of Oracle, Jenkins really needs to raise the bar now to prove itself for
production.  You guys can still hack away on the -DEV leading edge but many of us are a
bit more conservative, we prefer the dull predictability of a solid -STABLE release to all
that excitement!

A roadmap would be useful at this point, to indicate milestones and where the project is going.

Regards,
Ed

---

Share photos & screenshots in seconds...
Try FREE IM ToolPack at www.imtoolpack.com
Works in all emails, instant messengers, blogs, forums and social networks.

[Jesse Farinacci]

Greetings,

On Tue, Feb 1, 2011 at 10:37 AM, Ed Randall <ed_ra...@ingenotech.com> wrote:

I was thinking of something more like many other open-source projects where they maintain a
stable branch somewhat independently of the main development trunk, but occasionally important
fixes are merged back  (Linux kernel odd/even numbered releases come to mind though I am
unfamiliar with their exact process).  The triage decision for this would have to be based on
both -STABLE user demand and testing.  Fixes to be proven in -DEV first.   From time to time
the development branch reaches a milestone and is stabilised,  after a period of intense testing
and fixing a major release is declared. That release is copied over to -STABLE and becomes
the new stable head version until the next development milestone.

What you're describing is an awful lot of work. Are you volunteering to help with it? There are several for-money offerings that are doing exactly this, with many full time workers to provide a -STABLE tree..

Also, there's no one forcing you to run the latest development version. Why isn't the basic strategy of " just don't upgrade " not a good candidate? You seem to want to cherry pick the best of -DEV but not have to do any testing of your own.

 

Having broken free of Oracle, Jenkins really needs to raise the bar now to prove itself for
production.  You guys can still hack away on the -DEV leading edge but many of us are a
bit more conservative, we prefer the dull predictability of a solid -STABLE release to all
that excitement!

Again, just don't upgrade. Once you find a stable version, just sit on it until you absolutely have to upgrade to pick up some plugin or core feature. Someone did suggest making the " newer version of Jenkins is available " banner less obtrusive, and I think that's a good idea. Maybe not having to be reminded of a newer version would give people peace of mind for just squatting on a lower level release..

 

A roadmap would be useful at this point, to indicate milestones and where the project is going.

I think we're all looking forward to seeing it! But.. There are a ton of infrastructure changes still going on, I don't think it is reasonable to expect a roadmap until at least next week though.

-Jesse

--
There are 10 types of people in this world, those
that can read binary and those that can not.

[ted]

Ed,

On Feb 1, 7:37 am, Ed Randall <ed_rand...@ingenotech.com> wrote:
> I was really hoping for a bit more than that.

> I was thinking of something more like many other open-source projects where they maintain a
> stable branch somewhat independently of the main development trunk, but occasionally important
> fixes are merged back 

We have heard this a lot from our users. We have a proposal we are
working on sending out to the Hudson community for review that will
create a stable Hudson build that is updated every 6 weeks or so.
People can always grab the latest if they want to, but for users who
don't, they can rely on a stable version with well-documented changes
and passing certification tests. Part of this proposal is also to
change the versioning scheme to be a 3 digit number (eg. 1.3.99) where
the first number is major changes, the second is smaller enhancements
and the third is bug fixes. This also should provide better insight
into what each release means to users picking them up.

-ted

[Romain Seguy]

Ted,

One question regarding the plan that Oracle + Sonatype is going to
propose (because my understanding is that the plan is common): How the
"Hudson community" will be integrated into it? I mean, will the
community still be considered as a major contributor as it was before
"The Event" and fully part of the decision making, thus being able to
bring big unplanned changes, or will it act more as a validator of
what's proposed by O+S?

Thanks,
Romain

2011/2/1 ted <ted...@gmail.com>:

[ted]

Hi Romain,

> One question regarding the plan that Oracle + Sonatype is going to
> propose (because my understanding is that the plan is common): How the
> "Hudson community" will be integrated into it? I mean, will the
> community still be considered as a major contributor as it was before
> "The Event" and fully part of the decision making, thus being able to
> bring big unplanned changes, or will it act more as a validator of
> what's proposed by O+S?

We are hoping that the community is the major driving factor in
Hudson's future. Any changes that Oracle or Sonatype want to make
will go through a process (similar to the one I posted last month[1])
where the community can comment and contribute. It should be an equal
playing field with decisions about the software.

In talking with Jason I think a lot of what he describes in this
thread is already written, but that will be reviewed by the community
just like anybody else. In the future we are encouraging people to
post descriptions of new work even before they start major coding so
that more requirements and opinions can be heard early on. That will
also save people time if they need to change things because of
community feedback. We are looking forward to an open, stable and
predictable community built up around Hudson.

The Hudson mailing lists will move back to the ones on java.net after
the rename in a little more than an hour. You can track the things we
are doing there starting this morning.

-ted


[1] http://hudson-ci.org/docs/Hudson_Process_v0.4.html

[Andrew Bayer]

I think this is definitely a worthy goal - we just need a lot more QA to make this viable, I think. That, of course, is one of the inherent challenges of open source development - we don't have dedicated QA resources available in the way a commercial, corporate product would. So we end up having to rely on willing users to serve as our QA. I think the basic concept of a stable release is about the same in what you're saying and my initial thoughts, with backported fixes being the major difference - I'm not opposed to that, I'm just not entirely sure how we can make it work effectively. That said, I am most certainly open to ideas as to *how* to make it work. =)

A.

[pelegri]

The GlassFish and the NetBeans folks had very successful CAT ("Community
Acceptance Team") [[and so did the XEmacs years ago]]. I think we should be
able to do this, specially with the GitHub machinery.
--
View this message in context: http://hudson.361315.n4.nabble.com/Request-Jenkins-STABLE-branch-tp3250915p3252475.html
Sent from the Hudson dev mailing list archive at Nabble.com.

[Sacha Labourey]

Ed,

In many FOSS projects, contributors are not necessarily directly
focused on backward compatibility - but rather on new features, fixes,
etc.

This is why you can find lots of "productized" offering on top of Open
Source projects, sold and supported by vendors, providing that kind of
"Enterprise" features. Examples include Linux/Fedora/RHEL/Unbreakable
Linux, JBoss/EAP, Geronimo/WebSphere CE, etc.

You'll find several companies offering this for Jenkins (including
ours).

This by no mean imply that nobody from the community would be willing
to step up and provide this directly as part of the community.

Cheers,


Sacha

> TRY FREE IM TOOLPACK athttp://www.imtoolpack.com/default.aspx?rc=if5

[Richard Bywater]

Doh, wrong email address - lets try that again :)

---------- Forwarded message ----------
From: Richard Bywater <rbyw...@gmail.com>
Date: Wed, Feb 2, 2011 at 8:54 AM
Subject: Re: Request: Jenkins-STABLE branch

To: jenki...@googlegroups.com

Hi Jesse

I think one issue with the "do not upgrade" approach is that its hard
to know when it is safe to upgrade. For instance we're sitting on
1.372 currently. Everytime a new release comes out I think that its
time to upgrade but have no idea whether it's stable enough to move
to.

Personally I think unless QA of releases in increased (although I'm
not sure exactly how), I think that the Oracle offering will eat
Jenkins alive in the corporate world (as presumably they've got whole
teams of people they can throw at it)

My 2 cents...
Richard.

[Jesse Farinacci]

Greetings,

On Tue, Feb 1, 2011 at 2:55 PM, Richard Bywater <rbyw...@gmail.com> wrote:
>
> I think one issue with the "do not upgrade" approach is that its hard
> to know when it is safe to upgrade. For instance we're sitting on
> 1.372 currently. Everytime a new release comes out I think that its
> time to upgrade but have no idea whether it's stable enough to move
> to.

Yep, there have been a few false starts for this kind of thing. What I
do in my shop is run Hudson privately for a couple of days when I'm
thinking about upgrading. I have all our core plugins, and I build a
few of the Apache Maven modules so that if I find any bugs I can
report bugs with them and have a fully working config.xml for someone
outside my company to reproduce the problem.

I think this is the best that can be done right now. Maybe if the
anonymous usage data was more real time, it would shine a brighter
light on which versions might be safest to hop to.

[Jerome Lacoste]

On Tuesday, February 1, 2011 4:37:37 PM UTC+1, Ed Randall wrote:

I was really hoping for a bit more than that.

Previously there was a hudson-download web page that showed some user-approval statistics
which gave a bit of an indication as to the stability of a build.  It was insufficient and I don't think
this proposal is an awful lot different. 

I was thinking of something more like many other open-source projects where they maintain a
stable branch somewhat independently of the main development trunk, but occasionally important
fixes are merged back  (Linux kernel odd/even numbered releases come to mind though I am
unfamiliar with their exact process). 

Linux isn't using odd/even numbered releases anymore.

 

The triage decision for this would have to be based on
both -STABLE user demand and testing.  Fixes to be proven in -DEV first.   From time to time
the development branch reaches a milestone and is stabilised,  after a period of intense testing
and fixing a major release is declared. That release is copied over to -STABLE and becomes
the new stable head version until the next development milestone.

I would prefer something along the lines of Linux stabilization kernel tree.

http://www.linux.com/learn/tutorials/387494:understanding-the-stable-linux-kernel

http://www.kroah.com/log/linux/how-i-do-stable.html

e.g. if 1.400 is stable (i.e. long support), then take fixes from 1.401, 1.402, etc and backport to 1.400 for a few weeks/months. How long stable branches must be supported.

Jerome

[Erik Bertelsen]

I'd like to suggest something that I have learned to appreciate from the Apache Tomcat project:

When the developers "feel for it", they define a new release.

Initially the release is mostly known by the developers (and developer-type and other experimental people). A vote is defined where formal developers and any other interested party may indicate their evaluation of this build.

Some builds are designated as being alpha/beta when not enough voters support them as a full release. Other builds get a full release designation if enough formal (and other participants) vote for it.

In rare cases, at build that was initially designated as a full release may be re-designated to alpha/beta if a serious problem is detected.

Result: we just have one place of future development, i.e. focus is maintained for developers of the product. We also have a formal evaluation of each build/release in order to tell users/consumers of the product the status of each release. The recommended release for normal deployment is not always "just" the newest build/release.

kind regards
 - Erik

2011/2/2 Jerome Lacoste <jerome....@gmail.com>

[Caraivan Constantin]

This vote for release seems interesting, I saw Maven developers doing this too.

However, there's a something I didn't see anyone mention - *plugin quality*. Even if the Jenkins core is stable, the plugins make or break an installation or upgrade.

 

Right now each plugin has its own release + QA cycle and there's no easy way to see the maturity of the plugin. Compare this with Maven, for example:

http://maven.apache.org/plugins/ -> core Maven plugins, usually solid

http://mojo.codehaus.org/plugins.html -> other Maven plugins, with levels of maturity: Production, Pre-release, Sandbox, Graveyard.

 

The Hudson/Jenkins plugin list doesn't help much - ok, there are hundreds of plugins. But which of them can be relied on now and in the future, and which are just code drops no one is maintaining?

 

I could help with the Wiki editing, but the plugin developers need to rate their plugins according to several categories. For example Berlios has a nice rating system:

    1 - Planning

    2 - Pre-Alpha

    3 - Alpha

    4 - Beta

    5 - Production/Stable

    6 - Mature

    7 - Inactive

 

Regards,

_______________
Costin Caraivan

From: jenkin...@googlegroups.com [mailto:jenkin...@googlegroups.com] On Behalf Of Erik Bertelsen
Sent: 2 februarie 2011 16:08
To: jenkin...@googlegroups.com
Subject: Re: Request: Jenkins-STABLE branch

 

I'd like to suggest something that I have learned to appreciate from the Apache Tomcat project:

[Jan Ruzicka]

Hi

I would like to add to the plugin stability discussion.

There is the chicken and the egg problem should I, as a plugin maintainer, try to update plugin and risk breaking compatibility.

I miss some easy way to test compatibility of plugins agains different Hudson/Jenkins releases.

Reinstalling versions and repeated testing of functionality is too time and resource consuming.

My plugin (Starteam) has additional complication of being dependent on proprietary piece of licensed software.

It severely limits the testing pool.

Are there any automated tests/scripts that can determine compatibility?

I know the versions in POM file may be a clue, but I'm thinking along the lines of interfaces that need to be implemented or  should not be used for given version.

When we are talking about plugins, will there be a package name space cleanup?

I'm asking about it because Hudson plugin packages are split between different OrgIDs. 

Sincerely

Jan

[Henrik G. Sørensen]

The Maven Clirr plugin (http://mojo.codehaus.org/clirr-maven-plugin/) perhaps might be of help? - It would only help at the API level however.

 

It doesn't catch everything either, but it might perhaps be a starting point.

 

Best,

Henrik

---

Fra: jenkin...@googlegroups.com [jenkin...@googlegroups.com] På vegne af Jan Ruzicka [jan.r...@comtechmobile.com]
Sendt: 2. februar 2011 17:26
Til: jenkin...@googlegroups.com
Emne: Re: Request: Jenkins-STABLE branch

[Jerome Lacoste]

On Wednesday, February 2, 2011 5:26:01 PM UTC+1, Jan Ruzicka wrote:

Hi

[...]

My plugin (Starteam) has additional complication of being dependent on proprietary piece of licensed software.

It severely limits the testing pool.

There are test strategies for writing plugins against proprietary APIs. Back in the CruiseControl days for example, I was using a fake API (written from scrach), to at least allow compilation for those not having the licensed software on their machine. Combined with mocking you can achieve quite a bit of coverage.

Let me know if you are interested.

Jerome

[Vojtech Juranek]

Hi,
labeling packges seems to me as a good idea which could help at least little
bit. Do you exptect some additional criteria (not just labeling) - e.g. that
if maintainer labes his plugin as "Production", he is supposed to test it
against each new Jenkins release?

Probably a lot of people test new Jenkins release in their environment before
deploying it into production, which includes also some testing of plugins.
Another thing which could help little bit is to share this information in some
systemac way.

Also up to date results from anonymous Jenkins usage data could be useful -
e.g. some 2D plot, on one axis hudson version, on the other plugin names and
showing number of deplyments (or e.g. mark given coordinate as green if there
is more then 5/10/? deployments of the given plugin with given Jenkins release
- this would asseme that if plugin is running on more the 5/10/? instances, it
probably works or at least does't cause any significant problems)
Does it sound reasonable to you?

[Caraivan Constantin]

It sounds reasonable :)

So, basically, it would be an anonymous usage survey, coming from the
Jenkins update center. Is this already implemented or it's meant to be a
new plugin?

Something which could show the number of deployments and the
combinations of versions, maybe even some details about the size of the
deployment (X slaves, Y platforms, Z jobs) would be great.
The base question is: I'm an existing user and I want to upgrade. What
do I chose? Where can I find some relevant information about the upgrade
decision?

Regards,
_______________
Costin Caraivan

[Frederic Camblor]

Yeah this would be cool ! :-)

Moreover, this information is already gathered (andrew posted, some monthes ago, statistics like this).

But it represents a substantial amount of informations ! (json object representation was about 2,4Go)

Would be cool to have plugins usage statistics, too, in these dashboards.

Frédéric

[Kohsuke Kawaguchi]

I think this is where the Andrew's original idea of endorsed stable
release would help.

We actually did it for a while, so let me explain it once again here:

- In the project top page, there used to be two download links.
One that said "latest&greatest", which pointed to the last release,
and the other that said "old&stable", which pointed to one of the
earlier versions that are known to work well.

- The goal of the latest & greatest was to deliver bug fixes and
new features that plugin developers needed quickly.

- The goal of the old & stable was to make it easy for people to
find old stable release, at the expense of losing some cutting edge
features.

We can further build upon it, like:

- Produce a separate update center that only advertises the old&stable
releases?

- Perhaps we can even try to backport some important bug fixes
to generate 1.X.1, 1.X.2, and so on, from the old&stable line.
We'll have to count on more volunteers to help with this effort,
though, in terms of cherry-picking changes from the trunk.

In the past few months, I think different people told us that the
release process should be revisited. I think we should make some changes
--- we just need to figure out exactly how to do it.

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/

[Jerome Lacoste]

On Thursday, February 3, 2011 8:11:15 PM UTC+1, Kohsuke Kawaguchi wrote:

I think this is where the Andrew's original idea of endorsed stable
release would help.

We actually did it for a while, so let me explain it once again here:

- In the project top page, there used to be two download links.
   One that said "latest&greatest", which pointed to the last release,
   and the other that said "old&stable", which pointed to one of the
   earlier versions that are known to work well.

- The goal of the latest & greatest was to deliver bug fixes and
   new features that plugin developers needed quickly.

- The goal of the old & stable was to make it easy for people to
   find old stable release, at the expense of losing some cutting edge
   features.

We can further build upon it, like:

- Produce a separate update center that only advertises the old&stable
   releases?

- Perhaps we can even try to backport some important bug fixes
   to generate 1.X.1, 1.X.2, and so on, from the old&stable line.
   We'll have to count on more volunteers to help with this effort,
   though, in terms of cherry-picking changes from the trunk.

I can definitively help identifying commits that should be backported to a stable branch.

Jerome 

[Harry G.]

I also emphasize that a regression tested and stable release is the
major issue in the enterprise market.
In particular it might be the only thing where Oracle/Hudson might
outperform Jenkins!

So sure there needs to be more regression testing, maybe this is the
solution:

> The GlassFish and the NetBeans folks had very successful CAT ("Community
> Acceptance Team") [[and so did the XEmacs years ago]]. I think we should be
> able to do this, specially with the GitHub machinery.

Concerning stable releases, I like the idea of voting and of endorsed
releases, but I think that's not enough.
Here's my proposal.
Sorry, only rough and without Jenkis core knowledge, but maybe some
good ideas?

1. for core
* split core in smaller artifacts (as far as possible) with labels for
stable
* developers vote which version of which artifacts is stable
* decision and marking as stable is done by the project board
* together all stable artifacts make the stable release
-> this is tricky, I'm aware of the problem of dependencies of
changes distributed over artifacts
* offer both stable and latest&greatest download (but avoid the word
"old" ;-)
* offer them also in automatic updates in UI (stable ones maybe in
bigger font)
* provide a branch for important bugfixes on stable releases, what KK
wrote on this is a must-have:

> - Perhaps we can even try to backport some important bug fixes
> to generate 1.X.1, 1.X.2, and so on, from the old&stable line.

* also here voting could help: a voting link on the changelog to say
which fix is important to merge back

2. for plugins
* all plugins have a label for their stable release
* even better: one label for each core version, like "stable for
1.396", "stable for 1.395"; of course several labels would then stick
on one plugin release
* all users can chose whether to download the stable or newest version
* all users can vote how stable a certain plugin release is
* this vote is automatically combined with the Jenkins release number
they run the plugin on
* this is all fully integrated in the "manage plugins" page
* the plugin maintainer decides, which release is marked as stable
* therefore he also does regression tests against the current stable
release
* the stable marking is scheduled together with the Jenkins releases
(a bit like Eclipse release train), i.e. stable core releases are
announced early enogh
* plugin maintainers not willing or able to do this just don't have
stable marked releases - the user can see this in the "manage plugins"
page and can decide if he tries the plugin anyway; it just has to be
convention that people don't mark their plugin as stable without
voting and testing

I know this is work, but I don't believe it's awful lot of work, once
it is established.
We definitely need something like this to beat Oracle. It will be
their trump.
I offer to personally help with this, if it is useful as I'm not a
Jenkins developer (yet).

What do you think?

Harald

[Caraivan Constantin]

Hello,

Nice suggestion :)
Don't really know about the core, but for the plugins, I think that the
Hudson plugins are very similar to Firefox add-ons.

It might be a good idea to see how the Mozilla guys handle this. I'm
pretty sure that the promoted plugins (those on addons.mozilla.org) have
at least some minimal QA checks before being made available. And there's
also an add-on black list in Firefox, so that known trouble-makers can
be blocked.

Maybe there's a Firefox developer somewhere around here which can
enlighten us? :)
_______________
Costin Caraivan

[Arnaud Héritier]

I agree that even if we can always find some bugs in core, the major part of real issues are from plugins. I agree we should have a triage and a better visibility for each one (We already discussed on another thread about having a dedicated Jira for each plugin and we could have them group together in various categories + the necessary doc/classification in the wiki).

As Jenkins (the community version) doesn't always have the expected level of quality users have to understand that if they don't pay for the software, they are paying with the time they invest in it. The advantage of Jenkins and it's plugins is that it isn't complex to enter in plugins code (even if some of them could improve the quality of devs) and thus they can temporarily patch it if they cannot rollback an upgrade.

Thus definitively yes to classify, yes to try to improve the quality (core and plugins) with more tests, etc and with indicators to monitor it.

[Vojtech Juranek]

> It sounds reasonable :)
>
> So, basically, it would be an anonymous usage survey, coming from the
> Jenkins update center. Is this already implemented or it's meant to be a
> new plugin?

I'm not aware of any implementation. Finally I had some time to write PoC of
this idea - table attached as "topPlugins.html". It's only for top 30 plugins.
The box is green if there are 10 or more installations of this plugin on given
Hudson version, otherwise red. First number is Hudson version, second is
number of instalations of plugin on this Hudson version.

The table is quite huge and for all plugins it would be even less lucid.
Therefore I tried somehow summarize this data. I took into an account only
plugins, which have 10 or more installation on given Hudson version and sum
number of such plugins for each version. Result is attached as
"topVersions.html" and these plugins are listed for completeness. I could
imagine some more complex function taking into accnout number of deployments
of given Jenkins version itself, how lager is the deployment or how old the
version is. This is just a PoC, if the community is interested and especially
KK et al. as this should be published on Jenkins web page (implementing it as
a pluging doesn't seem to be reasonable)

Both tables are based on data from July 2010 (therefore version is refered as
Hudson version).

[Chinna Gangarum]

I am using hudson 1.366. Could you please let me know starteam plugin works or not, if yes which version of the plugin.