Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Newcomers » Proposals » Hudson Proposal posted
Hudson Proposal posted [message #668236] Wed, 04 May 2011 15:38 Go to next message
Wayne Beaton is currently offline Wayne Beaton
Messages: 501
Registered: July 2009
Senior Member
Greetings folks. We've just posted a new proposal [1] for Hudson.

The primary goals of this project are to make a high-quality continuous
integration server and help the ecosystem of Hudson plugins, extensions
and integrations flourish.

We look forward to your questions!

Wayne

[1] http://www.eclipse.org/proposals/technology.hudson/
Re: Hudson Proposal posted [message #668257 is a reply to message #668236] Wed, 04 May 2011 17:19 Go to previous messageGo to next message
Kaloyan Raev is currently offline Kaloyan Raev
Messages: 188
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member
Hi,

It is quite interesting to see this proposal. Please add me to the list of Interested Parties. I think I will ask a question that the people who proposed this project to Eclipse should have expected.

How about the Jenkins community?

The Hudson vs. Jenkins fight is quite popular at the moment? Now, when proposing Hudson to Eclipse, do you have any plans to merge Hudson and Jenkins back to a single project hosted at Eclipse? Do you have any talks with the Jenkins community about this?

Greetings,
Kaloyan
Re: Hudson Proposal posted [message #668266 is a reply to message #668257] Wed, 04 May 2011 18:13 Go to previous messageGo to next message
Ted Farrell is currently offline Ted Farrell
Messages: 4
Registered: May 2011
Junior Member
> Kaloyan Raev wrote:
> The Hudson vs. Jenkins fight is quite popular at the moment? Now, when proposing Hudson to Eclipse, do you have any plans to merge Hudson and Jenkins back to a single project hosted at Eclipse? Do you have any talks with the Jenkins community about this?

Hi Kaloyan, I can't speak for the Jenkins folks, but one of the good things about Hudson moving to Eclipse is that anyone can participate. When the fork happened, I think it came down to a difference of opinion about how to run an open source project. Oracle and Sonatype wanted more of an enterprise focus, and Cloudbees wanted more of a grass-roots environment which is how Hudson came to be. I think both are valid opinions.

So when we started talking about this move to Eclipse, we initially focused on talking to people who's views were more in line with our Enterprise focus. Now that the proposal is public, We welcome anyone to join the conversation over the next 2 months while we finalize the submission and get it accepted.

Let me know if you have any other questions.

-ted

Ted Farrell
Oracle Corporation.
Re: Hudson Proposal posted [message #668296 is a reply to message #668266] Wed, 04 May 2011 22:13 Go to previous messageGo to next message
Kaloyan Raev is currently offline Kaloyan Raev
Messages: 188
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member
Hi Ted,

Thanks for your answer.

I would say that the only meaningful reason to have Hudson at Eclipse is that this move will unity the Hudson/Jenkins community. If this does not happen, then creating the project with only one of the belligerent sides will cause significant damage to the Eclipse Foundation and the Eclipse community.

Therefore, the major focus of this proposal should be on how the Eclipse Development Process will help the Hudson/Jenkins community to move from the current lose-lose situation to a united and stronger-than-before community. The proposal should be written in more open and invited spirit that opens the doors and gives hand to the Jenkins community. The current text is far away from this state and IMHO needs a complete rewriting.

Statements like who made the fork and who has the enterprise focus are just pouring fuel in that stupid flame war. There are a lot of companies with enterprise focus that are currently forced to make the unwanted choice between Hudson and Jenkins. And for some of them the major factor is which community is the most productive and trusted. It would be the best if there is no need for such choice. My hopes in this proposal are that we will have again one united community.

Greetings,
Kaloyan
icon14.gif  Re: Hudson Proposal posted [message #668411 is a reply to message #668236] Thu, 05 May 2011 15:15 Go to previous messageGo to next message
Martijn Verburg is currently offline Martijn Verburg
Messages: 1
Registered: July 2009
Junior Member
As stated elsewhere, I applaud this initiative!

I think that all efforts should be made to actively get the Jenkins community to join, if that can be done then this proposal instantly becomes very compelling for the Eclipse Foundation.

* It will remove any contentious them vs. us debates/rhetoric etc that has occurred in the past
* It will give the project a large developer community, it will allow the project to draw upon the expertise of those Jenkins developers
* It will give the project a large user community
* It will allow the project to massively widen its extensions/plugins base

Add those factors to the commercial/enterprise resources and expertise that the existing interested parties bring to the table, and you have what shapes up to be a truly remarkable project.

My simple suggestions

* Invite KK to become one of the project leaders.
* Invite other proven Jenkins committers to be committers on this proposed project.

A vast majority of the London Java Community would love to see the communities merge once more for practical as well as community reasons.


Cheers,
Martijn (Twitter: @karianna @java7developer)

[Updated on: Fri, 06 May 2011 10:26]

Report message to a moderator

Re: Hudson Proposal posted [message #668502 is a reply to message #668296] Thu, 05 May 2011 21:05 Go to previous messageGo to next message
Gunnar Wagenknecht is currently offline Gunnar Wagenknecht
Messages: 452
Registered: July 2009
Location: Germany ✈ Vancouver
Senior Member

Am 05.05.2011 00:13, schrieb Kaloyan Raev:
> I would say that the only meaningful reason to have Hudson at
> Eclipse is that this move will unity the Hudson/Jenkins community.
> If this does not happen, then creating the project with only one
> of the belligerent sides will cause significant damage to the Eclipse
> Foundation and the Eclipse community.

I'm sorry but don't really understand what damage would be caused to the
Eclipse Foundation and community?

Frankly, the fork happened. A single proposal won't reverse it. There
are many issues along the road (legal, technical, communication). IMHO
only time will show *if* the two communities will merge again in the
future. Bringing such a requirement into a proposal will not make it
happen. The proposal is a first step. Many more have to follow.

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
Re: Hudson Proposal posted [message #668510 is a reply to message #668296] Thu, 05 May 2011 22:24 Go to previous messageGo to next message
Ted Farrell is currently offline Ted Farrell
Messages: 4
Registered: May 2011
Junior Member
Kalovan,

Kaloyan Raev wrote on Wed, 04 May 2011 18:13

I would say that the only meaningful reason to have Hudson at Eclipse is that this move will unity the Hudson/Jenkins community. If this does not happen, then creating the project with only one of the belligerent sides will cause significant damage to the Eclipse Foundation and the Eclipse community.



I think we are talking about two different issues here. The proposal was submitted to add formal governance to the Hudson project as well as reduce the Oracle footprint on the ownership to make it more approachable. The issue you are talking about is reuniting Jenkins and Hudson. I disagree that the former is worthless without the latter.

Since the fork, the two communities have been doing their own thing. I don't believe that in order for us to be able to spend resources on improving Hudson we have to reunite with Jenkins. No one is putting the same requirements on them. We have thousands of users who are relying on us to improve and support Hudson. I think it is our responsibility to do that for them.

I do think that the Eclipse foundation is a good neutral ground if any such reunion were to happen, but again, this proposal is about Hudson. It is not meant for a commentary on Jenkins.

Kaloyan Raev wrote on Wed, 04 May 2011 18:13

Statements like who made the fork and who has the enterprise focus are just pouring fuel in that stupid flame war.


Again, I respectively disagree. I believe this is an important distinction that came out of our talks pre-fork. There are people that like rapid iterations and more free-form processes and there are people that don't. I think that there are different ways to run an open source project and I don't think that is a bad thing. I specifically commented that I think both ways are valid, but I think we need to acknowledge the difference in order to understand the landscape and talk about any possible solution.





Re: Hudson Proposal posted [message #668795 is a reply to message #668236] Sat, 07 May 2011 14:26 Go to previous messageGo to next message
Werner Keil is currently offline Werner Keil
Messages: 1083
Registered: July 2009
Senior Member
Considering I'm one of the few (~15) people, Hudson follows on Twitter, would you mind returning the favour and listing me as Interested Party.

Either as UOMo Project Lead or with emergn as company (e.g. as in the Jubula proposal Razz )

Thanks,
Werner
Re: Hudson Proposal posted [message #668796 is a reply to message #668236] Sat, 07 May 2011 14:31 Go to previous messageGo to next message
Werner Keil is currently offline Werner Keil
Messages: 1083
Registered: July 2009
Senior Member
Hi,

For some strange reason it seems, posts here are not always properly stored?! Shocked

Just tried a reply, and will do it again, assuming this message at least shows up.

Maybe that's the reason why some Tweets (mostly from Jenkins committers it seems Rolling Eyes ) reckon there isn't much traffic here...
Re: Hudson Proposal posted [message #668797 is a reply to message #668236] Sat, 07 May 2011 14:31 Go to previous messageGo to next message
Werner Keil is currently offline Werner Keil
Messages: 1083
Registered: July 2009
Senior Member
Hi,

For some strange reason it seems, posts here are not always properly stored?! Shocked

Just tried a reply, and will do it again, assuming this message at least shows up.

Maybe that's the reason why some Tweets (mostly from Jenkins committers it seems Rolling Eyes ) reckon there isn't much traffic here...
Re: Hudson Proposal posted [message #668798 is a reply to message #668797] Sat, 07 May 2011 14:32 Go to previous messageGo to next message
Werner Keil is currently offline Werner Keil
Messages: 1083
Registered: July 2009
Senior Member
It worked, but my first approach to reply directly to Wayne's post failed twice?! Confused
icon4.gif  Re: Hudson Proposal posted [message #668799 is a reply to message #668236] Sat, 07 May 2011 14:33 Go to previous messageGo to next message
Werner Keil is currently offline Werner Keil
Messages: 1083
Registered: July 2009
Senior Member
Seems you can't reply to any post at least in Chrome, reply to the actual thread worked.
Re: Hudson Proposal posted [message #668801 is a reply to message #668236] Sat, 07 May 2011 14:46 Go to previous messageGo to next message
Werner Keil is currently offline Werner Keil
Messages: 1083
Registered: July 2009
Senior Member
Wayne,

Glad to see, Hudson might get a little more attention here, than it used to at Sun/Oracle Razz

As I am one of the few (~15) people, who Hudson is following on Twitter, may I ask you to return the favour and list me as Interested Party?

Either as UOMo Project Lead or emergn consultant (see Jubula)

TIA,
Werner
Re: Hudson Proposal posted [message #669239 is a reply to message #668236] Mon, 09 May 2011 15:05 Go to previous messageGo to next message
Kohsuke Kawaguchi is currently offline Kohsuke Kawaguchi
Messages: 2
Registered: July 2009
Junior Member
There are several 3rd party libraries listed under "various organizations" that should be under "Kohsuke Kawaguchi" in http://www.eclipse.org/proposals/technology.hudson/Hudson3rd PartyLicenses.txt

Ones that I noticed thus far are:

Bridge method injector
Annotation for JDK requirements
windows-remote-command
Custom Acess Modifier annotations
Graph Layout Library
PuTTY support for Trilead SSH2 library
jinterop-proxy
META-INF/services generator

Would you please correct them?
Re: Hudson Proposal posted [message #669322 is a reply to message #669239] Mon, 09 May 2011 22:07 Go to previous messageGo to next message
Ted Farrell is currently offline Ted Farrell
Messages: 4
Registered: May 2011
Junior Member
Kohsuke,

Kohsuke Kawaguchi wrote on Mon, 09 May 2011 11:05
There are several 3rd party libraries listed under "various organizations" that should be under "Kohsuke Kawaguchi" ...

Would you please correct them?


We will get this cleaned up. I think the script just noted "various" if it wasn't sure. The goal during the submission cleanup is to make sure that your name is at the top of all of the code you wrote, including these kinds of libraries.

Please let us know if you notice anything else we might have missed.

-ted

Re: Hudson Proposal posted [message #670116 is a reply to message #668502] Thu, 12 May 2011 17:32 Go to previous messageGo to next message
Kaloyan Raev is currently offline Kaloyan Raev
Messages: 188
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member
Gunnar Wagenknecht wrote on Fri, 06 May 2011 00:05
I'm sorry but don't really understand what damage would be caused to the
Eclipse Foundation and community?


Gunnar, this proposal is quite different in nature compared to the typical proposals we have at Eclipse. I cannot recall to a similar situation, where an open source projects forks - one of the sides forms another open source community, and the other side, after some time, moves what's left from the original project to Eclipse.

As it can be seen in the comments in many blog posts, the Hudson/Jenkins drama has not settled down yet. For many people, Oracle earned quite bad reputation as a participant in the open source communities. I know that Oracle is a good citizen in the Eclipse community - I have excellent working relations with several Oracle committers. But this good face of Oracle is not very well known outside the Eclipse community. The open source communities outside Eclipse see another face of Oracle - the one that acts in the Hudson project. And in this case Oracle could do it way better.

Since Oracle didn't manage to work with what's now called the Jenkins community, why moving the Hudson project from java.net to Eclipse will make it better? The positive answer would be: because this will make possible the reunion of Hudson and Jenkins. But, based on the Ted's comments, it does not seems that this is the motivation of Oracle to move the project to Eclipse.

Then the question is: why Oracle makes this move? There are people that can think that this is yet another maneuver in the Hudson vs Jenkins war. And the Eclipse Foundation is yet another weapon in the hands of mighty Oracle.

I know that the above words are extremely speculative. But there are people that actually think like this. And this reflects to the reputation and trust of the Eclipse Foundation and the Eclipse community.

Gunnar Wagenknecht wrote on Fri, 06 May 2011 00:05
Frankly, the fork happened. A single proposal won't reverse it. There
are many issues along the road (legal, technical, communication). IMHO
only time will show *if* the two communities will merge again in the
future. Bringing such a requirement into a proposal will not make it
happen. The proposal is a first step. Many more have to follow.


You are correct. And this is not a requirement, just an opinion. There is no legal way that I can put requirements to any Eclipse proposal. We have the Eclipse Development Process for this.

I just wanted to say that I see no benefit of having the Hudson project at Eclipse, if this does not involve the Jenkins community adequately.
Re: Hudson Proposal posted [message #670124 is a reply to message #668510] Thu, 12 May 2011 17:45 Go to previous messageGo to next message
Kaloyan Raev is currently offline Kaloyan Raev
Messages: 188
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member
Ted Farrell wrote on Fri, 06 May 2011 01:24
Kalovan,

Kaloyan Raev wrote on Wed, 04 May 2011 18:13
I would say that the only meaningful reason to have Hudson at Eclipse is that this move will unity the Hudson/Jenkins community. If this does not happen, then creating the project with only one of the belligerent sides will cause significant damage to the Eclipse Foundation and the Eclipse community.


I think we are talking about two different issues here. The proposal was submitted to add formal governance to the Hudson project as well as reduce the Oracle footprint on the ownership to make it more approachable. The issue you are talking about is reuniting Jenkins and Hudson. I disagree that the former is worthless without the latter.

Since the fork, the two communities have been doing their own thing. I don't believe that in order for us to be able to spend resources on improving Hudson we have to reunite with Jenkins. No one is putting the same requirements on them. We have thousands of users who are relying on us to improve and support Hudson. I think it is our responsibility to do that for them.

I do think that the Eclipse foundation is a good neutral ground if any such reunion were to happen, but again, this proposal is about Hudson. It is not meant for a commentary on Jenkins.

Kaloyan Raev wrote on Wed, 04 May 2011 18:13

Statements like who made the fork and who has the enterprise focus are just pouring fuel in that stupid flame war.


Again, I respectively disagree. I believe this is an important distinction that came out of our talks pre-fork. There are people that like rapid iterations and more free-form processes and there are people that don't. I think that there are different ways to run an open source project and I don't think that is a bad thing. I specifically commented that I think both ways are valid, but I think we need to acknowledge the difference in order to understand the landscape and talk about any possible solution.


Ted, it's hard to talk about Hudson without talking about Jenkins. Trying to ignore Jenkins will not make the product better and will not make the thousands of users happier. By the way, I am one of these users. I use both what's called Hudson and what's called Jenkins. And, damn hell, I don't see any difference. It's true that I am not a Hudson/Jenkins guru and I cannot look into the very details.

Eclipse is a place where projects meet the needs of contributors and adopters with very different needs. As an Eclipse project, the new Eclipse Hudson project should be able to meet the needs for release cycle of all participating members. This is not an easy thing, but the right balance needs to be found. If the different release cycles was the reason for the fork, then here at Eclipse, Oracle will face the same problem.
Re: Hudson Proposal posted [message #670143 is a reply to message #670116] Thu, 12 May 2011 19:42 Go to previous messageGo to next message
Gunnar Wagenknecht is currently offline Gunnar Wagenknecht
Messages: 452
Registered: July 2009
Location: Germany ✈ Vancouver
Senior Member

Am 12.05.2011 19:32, schrieb Kaloyan Raev:
> I know that the above words are extremely speculative. But
> there are people that actually think like this. And this
> reflects to the reputation and trust of the Eclipse
> Foundation and the Eclipse community.

It's ok for people to think and read what they want to think and read.
However, if they make judgments based on those speculative thoughts and
reflect those judgments to a larger group of people than IMHO it's
really their fault.

Frankly, it's ok to blame Oracle/Sun for the fork to happen. They really
screwed up there. But words like Eclipse and weapon in one sentence in
this context are just crazy talk.

> I just wanted to say that I see no benefit of having the
> Hudson project at Eclipse, if this does not involve the
> Jenkins community adequately.

Well, the EDP is very precise about openness and community. Having
Hudson at Eclipse requires every single Hudson committer and project
lead to follow this process. I consider this a big benefit for any
project coming to Eclipse.

-Gunnar

--
Gunnar Wagenknecht
gunnar@wagenknecht.org
http://wagenknecht.org/
Re: Hudson Proposal posted [message #670803 is a reply to message #670124] Sun, 15 May 2011 16:25 Go to previous messageGo to next message
Ted Farrell is currently offline Ted Farrell
Messages: 4
Registered: May 2011
Junior Member
Kaloyan,

Kaloyan Raev wrote on Thu, 12 May 2011 13:45
Ted, it's hard to talk about Hudson without talking about Jenkins. Trying to ignore Jenkins will not make the product better and will not make the thousands of users happier. By the way, I am one of these users. I use both what's called Hudson and what's called Jenkins. And, damn hell, I don't see any difference. It's true that I am not a Hudson/Jenkins guru and I cannot look into the very details.

Things may look similar between Hudson and Jenkins now, but I think you will start to see more and more changes between them moving forward. If you look closely it has already started. You don't have to look any further than the Jenkins wiki where the core community is talking about what they want for the Jenkins project if it moved to an open source foundation:

Jenkins Hudson Reconsiliation Requirements - wiki.jenkins-ci.org/display/JENKINS/Jenkins+Hudson+Reconcili ation+Requirements
Retention of Jenkins' development style and process (liberal distribution of commit bits). Not using the eclipse process; encouragement of 3rd party contributions, wherever they come from.

This is very different than what Oracle, Sonatype and some others have been talking about for Hudson. We want a formal development style like Eclipse. We want things in a friendly license like EPL. We want to make sure that people can't bring in any third-party library and taint the project for redistribution.

I think there are people like yourself who are still on the fence about using Hudson or Jenkins and are looking for the differences that you currently don't see. I think you will start to see more of them from both camps and that will make it easier for you to decide on which is right for you. I think both will be valid choices depending on what you are looking for, but the core of each project has declared very different things for what they want from their project. I don't think it benefits anyone to try and force a reunion of two opposing forces.

The fork didn't happen because of a simple IP issue. Mistakes were made on both sides, but even if they hadn't happened the fork probably would have still occurred. The goals and desires of each of the projects is very different. If KK still worked for Sun/Oracle, we would be making the types of changes that I have been talking about to make Hudson more open and enterprise-friendly. He decided to leave and go a different direction, and that's fine.

Kaloyan Raev wrote on Thu, 12 May 2011 13:45
Eclipse is a place where projects meet the needs of contributors and adopters with very different needs. As an Eclipse project, the new Eclipse Hudson project should be able to meet the needs for release cycle of all participating members. This is not an easy thing, but the right balance needs to be found. If the different release cycles was the reason for the fork, then here at Eclipse, Oracle will face the same problem.

I think this is true within reason. Eclipse does encourage diversity, but not to a point of breaking. If we are talking about reasonable compromises then all is good, but if that was the case I don't think we would have forked in the first place. The style, direction and (to quote KK) DNA, of the two projects are very different. While this makes it harder on plugin developers (who we are working with to try to help that), I think it gives everyone else more choice of what's right for them.

We are open to a reconciliation between Hudson and Jenkins, as well as having discussions with anyone who wants to join. We picked Eclipse because of its attributes around formal process, governance and quality. I don't think one of the requirements should ask us to abandon those goals. That said, I think there is room for compromise.


Re: Hudson Proposal posted [message #671857 is a reply to message #668236] Thu, 19 May 2011 07:48 Go to previous messageGo to next message
Aaron Digulla is currently offline Aaron Digulla
Messages: 258
Registered: July 2009
Location: Switzerland
Senior Member
I vote for rejecting the project Hudson for these reasons:

It would make the current state (two projects) permanent for the only reason to have a "enterprise CI solution."

As an "enterprise" user of Jenkins, I'm not sure how Jenkins isn't "enterprise" (or whatever that might mean for everyone).

Currently, the Jenkins projects is alive and kicking and works well. The only advantage of Hudson is that Sonatype has started to rework the core for DI using Guice.

This code would make perfect sense in Jenkins.

OTOH, the Jenkins folks are not going to distribute their work under the EPL. They want a more open MIT-like license (see here) plus the code probably doesn't have a very clean IP trail.

If Eclipse accepted Hudson, there would be little incentive to merge the DI code back into Jenkins: Sonatype has less reason to invest their time twice if they can use the time to bring Hudson forward. Especially if everyone involved with Hudson needs all the time they can get to reimplement the (L)GPL parts (see "Legal Issues" here)

For the same reason, Hudson isn't going to become usable for the next 12 months: All the (L)GPL parts must be reimplemented at eclipse.org to be able to license them under EPL.

The Jenkins people are happy as it is. They couldn't care less about Hudson: They have a working, stable, active, successful product right now. If you look at the time after the fork, Jenkins released once per week, as before. Hudson had just one release. That's 13:1.

On top of that, joining Hudson would mean a loss of face for them. The reverse is true for everyone involved in Hudson. But there is a difference: The people behind Hudson are working for companies which have a stake in Hudson. So they get money to swallow their pride while the Jenkins people seem to be mostly OSS developers. I don't feel like it will work to persuade them to come back to Hudson.

My conclusion: From a technical and social point of view, this proposal makes my heart bleed. It seems like a huge waste of time and effort for little gain.

Now if Eclipse would reject Hudson, what are the options? Could Hudson survive? Sure, but it would be an even bigger effort. Pressure to merge Hudson into Jenkins would be bigger.

So for the sake of both projects, I feel it would be better to reject Hudson.
Re: Hudson Proposal posted [message #671907 is a reply to message #671857] Thu, 19 May 2011 10:28 Go to previous messageGo to next message
Darren Bell is currently offline Darren Bell
Messages: 3
Registered: July 2009
Junior Member
I absolutely agree with Aaron. By rejecting this proposal would ensure the faster unification of both projects. By letting Hudson die gracefully everyone involved would start committing to Jenkins and we all win.

By Oracle moving Hudson to Eclipse, I believe they are still going to try and steer it in the direction they want it to go.

We moved over to Jenkins as soon as it became viable and have not looked back.
Re: Hudson Proposal posted [message #672136 is a reply to message #671857] Fri, 20 May 2011 02:42 Go to previous messageGo to next message
Stuart Mcculloch is currently offline Stuart Mcculloch
Messages: 19
Registered: July 2009
Junior Member
Aaron Digulla wrote on Thu, 19 May 2011 03:48
The only advantage of Hudson is that Sonatype has started to rework the core for DI using Guice.


We've also improved the Maven3 support in free-style builds, and worked on GWT and REST integration.

Aaron Digulla wrote on Thu, 19 May 2011 03:48
This code would make perfect sense in Jenkins. [...snip...] If Eclipse accepted Hudson, there would be little incentive to merge the DI code back into Jenkins


All our changes are (or will be very soon) open-source, so afaict there's nothing stopping Jenkins from cherry-picking them from github if they want them. See also the "Allow PluginStrategy implementations complete control over finding components" thread on jenkins-dev, where we previously helped merge some of this code back to maintain compatibility.

Aaron Digulla wrote
Especially if everyone involved with Hudson needs all the time they can get to reimplement the (L)GPL parts (see "Legal Issues" here) For the same reason, Hudson isn't going to become usable for the next 12 months: All the (L)GPL parts must be reimplemented at eclipse.org to be able to license them under EPL.


Where possible we'll be moving (L)GPL parts out into external non-core plugins, which the core won't depend on. This would be a similar situation to the Eclipse IDE - where the core doesn't contain (L)GPL code, but users can install (L)GPL plugins if they wish. I'd be surprised if that took anything like 12 months.

Aaron Digulla wrote
If you look at the time after the fork, Jenkins released once per week, as before. Hudson had just one release. That's 13:1.


I could do the same comparison for overlapping Apache/Eclipse projects (ie. Felix vs Equinox) - or even various Linux distros, but that doesn't mean those projects shouldn't exist Smile FWIW our current policy is to prepare a new release every 6 weeks, and so far we've kept to that schedule.

Aaron Digulla wrote
But there is a difference: The people behind Hudson are working for companies which have a stake in Hudson. So they get money to swallow their pride while the Jenkins people seem to be mostly OSS developers.


I work for Sonatype, but I also spend my spare time helping out on various OSS projects (not all related to what I'm paid for) - so I don't think it's quite as cut and dried as you make out. Most OSS developers are scratching an itch, and often that itch is related to their work. Personally I don't feel that I'm selling my soul/pride for money.

Aaron Digulla wrote
Now if Eclipse would reject Hudson, what are the options? Could Hudson survive? Sure, but it would be an even bigger effort. Pressure to merge Hudson into Jenkins would be bigger. So for the sake of both projects, I feel it would be better to reject Hudson.


Well if Eclipse rejected Hudson (and I really think that would be the wrong decision) then imho it would be critical for Jenkins to find some sort of umbrella/foundation as soon as possible. I really think the project needs the backing of some foundation, and I honestly think Eclipse is the best choice for Hudson/Jenkins.
Re: Hudson Proposal posted [message #672573 is a reply to message #672136] Sat, 21 May 2011 21:10 Go to previous messageGo to next message
Eduardo Pelegri-Llopart is currently offline Eduardo Pelegri-Llopart
Messages: 8
Registered: May 2011
Junior Member
Stuart says...
Quote:
All our changes are (or will be very soon) open-source, so afaict there's nothing stopping Jenkins from cherry-picking them from github if they want them.


I believe that will not be the case after the move to Eclipse, based on the EPL FAQ (www.eclipse.org/legal/eplfaq.php#USEINANOTHER) and assuming that Jenkins continues to use MIT and that Hudson uses only EPL.
Re: Hudson Proposal posted [message #672601 is a reply to message #672573] Sun, 22 May 2011 02:42 Go to previous messageGo to next message
Jason van Zyl is currently offline Jason van Zyl
Messages: 19
Registered: July 2009
Junior Member
Eclipse committers retain copy right so if we wanted to make sure this remained the case, we could sign the Jenkins CLA and the code could be absorbed.
Re: Hudson Proposal posted [message #672611 is a reply to message #672601] Sun, 22 May 2011 04:36 Go to previous messageGo to next message
Eduardo Pelegri-Llopart is currently offline Eduardo Pelegri-Llopart
Messages: 8
Registered: May 2011
Junior Member
Yep, if all the Hudson@Eclipse committers signed the CA and donated their contributions to Jenkins too, it could be made to work.

Re: Hudson Proposal posted [message #673260 is a reply to message #671857] Mon, 23 May 2011 03:41 Go to previous messageGo to next message
Wayne Beaton is currently offline Wayne Beaton
Messages: 501
Registered: July 2009
Senior Member
I cannot recall any proposal garnering so much discussion and stirring
so much emotion. Frankly, this is the first time that anybody has
ever--in my memory--explicitly voted on a project proposal. I thought it
would be valuable for me to take a few minutes out to discuss how this
works at Eclipse.

For starters, there is no provision the Eclipse Development Process [1]
for voting on whether or not a proposal will be accepted. It is the
case, that the opinions expressed by Eclipse committers and the
community are taken into account as part of this process; as is the
responsiveness of the project proposers to questions, criticisms, and
other concerns.

The purpose of the proposal period is to develop community, and for the
"proposers, in conjunction with the destination PMC and the community,
collaborate in public to enhance, refine, and clarify the proposal." I
am very happy that members of the community feel that they can express
their opinions and pose so many thoughtful, and important questions.
Frankly, it is my opinion that the project proposers have been doing a
fantastic job of addressing the all of the issues presented in a timely,
courteous, and professional manner.

The EDP does not explicitly state with whom the decision that a project
proposal has done the right sorts of things to warrant a move to a
creation review. In practical terms, however, that decision is made by
me upon request by the proposers. The creation review provides the
community with one last chance to ask the hard questions before we
declare success and actually create the project, or declare failure and
withdraw the proposal.

For completeness, in section 6.3 the EDP states that the "EMO(ED)
approves or fails the Review based on the public comments, the scope of
the Project, and the Purposes of the Eclipse Foundation as defined in
the Bylaws." EMO(ED) refers to the "subset of the EMO consisting of the
Executive Director and whomever he or she may delegate that specific
approval authority to." In this particular case, authority has been
granted to me.

In the case of the project, I have been watching this communication
channel (and others) carefully. I believe that community concerns are
being adequately addressed, that significant community is developing
around the proposal, and that the contributor community is diverse and
dedicated. I doubt very much that there's anyway possible to make
everybody happy about this proposal but there's no provision in the EDP
to make everybody happy.

Thanks,

Wayne

[1]
http://www.eclipse.org/projects/dev_process/development_process_2010.php#6_2_2_Proposal

On 05/19/2011 03:48 AM, Aaron Digulla wrote:
> I vote for rejecting the project Hudson for these reasons:
Re: Hudson Proposal posted [message #673424 is a reply to message #672136] Mon, 23 May 2011 15:32 Go to previous messageGo to next message
Aaron Digulla is currently offline Aaron Digulla
Messages: 258
Registered: July 2009
Location: Switzerland
Senior Member
Stuart McCulloch wrote on Fri, 20 May 2011 04:42
Aaron Digulla wrote on Thu, 19 May 2011 03:48
The only advantage of Hudson is that Sonatype has started to rework the core for DI using Guice.


We've also improved the Maven3 support in free-style builds, and worked on GWT and REST integration.

That's good. It just doesn't answer my core question: Why?

I think a lot of people are wondering: Why is it so important to create a new project, and divide the resources?

Can't you work with the Jenkins people? Or is Oracle paying you for this? What's the at stake here? Why is it better to have Hudson at Eclipse instead of working directly with the Jenkins team?

Why is a foundation so utterly important? The project does work as it is. What's wrong with Jenkins that there has to be a legal entity backing it?

What does the OSS world gain from this move? How is the world becoming a better place if the fork is set into stone? Isn't this just a bunch of lawyers make a buck?

I think that people are wondering about these questions and Hudson will have a hard time gaining support if you fail to make people understand the reasons for your move.
Reciprocal code sharing [message #673515 is a reply to message #672601] Mon, 23 May 2011 22:48 Go to previous messageGo to next message
Jason van Zyl is currently offline Jason van Zyl
Messages: 19
Registered: July 2009
Junior Member
I think putting a reciprocal agreement in place would make a lot of users more comfortable.
Re: Hudson Proposal posted [message #673519 is a reply to message #673424] Mon, 23 May 2011 23:19 Go to previous messageGo to next message
Stuart Mcculloch is currently offline Stuart Mcculloch
Messages: 19
Registered: July 2009
Junior Member
Aaron Digulla wrote on Mon, 23 May 2011 11:32
Stuart McCulloch wrote on Fri, 20 May 2011 04:42
We've also improved the Maven3 support in free-style builds, and worked on GWT and REST integration.
That's good. It just doesn't answer my core question: Why?

The main reasons why are listed under the "Why Eclipse?" section of the proposal - moving to Eclipse also answers the questions first asked at the start of the year around governance, infrastructure, and trademark/naming.

Aaron Digulla wrote
I think a lot of people are wondering: Why is it so important to create a new project, and divide the resources?

This is not a new project, this is about moving an existing project to Eclipse. As I said before, there are plenty of examples of overlapping OSS projects - sometimes the difference is due to technical choices, sometimes due to governance styles. For example, both Eclipse/Equinox and Apache/Felix are implementations of the same spec (OSGi) - pooling resources could be more efficient, but then you'd lose the variety that comes from different design decisions and different communities. As long as you use (and agree on) standards, people can get the benefit of choice without getting locked into a particular implementation.

Aaron Digulla wrote
Can't you work with the Jenkins people? Or is Oracle paying you for this? What's the at stake here? Why is it better to have Hudson at Eclipse instead of working directly with the Jenkins team?

I work for Sonatype (not Oracle) and the views I'm expressing here happen to be my own personal views. I also subscribe to the idea of meritocracy (you earn responsibility by contributing) so what you contribute matters more than where you happen to work. (off-topic: wouldn't it be great to see something like ohloh stats associated with messages?)

Wrt. merging projects, unfortunately that isn't always possible if it leads to friction, you have to want to work together towards a shared goal. Is there a single governance process that can work for everyone? I'm honestly not sure. What I do know is there's a significant number of people who would like to work together at Eclipse.

Aaron Digulla wrote
Why is a foundation so utterly important? The project does work as it is. What's wrong with Jenkins that there has to be a legal entity backing it?

The Jenkins folks are currently discussing the same questions so we appear to share similar thoughts about the need for a foundation, but (may) differ in the actual choice.

Aaron Digulla wrote
What does the OSS world gain from this move? How is the world becoming a better place if the fork is set into stone? Isn't this just a bunch of lawyers make a buck? I think that people are wondering about these questions and Hudson will have a hard time gaining support if you fail to make people understand the reasons for your move.

Perhaps the users win by having more choice and (healthy) competition.

[Updated on: Tue, 24 May 2011 14:31]

Report message to a moderator

Re: Hudson Proposal posted [message #673562 is a reply to message #673519] Tue, 24 May 2011 06:21 Go to previous messageGo to next message
Markus Kuppe is currently offline Markus Kuppe
Messages: 177
Registered: July 2009
Senior Member
Stuart McCulloch wrote on Mon, 23 May 2011 19:19

This is not a new project, this is about moving an existing project to Eclipse. As I said before, there are plenty of examples of overlapping OSS projects - sometimes the difference is due to technical choices, sometimes due to governance styles. For example, both Eclipse/Equinox and Apache/Felix are implementations of the same spec (OSGi) - pooling resources could be more efficient, but then you'd lose the variety that comes from different design decisions and different communities. As long as you use (and agree on) standards, people can get the benefit of choice without getting locked into a particular implementation.


Is there such a standard/spec that would make sure consumers don't get vendor locked into either Hudson or Jenkins?

Markus
Re: Hudson Proposal posted [message #673718 is a reply to message #673562] Tue, 24 May 2011 14:31 Go to previous messageGo to next message
Stuart Mcculloch is currently offline Stuart Mcculloch
Messages: 19
Registered: July 2009
Junior Member
Markus Alexander Kuppe wrote on Tue, 24 May 2011 02:21
Stuart McCulloch wrote on Mon, 23 May 2011 19:19

This is not a new project, this is about moving an existing project to Eclipse. As I said before, there are plenty of examples of overlapping OSS projects - sometimes the difference is due to technical choices, sometimes due to governance styles. For example, both Eclipse/Equinox and Apache/Felix are implementations of the same spec (OSGi) - pooling resources could be more efficient, but then you'd lose the variety that comes from different design decisions and different communities. As long as you use (and agree on) standards, people can get the benefit of choice without getting locked into a particular implementation.


Is there such a standard/spec that would make sure consumers don't get vendor locked into either Hudson or Jenkins?


Wrt. developers there are some standards, in the form of extension points and other interfaces - but it's not always clear what a plugin can or should depend on in terms of types/methods, the general build model, or behaviour. Hopefully this is something we can document and improve as part of this project. This is also one of the areas where OSGi can help, and we've already started by using the "major.minor.micro" versioning scheme for the main project to try and differentiate between bugfix and feature releases.

We've also been working on improving the test coverage to make sure we retain compatibility with existing plugins, while at the same time introducing standards such as JSR330 (dependency injection) and JSR311 (JAX-RS). The Jenkins folks have also worked on testing plugin compatibility and Henrik Lynggaard wrote a blog on how plugin authors can support both systems.
Re: Hudson Proposal posted [message #673742 is a reply to message #673519] Tue, 24 May 2011 15:29 Go to previous messageGo to next message
Aaron Digulla is currently offline Aaron Digulla
Messages: 258
Registered: July 2009
Location: Switzerland
Senior Member
Stuart McCulloch wrote on Tue, 24 May 2011 01:19
Aaron Digulla wrote on Mon, 23 May 2011 11:32
That's good. It just doesn't answer my core question: Why?

The main reasons why are listed under the "Why Eclipse?" section of the proposal - moving to Eclipse also answers the questions first asked at the start of the year around governance, infrastructure, and trademark/naming.


The linked document says:

Proposal

It is now the desire of the Hudson project to formalize the process and structure of the project to help create a healthy, open environment with well-defined rules, development process and release processes for building a high-quality and reliable continuous integration server.


When I read this, the following questions come to my mind:

Who is "Hudson project"? What's wrong with the current process? Why is it good to make it more formalized? How is the Jenkins environment not healthy and open? What is bad about the current release process? How Jenkins is not a "high-quality and reliable continuous integration server"?

To understand the next lines better: I say "new project" since I don't really see the connections between Hudson and Jenkins. From my technical point of view, the "old" project is Jenkins (nothing changed but the name) and the "new" or forked project is Hudson. So one thing you may want to clear up are questions like: How many people in "new" Hudson have been working on the project before the fork?

I think a lot of people are wondering something along these lines: Oracle/the powers behind the new project Hudson tried to "steal" the code or gain control over the project. That failed. A lot of bad reputation was generated in the process. So Oracle moved away to stop damaging the project further. But that doesn't stop the people behind the fork/"new" Hudson. Instead of considering to merge the work back, they "stubbornly try to seize control of the project" or something like that.

I mean: saying "No problem, we're open, Jenkins can copy any amount of our code" isn't the same as "working together." Working together means to create a common code base with Jenkins to avoid duplicate work and then maybe add extra Plugins for additional functionality.

But what I read here so far makes me think "Okay, they don't want to look bad but they don't want to help Jenkins, either."

And I think I'm not alone in this regard. Maybe the decision that Hudson is "evil" has already been made in the heads of a lot of people and there is not much that can be done about it anymore.

That's why I believe that you must either succeed in convincing the Jenkins people that you're "good". If they "forgive" you, it should be much more simple to communicate "we want to work together." But if Jenkins ignores you, why should anyone care about Hudson?

Sorry, I'm not 100% clear on how to say what I feel. But I think it's so important that you solve this. Otherwise, a lot of effort will be lost.

[Updated on: Tue, 24 May 2011 15:29]

Report message to a moderator

Re: Hudson Proposal posted [message #673796 is a reply to message #673742] Tue, 24 May 2011 19:03 Go to previous messageGo to next message
Wayne Beaton is currently offline Wayne Beaton
Messages: 501
Registered: July 2009
Senior Member
On 05/24/2011 11:29 AM, Aaron Digulla wrote:
> Who is "Hudson project"? What's wrong with the current process? Why is
> it good to make it more formalized? How is the Jenkins environment not
> healthy and open? What is bad about the current release process? How
> Jenkins not a "high-quality and reliable continuous integration server"?

The first thing that comes to mind is IP due diligence. Eclipse has a
well-established formal IP Process. Jenkins does not.

> To understand the next lines better: I say "new project" since I don't
> really see the connections between Hudson and Jenkins. From my technical
> point of view, the "old" project is Jenkins (nothing changed but the
> name) and the "new" or forked project is Hudson. So one thing you may
> want to clear up are questions like: How many people in "new" Hudson
> have been working on the project before the fork?

This is semantics. You see it one way, others see it in other ways. The
project split, both are old. From an Eclipse POV, we really don't care
if it's old or new.

> I think a lot of people are wondering something along these lines:
> Oracle/the powers behind the new project Hudson tried to "steal" the
> code or gain control over the project. That failed. A lot of bad
> reputation was generated in the process. So Oracle moved away to stop
> damaging the project further. But that doesn't stop the people behind
> the fork/"new" Hudson. Instead of considering to merge the work back,
> they "stubbornly try to seize control of the project" or something like
> that.

I'm actually surprised that the IP due diligence issue doesn't come up
more. The Jenkins developers, AFAICT, are pretty willy-nilly when it
comes to tracking contributions or doing IP due diligence of any kind.
This makes it difficult to use the code in commercial products.

I can't speak for what is in the mind of the powers that be at Oracle. I
don't see it as stealing. Everything that is happening is perfectly
valid from a licensing standpoint. This is two different groups with
different priorities pursing different tracks.

> I mean: saying "No problem, we're open, Jenkins can copy any amount of
> our code" isn't the same as "working together." Working together means
> to create a common code base with Jenkins to avoid duplicate work and
> then maybe add extra Plugins for additional functionality.

The Jenkins folks have been approached. Their response was that they'd
love to join us if we just let them do what they want and just not do
any of that silly IP due diligence stuff, host code the code where they
want, not use the Eclipse Bugzilla, push out releases whenever they
want, and just generally not do any of the things that actually define
an Eclipse project. In short, the Jenkins folks don't want to work with us.

> But what I read here so far makes me think "Okay, they don't want to
> look bad but they don't want to help Jenkins, either."

Again, I don't know what's in the heads of the powers that be at Oracle.
I can't believe that it's anything along the lines of "let's spend a
bunch of money because we want to make the Jenkins people miserable".
More so for the other parties bringing resources to this project.

> And I think I'm not alone in this regard. Maybe the decision that Hudson
> is "evil" has already been made in the heads of a lot of people and
> there is not much that can be done about it anymore.

Some people will never be convinced. It's unfortunate that we all can't
just get along. There is no reason for hostility between Hudson and
Jenkins. Both projects will chug along at whatever speed they chug along
at. The community will ultimately decide what happens. One may win. Both
may win. Both may lose.

> That's why I believe that you must either succeed in convincing the
> Jenkins people that you're "good". If they "forgive" you, it should be
> much more simple to communicate "we want to work together." But if
> Jenkins ignores you, why should anyone care about Hudson?

IMHO, we've collectively done a lot in the effort already. The part
about "Jenkins ignores you, why should anyone care about Hudson?"
doesn't track for me. Large portions of the NetBeans community really
tries to pretend that they ignores us, but lots of people still care
about Eclipse. Both projects can exist. Maybe time will heal old wounds.

Forgiveness is not required from an Eclipse Development Process POV.

> Sorry, I'm not 100% clear on how to say what I feel. But I think it's so
> important that you solve this. Otherwise, a lot of effort will be lost.

I'm glad that you're asking these questions. But, I don't see these
communities joining forces any time soon. Again, maybe time will heal
old wounds. In the meantime, progress must be made and the Hudson
faithful have decided that progress requires a move to Eclipse.

I wish that all Eclipse committers were happy about this. I don't
reasonably expect that, however.

Wayne
Re: Hudson Proposal posted [message #673811 is a reply to message #668236] Tue, 24 May 2011 20:10 Go to previous messageGo to next message
Andrew Bayer is currently offline Andrew Bayer
Messages: 1
Registered: May 2011
Junior Member
Just a couple quick comments, coming from a Jenkins person:

- It is true that the Jenkins community is not particularly keen on Eclipse as a possible home for the project - see wiki.jenkins-ci.org/display/JENKINS/Possible+Jenkins+Umbrella+Foundations for discussions, comments, etc on the various possible umbrella organizations we're looking at. This does not mean that the community as a whole rejects things like the IP issues, etc - we're just working out what the right solutions are for our requirements. That probably won't be Eclipse, which is not commentary on Eclipse, obviously - it's just different needs and interests dictating different results.

- The question of whether Jenkins is interested in going to Eclipse is, to a real extent, a separate question from that of whether Jenkins and Hudson can reconcile - we've had discussions on that as well, at wiki.jenkins-ci.org/display/JENKINS/Jenkins+Hudson+Reconciliation+Requirements, and I'll be summarizing those discussions in an attempt to come up with a coherent sense of what the Jenkins community is looking for in order to make a reunion work. We'd love to get a sense of what the Hudson people would be looking for as well, but haven't heard anything.

(fyi - the links are not actually links because the forum wouldn't let me post with links until I've made 5 posts. *shrug*)

A.
Re: Hudson Proposal posted [message #673848 is a reply to message #673742] Tue, 24 May 2011 23:39 Go to previous messageGo to next message
Stuart Mcculloch is currently offline Stuart Mcculloch
Messages: 19
Registered: July 2009
Junior Member
Aaron Digulla wrote on Tue, 24 May 2011 11:29
The linked document says:

Proposal
It is now the desire of the Hudson project to formalize the process and structure of the project to help create a healthy, open environment with well-defined rules, development process and release processes for building a high-quality and reliable continuous integration server.


When I read this, the following questions come to my mind:

Who is "Hudson project"?

The Hudson project is described in the same proposal and you can find more about it here. It has a codebase, committers, mailing lists, users, etc. Sure, there are projects that are larger, projects that are smaller, projects that cover the same area - but you can't dispute that there is a project called Hudson.

Aaron Digulla wrote
What's wrong with the current process? Why is it good to make it more formalized? How is the Jenkins environment not healthy and open? What is bad about the current release process? How Jenkins is not a "high-quality and reliable continuous integration server"?

The quote from the proposal doesn't say anything about Jenkins, it merely states the goals of the Hudson project in moving to Eclipse. We believe that such a move would lead to a healthy and open environment and the Eclipse development process would help us build a high-quality and reliable CI server. This doesn't mean that this is the only route to building high-quality and reliable CI servers, it's just the route that we would like to take.

Aaron Digulla wrote
To understand the next lines better: I say "new project" since I don't really see the connections between Hudson and Jenkins. From my technical point of view, the "old" project is Jenkins (nothing changed but the name) and the "new" or forked project is Hudson. So one thing you may want to clear up are questions like: How many people in "new" Hudson have been working on the project before the fork?

Some committers have been working on this code for a while, some have been working indirectly on branches or have made significant recent contributions (note not all contributions are code related, some contributed to docs/testing). Personally I view meritocracy based on effort and contributions, not necessarily "time served".

Aaron Digulla wrote
I think a lot of people are wondering something along these lines: Oracle/the powers behind the new project Hudson tried to "steal" the code or gain control over the project. That failed. A lot of bad reputation was generated in the process. So Oracle moved away to stop damaging the project further. But that doesn't stop the people behind the fork/"new" Hudson. Instead of considering to merge the work back, they "stubbornly try to seize control of the project" or something like that.

Let's look at this from an open-source perspective - here we have a group of developers that want to work together on a codebase (Hudson), and that codebase has a license that allows this. They have a preferred place to do this work (Eclipse), and can meet the requirements of that place. They are not stopping other groups from working on the same/similar code. Now it seems like another group comes along and says "no" - you must follow our process, and only our group can work on this code or make releases of this code. Ironically, wasn't that the perception that led to the split in the first place?

Aaron Digulla wrote
I mean: saying "No problem, we're open, Jenkins can copy any amount of our code" isn't the same as "working together." Working together means to create a common code base with Jenkins to avoid duplicate work and then maybe add extra Plugins for additional functionality.

Working together can be good - but competition can be good as well, especially when it spurs people to really listen to what users want. As Andrew mentioned in his reply below, the Jenkins folks have been discussing what it would take to merge the projects back together - looking at the suggested items, it may just be the case that there truly are two different perspectives regarding IP, governance, etc. and trying to force the two groups together just won't work and would actually hinder progress.

But is duplication necessarily a bad thing? The software world is full of repeated work - many desktops share the same underlying code, but cater to different users needs. Don't get me wrong, I'd be happy if Jenkins wanted to join us at Eclipse - but if they don't then that's fine as well. I'm definitely not going to tell them what to do or what process they must follow. All I ask is that we're allowed to choose our own process.

Aaron Digulla wrote
But what I read here so far makes me think "Okay, they don't want to look bad but they don't want to help Jenkins, either." And I think I'm not alone in this regard. Maybe the decision that Hudson is "evil" has already been made in the heads of a lot of people and there is not much that can be done about it anymore. That's why I believe that you must either succeed in convincing the Jenkins people that you're "good". If they "forgive" you, it should be much more simple to communicate "we want to work together." But if Jenkins ignores you, why should anyone care about Hudson? Sorry, I'm not 100% clear on how to say what I feel. But I think it's so important that you solve this. Otherwise, a lot of effort will be lost.

Or in other words, "you can't please all of the people all of the time".

[Updated on: Wed, 25 May 2011 01:02]

Report message to a moderator

Re: Hudson Proposal posted [message #674285 is a reply to message #673848] Thu, 26 May 2011 12:11 Go to previous messageGo to next message
Aaron Digulla is currently offline Aaron Digulla
Messages: 258
Registered: July 2009
Location: Switzerland
Senior Member
Stuart McCulloch wrote on Wed, 25 May 2011 01:39
Or in other words, "you can't please all of the people all of the time".

Careful with that. It can mean "why even try" or "we tried but not too hard in case we might succeed" or "we tried and it didn't work so we give up"

From what I've read so far, I'm not 100% convinced what you mean.
Re: Hudson Proposal posted [message #674387 is a reply to message #674285] Thu, 26 May 2011 18:03 Go to previous messageGo to next message
Stuart Mcculloch is currently offline Stuart Mcculloch
Messages: 19
Registered: July 2009
Junior Member
Aaron Digulla wrote on Thu, 26 May 2011 08:11
Stuart McCulloch wrote on Wed, 25 May 2011 01:39
Or in other words, "you can't please all of the people all of the time".

Careful with that. It can mean "why even try" or "we tried but not too hard in case we might succeed" or "we tried and it didn't work so we give up"

Really? I never associated any of those meanings with that quote, but then I usually take a positive view of things.

Aaron Digulla wrote
From what I've read so far, I'm not 100% convinced what you mean.

I think you'll need to provide more concrete questions, as I really don't now how to make the proposal any clearer.
Re: Hudson Proposal posted [message #674504 is a reply to message #673796] Fri, 27 May 2011 07:26 Go to previous messageGo to next message
Sacha Labourey is currently offline Sacha Labourey
Messages: 1
Registered: May 2011
Junior Member
Quote:

On 05/24/2011 11:29 AM, Aaron Digulla wrote:
> Who is "Hudson project"? What's wrong with the current process? Why is
> it good to make it more formalized? How is the Jenkins environment not
> healthy and open? What is bad about the current release process? How
> Jenkins not a "high-quality and reliable continuous integration server"?

The first thing that comes to mind is IP due diligence. Eclipse has a
well-established formal IP Process. Jenkins does not.


Wayne,

I've seen this IP topic flourish a few times on this thread and since I am convinced you are not interested in spreading FUD, I'd like to get a few things straight:

- There are no perfect ways to manage IP: all processes are here to statistically reduce that risk, but no process will ever provide an absolute barrier to IP issues - this is obviously also true of the Eclipse process.

- As such, nobody could argue that projects covered by an Eclipse process are IP-kosher while those without a similar process are not. Linux has a very different "process" for example and it doesn't seem to impact its adoption much.

- Some people sometimes referred to "IP issues" with the Jenkins codebase. Each time I looked at those they were NOT IP issues at all. Those were either:

a) false positives in the form of libraries licensed under several possible licenses and where the most viral license (GPL) had been used to raise an issue when alternative licenses were available (CDDL, LGPL, etc.),

b) Personal license preferences i.e. some companies have IP policies restricting usage of some licenses, such as LGPL or CDDL. Fine, their call. But this does NOT imply anything wrong with regard to those license or software. I don't think anybody would argue that Glassfish or JBoss are not "clean".


Now, if you or anybody have specific IP claims they'd like to raise against Jenkins, you are invited to do so, I am sure the Jenkins community would take them very seriously.

On the other hand, if this is just your preference with regard to a specific IP process, I am not going to argue about this.

Cheers,


Sacha Labourey
- CloudBees



Re: Hudson Proposal posted [message #674611 is a reply to message #674504] Fri, 27 May 2011 14:32 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26137
Registered: July 2009
Senior Member
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Sacha,<br>
<br>
Comments below.<br>
<br>
Sacha Labourey wrote:
<blockquote cite="mid:irnj6r$kgk$1@news.eclipse.org" type="cite">Quote:
<br>
<blockquote type="cite">On 05/24/2011 11:29 AM, Aaron Digulla wrote:
<br>
&gt; Who is "Hudson project"? What's wrong with the current process?
Why is
<br>
&gt; it good to make it more formalized? How is the Jenkins environment
not
<br>
&gt; healthy and open? What is bad about the current release process?
How
<br>
&gt; Jenkins not a "high-quality and reliable continuous integration
server"?
<br>
<br>
The first thing that comes to mind is IP due diligence. Eclipse has a
<br>
well-established formal IP Process. Jenkins does not.
<br>
</blockquote>
<br>
<br>
Wayne,
<br>
<br>
I've seen this IP topic flourish a few times on this thread and since I
am convinced you are not interested in spreading FUD, I'd like to get a
few things straight:
<br>
<br>
- There are no perfect ways to manage IP: all processes are here to
statistically reduce that risk, but no process will ever provide an
absolute barrier to IP issues - this is obviously also true of the
Eclipse process.
<br>
</blockquote>
The important issue is to use "<a
href="http://en.wikipedia.org/wiki/Due_diligence">due diligence</a>."<br>
<blockquote cite="mid:irnj6r$kgk$1@news.eclipse.org" type="cite"><br>
- As such, nobody could argue that projects covered by an Eclipse
process are IP-kosher while those without a similar process are not. </blockquote>
One can certainly argue that good processes, like those followed at
Eclipse, significantly reduce risk (making those adopting the
technology far more comfortable)  while conversely, when there's little
or no process in place, there is a significantly more risk (making
adopters uncomfortable).<br>
<blockquote cite="mid:irnj6r$kgk$1@news.eclipse.org" type="cite">Linux
has a very different "process" for example and it doesn't seem to
impact its adoption much.
<br>
<br>
- Some people sometimes referred to "IP issues" with the Jenkins
codebase. Each time I looked at those they were NOT IP issues at all.
Those were either: <br>
     a) false positives in the form of libraries licensed under several
possible licenses and where the most viral license (GPL) had been used
to raise an issue when alternative licenses were available (CDDL, LGPL,
etc.), <br>
     b) Personal license preferences i.e. some companies have IP
policies restricting usage of some licenses, such as LGPL or CDDL.
Fine, their call. But this does NOT imply anything wrong with regard to
those license or software. I don't think anybody would argue that
Glassfish or JBoss are not "clean".
<br>
</blockquote>
Is it fair to suggest that these simple issues might have been avoided
with just a bit more due diligence?<br>
<blockquote cite="mid:irnj6r$kgk$1@news.eclipse.org" type="cite"><br>
<br>
Now, if you or anybody have specific IP claims they'd like to raise
against Jenkins, you are invited to do so, I am sure the Jenkins
community would take them very seriously. <br>
</blockquote>
Your issue started as one questioning the value added by Eclipse's IP
process.  The appearance is that you're arguing the value is minimal. 
That's fair enough.  We're all entitled to our opinions.  I have to say
though, I don't think that this thread is the appropriate place to
invite everyone to raise IP claims against Jenkins. This ought not to
turn into a witch hunt.<br>
<blockquote cite="mid:irnj6r$kgk$1@news.eclipse.org" type="cite">On the
other hand, if this is just your preference with regard to a specific
IP process, I am not going to argue about this.
<br>
</blockquote>
The Eclipse IP process was established by a number of large technology
firms, i.e., Eclipse Strategic Members, so that what they consume from
Eclipse conforms as much as possible to the reviews and constraints
their legal staff impose on all the things they consume from any other
open source community.  (As a committer representative, I've been on
the board's IP advisory committee for a number of years.)  So, like it
or not, whatever Jenkins, or anyone else, is producing, it will be
scrutinized in much the way as what you see happening at Eclipse.<br>
<br>
You might look into all the problems Terrence Parr has encountered as a
result of poor pedigree tracking with ANTLR.  Best such problems
avoided before hand rather then fixing them after the fact...<br>
<blockquote cite="mid:irnj6r$kgk$1@news.eclipse.org" type="cite"><br>
Cheers,
<br>
<br>
<br>
Sacha Labourey
<br>
- CloudBees
<br>
<br>
<br>
<br>
<br>
</blockquote>
</body>
</html>
Re: Hudson Proposal posted [message #674659 is a reply to message #674504] Fri, 27 May 2011 18:39 Go to previous messageGo to previous message
Wayne Beaton is currently offline Wayne Beaton
Messages: 501
Registered: July 2009
Senior Member
On 05/27/2011 03:26 AM, Sacha Labourey wrote:
>> The first thing that comes to mind is IP due diligence. Eclipse has a
>> well-established formal IP Process. Jenkins does not.

Sacha,

Is this statement inaccurate? Does Jenkins have an IP due diligence process?

>
> Wayne,
>
> I've seen this IP topic flourish a few times on this thread and since I
> am convinced you are not interested in spreading FUD, I'd like to get a
> few things straight:

Thank you for this acknowledgement. It is most certainly not in my
interest to spread FUD.

> - There are no perfect ways to manage IP: all processes are here to
> statistically reduce that risk, but no process will ever provide an
> absolute barrier to IP issues - this is obviously also true of the
> Eclipse process.

Agreed. It's about mitigation of risk.

> - As such, nobody could argue that projects covered by an Eclipse
> process are IP-kosher while those without a similar process are not.
> Linux has a very different "process" for example and it doesn't seem to
> impact its adoption much.

Agreed. But, as Ed stated, the Eclipse IP due diligence process gives
adopters a high degree of confidence that the code they're basing their
products on contain clean IP.

> - Some people sometimes referred to "IP issues" with the Jenkins
> codebase. Each time I looked at those they were NOT IP issues at all.
> Those were either:
> a) false positives in the form of libraries licensed under several
> possible licenses and where the most viral license (GPL) had been used
> to raise an issue when alternative licenses were available (CDDL, LGPL,
> etc.),
> b) Personal license preferences i.e. some companies have IP
> policies restricting usage of some licenses, such as LGPL or CDDL. Fine,
> their call. But this does NOT imply anything wrong with regard to those
> license or software. I don't think anybody would argue that Glassfish or
> JBoss are not "clean".

Third party libraries are part of the problem. Provenance of code
contributions are another. Does Jenkins have any process in place to
mitigate the risk of code being copied from one source into project
code? In my experience, this is most often an innocent mistake or
misunderstanding by a software developer. Our IP team discovers
instances of this fairly often; it's a source of some frustration for
Eclipse committers when we tell them that they have to yank out some
code and rewrite it.

> Now, if you or anybody have specific IP claims they'd like to raise
> against Jenkins, you are invited to do so, I am sure the Jenkins
> community would take them very seriously.

And there's the difference. At Eclipse we're proactive. It sounds like
Jenkins is reactive. I'm not saying that's wrong (I agree with your
assertion that there are many different ways to do this right); but it's
a clear difference in approach which I think rationalizes my assertion.

> On the other hand, if this is just your preference with regard to a
> specific IP process, I am not going to argue about this.

The IP due diligence process is one of the values/underlying principles
of project life at Eclipse. It is often cited as one of the primary
reasons for bringing projects here.

Wayne
Previous Topic:Hudson Creation Review scheduled for week of June 23-29/2011
Next Topic:Eclipse Hudson project creation declared successful!
Goto Forum:
  


Current Time: Thu Oct 23 06:00:55 GMT 2014

Powered by FUDForum. Page generated in 0.05531 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software