Purpose

Jenkins needs an umbrella foundation of some sort, at a minimum to provide a legal home for the Jenkins trademark/IP, a place to properly handle donations, etc. How much more than that is needed is an open question. This page is intended to provide a venue for discussing the pros and cons of each of the possible homes.

When adding a pro or con, or commenting on existing ones, please make sure to leave your name/username.

Foundations

Foundations are in alphabetical order.

Apache

Pros

Well know and respected ﻿(pablaasmo)

Some companies have not contributed to Jenkins because they believe it is controlled by CloudBees. Apache's integrity will address those concerns.

Gives good freedom to community to decide framework/design etc.(pablaasmo)

real community over code mind (olamy)

trademark and legal help possible (olamy)

MIT license is compatible with ASL. (abayer)

already in place process to sync with maven central repo (olamy : will need only a groupId change)

INFRA in place (jira, wiki, maven repos for snaphots (olamy)

Cons

Release process ? (weekly release will be more complicated due to vote process) (olamy)

The definition of an ASF release (http://www.apache.org/dev/release.html) is something that's publicized outside of the project's developers mailing list, so developer snapshots can be released quickly. A proper release requires a 72-hour vote (bdelacretaz)

The ASF process does not requires a 72-hour vote. It says it "should generally be permitted to run for at least 72 hours to provide an opportunity for all concerned persons to participate regardless of their geographic locations." (http://www.apache.org/foundation/voting.html) (elecharny)

new committer entry (olamy : IHMO not a real issue as the goal is to probably to move only core and bundled plugins)

Adding new committers is not complicated but requires a 72-hour vote and there's a delay for creating new accounts that's currently up to a week (bdelacretaz)

back to svn (AFAIK asf use a central svn repo) (olamy : btw is it a problem ?) (andrew: fwiw, ASF has talked about having a git repo, but no one there has stepped up to get it set up/supported - that may be something we'd be able to help with)

Is this really true? Why could we not continue to run with github? Can someone explain what the infrastructure constraints are? (magnayn)

I can go into more detail on this based on conversations I've had with Doug Cutting - I'll try to get that summed up somewhere. (abayer)

btw we can ask ASF for jenkins first using a git canonical repository hosted @asf (olamy) (@magnayn btw you can use git svn as svn repos are mirrored to git)

git-svn != git. You loose several important capabilities; most importantly you can never merge in git and push back to svn. This is a particular issue when you want to have maintenance branches, and merge back to the development tree. git-svn is useful for situations where you're corporate-locked to SVN, but it's a huge step backwards from git (and github) proper - you might do something in github that's impossible to ever commit back to svn. (magnayn)

Apache project code must be in the ASF's central svn repo, but you can use git to a certain extent, seehttp://git.apache.org- git support might be extended in the future but there are no definite plans at this time as far as I know (bdelacretaz)

My biggest problem with this is it smells like politics (magnayn). Many of us spend enough time in $dayjob fighting IT departments dubious ideas without having them on our side projects. Notably:

There is no such thing as 'canonical' in DVCS terms. I get worried about this requirement as being driven by an infrastructure team demarcation requirement. This solves no problems for Jenkins, and just creates new ones (it's just the same as ORCL deciding when and where the repo can be, not the community). If, however, it could be done such that we proceed as now - where development work is organised around github but the requirement being something like 'the SHA1 of any release must exist in >this< git repository - then that's totally fine.

Compared with ASF, more decisions in Eclipse depend on the Board and the Eclipse Staff. The bylaws are 24 pages (see here and the rest of the Governance Documents). As a specific, possibly infrequent, decision, see this comment from the Foundation on community reactions to the donation (pelegri)

2 Comments

In regards to Shawn's comments, I'll see if I can get him to blog about things now. A lot has improved and a lot of it was learning pains. JGit and EGit have benefited from the eclipse.org ecosystem but attracting a lot of individual and corporate contributions.

I'd like to point out that the Con against Eclipse "EPL is not MIT compatible (magnayn)" is not applicable since the project can be licensed under the EDL (BSD) or dual licensed EPL/EDL

In regards to "The eclipse IP ﻿process makes it very hard for occasional contributors. Many will just give up." If patches are under 250 LOC, there's no problem if the code was submitted via bugzilla, gerrit, mailing list or forums since the user agreed to the Eclipse Terms of Use. If the patch is over 250 LOC, that triggers a more in depth review which will require a short statement for provenance purposes.

In regards to "Compared with ASF, more decisions in Eclipse depend on the Board and the Eclipse Staff" each eclipse.org project is run individually by its committers and project leadership. As long as they adhere to the Eclipse Development Process guidelines, they decide when to release and what they want to do. Eclipse Foundation staff can't tell a project what to do technically.