Jenkins and ASF

152 views
Skip to first unread message

Michael Hüttermann

unread,
Feb 6, 2011, 11:40:00 AM2/6/11
to Jenkins Developers
Hello Andrew, hello all,

according to the gov meeting minutes [1], it is considered to be a
valid strategy to run Jenkins under the ASF umbrella. I've sent a
short tweet about that and got a very overwhelming response from many
different people, including a couple of guys that are activiley
involved in the ASF structure. They offered support to check how to
find a collaboration between Jenkins and ASF. I think hosting Jenkins
as an ASF project would add even more creditability to Jenkins. I
don't think existing licenses prevent such a movement. What do you
think?

Regards
Michael


[1] http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-02-04-23.02.html

nicolas de loof

unread,
Feb 6, 2011, 1:34:13 PM2/6/11
to jenkin...@googlegroups.com
Would be a great opportunity for Jenkins, and would solve the  infra / legals issues discussed during meeting.
Apache Extra could be used for plugins that don't use a compatible license.

2011/2/6 Michael Hüttermann <michael.h...@googlemail.com>

Nigel Magnay

unread,
Feb 6, 2011, 2:20:39 PM2/6/11
to jenkin...@googlegroups.com
Wouldn't that require following ASF release rules, which are a touch archaic?

On Sunday, February 6, 2011, Michael Hüttermann

Thomas Ferris Nicolaisen

unread,
Feb 6, 2011, 2:24:17 PM2/6/11
to jenkin...@googlegroups.com
I don't have any opinion on this myself, but it did ring a bell over something I read recently: iBatis moved away from Apache to become MyBatis last year.

I'm not aware of all the reasons they did this, but there was at least one legal implication:
When I donated iBATIS to the ASF, it was unfortunately irreversible. This is due to the fact that Apache is a 501(c)(3) nonprofit organization. They cannot turn over what might be considered "assets" to a private entity.


Shane of Apache commented this on the fork:
ASF projects are expected to follow a number of procedures roughly known as “The Apache Way”. We believe that software projects with a diverse community; that use a consensus process to make decisions; and that do all their work in the open results in the best overall quality and longest lasting projects. While the ASF expects it’s projects to follow the Apache Way, we certainly understand that not everyone believes that our way of software development is the right one for everyone or for all projects.

I don't know what's been going on behind the curtains there, but it's certainly important to make sure you're aware of Apache's expectations and constraints before you make the move (well, stating the obivous there).

pelegri

unread,
Feb 6, 2011, 2:53:02 PM2/6/11
to Jenkins Developers
I have mixed feelings about "the Apache way". It can work very well,
but it can also lead to internal fights, paralysis, conflicting
agendas. In particular Sun - where I was - was a founding member of
Tomcat but eventually felt it had to go its own way because of some of
these problems. And when we designed the GlassFish governance, we
chose a "(Corporate) benevolent dictatorship" model - which has its
own problems.

But, in any case, I don't see how Jenkins can be an Apache project.
Apache projects require IP to be contributed, and the bulk of the pre-
Jenkins IP is (c) Oracle, so we can't contribute it.

There is Apache-Extras at Google, but these are not really ASF
projects. As far as I understand the arrangement, there is no formal
relationshp between any project at Apache-Extras and ASF and it would
not really address any of our issues.

http://code.google.com/a/apache-extras.org/p/apache-extras/wiki/FAQ

Eduard/o

On Feb 6, 11:24 am, Thomas Ferris Nicolaisen <tfn...@gmail.com> wrote:
> I don't have any opinion on this myself, but it did ring a bell over
> something I read recently: iBatis moved away from Apache to become MyBatis
> last year.
>
> I'm not aware of all the reasons they did this, but there was at least one
> legal implication:
>
> When I donated iBATIS to the ASF, it was unfortunately irreversible. This is
> due to the fact that Apache is a 501(c)(3) nonprofit organization. They
> cannot turn over what might be considered "assets" to a private entity.
>
> Source:
> <http://mail-archives.apache.org/mod_mbox/ibatis-user-java/201005.mbox/%3CAANLkTilKGrPRn48gAhCWkdrLWQFGkXOkjbjHYVjsW...@mail.gmail.com%3E>

nicolas de loof

unread,
Feb 6, 2011, 3:31:43 PM2/6/11
to jenkin...@googlegroups.com
Regarding the "Apache way", I've noticed from Apache Maven & Apache commons where I contributed that only the PMC is responsible for project governance (nut is encouraged to get other contributors/committers involved), based on a consensus (the famous +1 / -1 votes). PMC can be limited in size, so it may be constituted on historical leadership on Hudson project and be similar to a 3-heads benevolent dictator model.

The main issue is not the "Apache way", that may fail only when the community has other governance/leadership issues, but (as you notice) the strict Apache IP rules. I don't know well the incubator requirements at apache to get a project donated to the foundation, but this may fail with Oracle copyright on code ( http://incubator.apache.org/ip-clearance/index.html ) even if I thing the MIT license is safe enough in such case. Maybe we could ask leg...@apache.org

Nicolas

2011/2/6 pelegri <pel...@calterra.com>

Andrew Bayer

unread,
Feb 6, 2011, 3:37:50 PM2/6/11
to jenkin...@googlegroups.com
FWIW, I've taken advantage of my employer also employing Doug Cutting, ASF chair, and have emailed him to see what if any options are available for a Jenkins/Apache relationship. I'll let you all know how that goes.

A.

rgardler

unread,
Feb 6, 2011, 6:19:40 PM2/6/11
to Jenkins Developers
Just an intro of myself...

I'm not a developer on Jenkins (or Hudson) and have never even read a
mail on your lists prior to this one. Therefore I have no opinion
about whether you should/should not enter the ASF.

I've joined this thread in order to help you understand what it means
from the ASF side of things. I'm active in the incubator and in a few
other things at the ASF.

Please note I'm not subscribed to this list with one of my primary
emails so I may be slow in responding. If you have something specific
you want me to respond to copy just ping me at rgardler....apache.org
and I'll be sure to come back and review the thread.

I'll respond to a couple of points elsewhere in this thread now.

Ross

On Feb 6, 4:40 pm, Michael Hüttermann
> [1]http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-02-04-23.02....

rgardler

unread,
Feb 6, 2011, 6:23:43 PM2/6/11
to Jenkins Developers
On Feb 6, 7:20 pm, Nigel Magnay <nigel.mag...@gmail.com> wrote:
> Wouldn't that require following ASF release rules, which are a touch archaic?

It depends how you define "archaic". If you mean sufficiently robust
to ensure that big corporation lawyers will allow Apache code to be
used in their products then yes, then no they are not "archaic" they
are "robust".

If you mean some people don't like them, then yes you are right.

Either way, all ASF projects must adhere to our release rules, it is
one of the very few things that are non-negotiable in the ASF. There
is more on this and a few other fixed rules at
https://blogs.apache.org/comdev/entry/what_makes_apache_projects_different

Ross


>
> On Sunday, February 6, 2011, Michael Hüttermann
>
> <michael.huetterm...@googlemail.com> wrote:
> > Hello Andrew, hello all,
>
> > according to the gov meeting minutes [1], it is considered to be a
> > valid strategy to run Jenkins under the ASF umbrella. I've sent a
> > short tweet about that and got a very overwhelming response from many
> > different people, including a couple of guys that are activiley
> > involved in the ASF structure. They offered support to check how to
> > find a collaboration between Jenkins and ASF. I think hosting Jenkins
> > as an ASF project would add even more creditability to Jenkins. I
> > don't think existing licenses prevent such a movement. What do you
> > think?
>
> > Regards
> > Michael
>
> > [1]http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-02-04-23.02....

rgardler

unread,
Feb 6, 2011, 6:33:11 PM2/6/11
to Jenkins Developers
On Feb 6, 7:24 pm, Thomas Ferris Nicolaisen <tfn...@gmail.com> wrote:
> I don't have any opinion on this myself, but it did ring a bell over
> something I read recently: iBatis moved away from Apache to become MyBatis
> last year.
>
> I'm not aware of all the reasons they did this, but there was at least one
> legal implication:
>
> When I donated iBATIS to the ASF, it was unfortunately irreversible. This is
> due to the fact that Apache is a 501(c)(3) nonprofit organization. They
> cannot turn over what might be considered "assets" to a private entity.

To be clear, this applies to the Trademark, not to the code. The code
is under an Apache License which is sufficiently permissive that you
can do whatever you want with it outside of the foundation (although
you still have to abide by the Apache Licence itself).

> Source:
> <http://mail-archives.apache.org/mod_mbox/ibatis-user-java/201005.mbox/%3CAANLkTilKGrPRn48gAhCWkdrLWQFGkXOkjbjHYVjsW...@mail.gmail.com%3E>
>
> Shane of Apache commented this on the fork:
>
> ASF projects are expected to follow a number of procedures roughly known as
> “The Apache Way”. We believe that software projects with a diverse
> community; that use a consensus process to make decisions; and that do all
> their work in the open results in the best overall quality and longest
> lasting projects. While the ASF expects it’s projects to follow the Apache
> Way, we certainly understand that not everyone believes that our way of
> software development is the right one for everyone or for all projects.
>
> Source: <http://communityovercode.com/2010/06/mybatis-forks-apache-ibatis/>
>
> I don't know what's been going on behind the curtains there, but it's
> certainly important to make sure you're aware of Apache's expectations and
> constraints before you make the move (well, stating the obivous there).

There's nothing behind the curtains. The iBatis project team didn't
like the way the ASF ran things and decided to go their own way.

I do agree that it is important that you understand what the ASF is
about. There are few rules that we insist upon, but those few rules
are not to everyones liking.

Ross

rgardler

unread,
Feb 6, 2011, 6:55:25 PM2/6/11
to Jenkins Developers
On Feb 6, 7:53 pm, pelegri <pele...@calterra.com> wrote:
> I have mixed feelings about "the Apache way".  It can work very well,
> but it can also lead to internal fights, paralysis, conflicting
> agendas.  In particular Sun - where I was - was a founding member of
> Tomcat but eventually felt it had to go its own way because of some of
> these problems.  And when we designed the GlassFish governance, we
> chose a "(Corporate) benevolent dictatorship" model - which has its
> own problems.

A well run community does not have "internal fights, paralysis
conflicting agendas". Internal fights are a symptom of a lack of
respect or understanding between opposing views. This can occur in any
community that is not well run. It is not a symptom of the Apache Way.
Paralysis is extremely rare in the ASF due to the way we make
decisions. It can happen in extreme cases, but in those cases I would
argue the same as for "internal fights". Conflicting Agendas are a
fact of life, and again not caused by the Apache Way. The question is
does the Apache Way provide a means to resolve those conflicts, again
I refer to my first two points.

Sometimes conflicts are not resolvable, at this point a fork is
created - that's what open source is all about (err.... hello Hudson,
oh sorry Jenkins).

Like most well run open source projects forks of ASF code are unusual,
but they do occasionally occur.

As Eduardo points out no governance model is perfeect. There are some
good documents (well, I wrote them so I think they are good) on
governance models at:

http://www.oss-watch.ac.uk/resources/governanceModels.xml
http://www.oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel.xml
http://www.oss-watch.ac.uk/resources/meritocraticGovernanceModel.xml

Note that a well run benevolent dictatorship is actually very similar
to a well run meritocratic model. Some of the processes are different
(in particular conflict resolution) but community engagement and
collaboration models are almost identical.

> But, in any case, I don't see how Jenkins can be an Apache project.
> Apache projects require IP to be contributed, and the bulk of the pre-
> Jenkins IP is (c) Oracle, so we can't contribute it.

No, this is not correct. The ASF does not require copyrights. What we
do require though is a copyright license. If Oracle are not prepared
to give us that licence via our standard Contributor Licence Agreement
we would have to work with out legal team to figure out how this could
be done. As I understand it the code is MIT licensed, this is
compatible with the Apache Licence.

However, this does not mean that we would be able to move the code
over. I've asked out legal list for their thoughts:
http://markmail.org/thread/xpsgspwozy2aiotv

> There is Apache-Extras at Google, but these are not really ASF
> projects.  As far as I understand the arrangement, there is no formal
> relationshp between any project at Apache-Extras and ASF and it would
> not really address any of our issues.

This is correct. Apache-Extras is for projects that are related to the
ASF, but not owned by the ASF. It's really intended for things like
plugins for Apache projects that cannot be licenced under the Apache
licence. I don't think you would gain any significant benefit from
being there over being in Google Code itself.

Ross

pelegri

unread,
Feb 6, 2011, 6:56:24 PM2/6/11
to Jenkins Developers
On the trademark issue, my understanding is that the only releases
that can use the ASF-branded name are exactly those from ASF.

That is why, for example, all the vendors that distribute tomcat-based
distributions use a different name for their distributions.

eduard/o

rgardler

unread,
Feb 6, 2011, 7:07:58 PM2/6/11
to Jenkins Developers
On Feb 6, 8:31 pm, nicolas de loof <nicolas.del...@gmail.com> wrote:
> Regarding the "Apache way", I've noticed from Apache Maven & Apache commons
> where I contributed that only the PMC is responsible for project governance
> (nut is encouraged to get other contributors/committers involved), based on
> a consensus (the famous +1 / -1 votes). PMC can be limited in size, so it
> may be constituted on historical leadership on Hudson project and be similar
> to a 3-heads benevolent dictator model.

No we would not allow that. All Apache projects are meritocracies and
must be run as one. Having a hard fix on the number of people able to
become a part of the governance of the project is not meritocratic.
This is another of the invariant rules of the ASF.

Having said that, each project is free to decide where to place the
bar for membership of the PMC. Some projects give it away quickly (a
couple of decent patches for example), others require a significant
amount of time and effort. As long as the rules the project defines
are meritocratic (i.e. there is a way to become a part of the PMC)
then they will be accepted by the board. Note, however, that the
culture of the ASF leans more towards low barriers than high barriers.
Experience has shown us that lower barriers are more effective in
creating viable ASF style communities - of course, I don't mean to
imply that ASF style communities are the only succesful ones.

Projects are also free to choose whether they want to make the
distinction between committer and PMC member. Historically there was
always a split. Over the years many projects (though not all) have
decided that committership == PMC. There are still projects that have
a clear separation between committer and PMC member.

A further area of flexibility is in who makes the decisions. In a
healthy ASF style community decisions are made through a consensus
which is reached through code and (where necessary) discussion.
Conflicts are resolved with a vote. How those votes are counted is up
to the PMC to define (with a few exceptions that have legal
implications).

> The main issue is not the "Apache way", that may fail only when the
> community has other governance/leadership issues, but (as you notice) the
> strict Apache IP rules. I don't know well the incubator requirements at
> apache to get a project donated to the foundation, but this may fail with
> Oracle copyright on code (http://incubator.apache.org/ip-clearance/index.html) even if I thing the
> MIT license is safe enough in such case. Maybe we could ask
> leg...@apache.org

I already asked for you. See http://markmail.org/thread/xpsgspwozy2aiotv

Ross

rgardler

unread,
Feb 6, 2011, 7:15:46 PM2/6/11
to Jenkins Developers
On Feb 6, 11:56 pm, pelegri <pele...@calterra.com> wrote:
> On the trademark issue, my understanding is that the only  releases
> that can use the ASF-branded name are exactly those from ASF.
>
> That is why, for example, all the vendors that distribute tomcat-based
> distributions use a different name for their distributions.

Correct. More at http://www.apache.org/foundation/marks/

Ross

pelegri

unread,
Feb 6, 2011, 7:37:57 PM2/6/11
to jenkin...@googlegroups.com

rgardler wrote:
>
> As Eduardo points out no governance model is perfeect. There are some
> good documents (well, I wrote them so I think they are good) on
> governance models at:
>
> http://www.oss-watch.ac.uk/resources/governanceModels.xml
> http://www.oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel.xml
> http://www.oss-watch.ac.uk/resources/meritocraticGovernanceModel.xml
>

Thanks for the pointers, Ross.


rgardler wrote:
>
>> But, in any case, I don't see how Jenkins can be an Apache project.
>> Apache projects require IP to be contributed, and the bulk of the pre-
>> Jenkins IP is (c) Oracle, so we can't contribute it.
>
> No, this is not correct. The ASF does not require copyrights. What we
> do require though is a copyright license. If Oracle are not prepared
> to give us that licence via our standard Contributor Licence Agreement
> we would have to work with out legal team to figure out how this could
> be done. As I understand it the code is MIT licensed, this is
> compatible with the Apache Licence.
>
> However, this does not mean that we would be able to move the code
> over. I've asked out legal list for their thoughts:
> http://markmail.org/thread/xpsgspwozy2aiotv
>

Thanks!

--
View this message in context: http://jenkins.361315.n4.nabble.com/Jenkins-and-ASF-tp3262928p3263419.html
Sent from the Jenkins dev mailing list archive at Nabble.com.

Andrew Bayer

unread,
Feb 6, 2011, 8:50:08 PM2/6/11
to jenkin...@googlegroups.com
For what it's worth, my only real concern is how to mesh the Apache release policies with Jenkins' rapid iteration of releases - that said, I'm not entirely sure it'd be a bad thing for the release cycle to slow down a bit (not much, but not necessarily a release a week, every week).

A.

Richard Bywater

unread,
Feb 6, 2011, 9:08:18 PM2/6/11
to jenkin...@googlegroups.com
Couldn't the weekly releases be a bit like Release Candidate type releases (well thats probably not the right name but hopefully it makes sense) and then there's a official release at a more irregular interval - that could go towards the issue of a "Stable" release too if done correctly?

Richard.

pelegri

unread,
Feb 6, 2011, 9:11:00 PM2/6/11
to jenkin...@googlegroups.com

rgardler wrote:
>
> On Feb 6, 8:31 pm, nicolas de loof <nicolas.del...@gmail.com> wrote:
>> Regarding the "Apache way", I've noticed from Apache Maven & Apache
>> commons
>> where I contributed that only the PMC is responsible for project
>> governance
>> (nut is encouraged to get other contributors/committers involved), based
>> on
>> a consensus (the famous +1 / -1 votes). PMC can be limited in size, so it
>> may be constituted on historical leadership on Hudson project and be
>> similar
>> to a 3-heads benevolent dictator model.
>
> No we would not allow that. All Apache projects are meritocracies and
> must be run as one. Having a hard fix on the number of people able to
> become a part of the governance of the project is not meritocratic.
> This is another of the invariant rules of the ASF.
>

How flexibly is ASF's definition of "merit"?

I am totally fine with an egalitarian approach to votes, etc. My main
concern with the ASF model - and I might be misrepresenting the model - is
that ASF meritocracy seems to mean just "technical expertise" and I think it
is important to consider how well the team works together.


--
View this message in context: http://jenkins.361315.n4.nabble.com/Jenkins-and-ASF-tp3262928p3263473.html

Jeff Jensen

unread,
Feb 6, 2011, 9:45:42 PM2/6/11
to jenkinsci-dev
On Sun, Feb 6, 2011 at 8:11 PM, pelegri <pel...@calterra.com> wrote:
>
>
> rgardler wrote:
>>
>> On Feb 6, 8:31 pm, nicolas de loof <nicolas.del...@gmail.com> wrote:
>>> Regarding the "Apache way", I've noticed from Apache Maven & Apache
>>> commons
>>> where I contributed that only the PMC is responsible for project
>>> governance
>>> (nut is encouraged to get other contributors/committers involved), based
>>> on
>>> a consensus (the famous +1 / -1 votes). PMC can be limited in size, so it
>>> may be constituted on historical leadership on Hudson project and be
>>> similar
>>> to a 3-heads benevolent dictator model.
>>
>> No we would not allow that. All Apache projects are meritocracies and
>> must be run as one. Having a hard fix on the number of people able to
>> become a part of the governance of the project is not meritocratic.
>> This is another of the invariant rules of the ASF.
>>
>
> How flexibly is ASF's definition of "merit"?

Very. An existing committer "sponsors" you, and the committers vote
+1, 0, -1 to grant you committer status. Any -1 votes mean you don't
receive it.
You don't typically get nominated/sponsored without first proving your
worth one way or another.


> I am totally fine with an egalitarian approach to votes, etc.  My main
> concern with the ASF model - and I might be misrepresenting the model - is
> that ASF meritocracy seems to mean just "technical expertise" and I think it
> is important to consider how well the team works together.

It is not just technical expertise.


I think the biggest issue with moving to Apache is the requirement for
votes to release with a voting period of 72 hours. Continuing a
weekly-ish release could be overcome by staging a release and vote on
every Tues for a Fri release.

The rigor and structure provided by Apache could be very beneficial to
Jenkins. It would also be painful with some of its process
requirements.

Regardless of Apache or not, the key need is the proven release
quality - test coverage, process, infrastructure.

Steve M. Robbins

unread,
Feb 6, 2011, 9:38:44 PM2/6/11
to jenkin...@googlegroups.com
On Sun, Feb 06, 2011 at 05:50:08PM -0800, Andrew Bayer wrote:
> For what it's worth, my only real concern is how to mesh the Apache release
> policies with Jenkins' rapid iteration of releases - that said, I'm not
> entirely sure it'd be a bad thing for the release cycle to slow down a bit
> (not much, but not necessarily a release a week, every week).

Well, reading from the Apache Releases FAQ [1], it is completely
permissible to offer "Test Packages" without a formal approval from
the PMC. One could imagine the weekly build be such a Test Package.

On the other hand: as a user, I'd certainly welcome a slower release
cycle coupled with automated testing and some QA. This should give me
some more assurance that an upgrade would be successful.

[1] http://www.apache.org/dev/release.html

Cheers,
-Steve

signature.asc

Andrew Bayer

unread,
Feb 6, 2011, 11:17:53 PM2/6/11
to jenkin...@googlegroups.com
I tend to agree - there are real benefits from the ultra-rapid release schedule, but I think something more like a monthly release, with more time for release candidates to get tested and the possibility of out-of-schedule releases going out when a critical fix is needed, etc, is probably better overall. 

A.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFNT1s00i2bPSHbMcURAgJ2AJ9eo1F/WkUIUnKTKNH6LxPgn4hTkgCgr/uk
mxWY4Y1fAss6VFsn3Gqs5c4=
=6Gxv
-----END PGP SIGNATURE-----


Message has been deleted

AJones

unread,
Feb 6, 2011, 11:52:33 PM2/6/11
to Jenkins Developers
> View this message in context:http://jenkins.361315.n4.nabble.com/Jenkins-and-ASF-tp3262928p3263473...
> Sent from the Jenkins dev mailing list archive at Nabble.com.

I not a member of any ASF projects, but from my reading and
understanding of what's on the ASF website, the ASF imposes very
little on a project, except of course, the ASF license, and that
projects are run openly and hopefully have a strong community. The
details of everything else is determined by the project's community
and the project's PMC - so the project's community and the project's
PMC determines exactly what "merit" is for that project.

Ross Gardler

unread,
Feb 7, 2011, 3:18:52 AM2/7/11
to jenkin...@googlegroups.com
There is no reason why you can't have, for example, automated nightly builds available. They wouldn't be releases, wouldn't be distributed through the mirrors and wouldn't have press releases. But you can build the binaries. 

However, I'm not sure why the process of a release would be an issue for rapid releases. It's not that onerous. Releases must be signed, tested and approved formally by the PMC. Other than that it's just a matter of building the binaries. 

The bit that some people feel is unnecessary is the proper due diligence on IP in contributions (collection if. CLAs for committees, contributions tracking for non-committees). 

Sent from my mobile device.

Ross Gardler

unread,
Feb 7, 2011, 3:24:16 AM2/7/11
to jenkin...@googlegroups.com
The project itself decides what merit is respected, so it varies.
However, convention is that any positive contribution is valuable and
earns merit.

The PMC decides who is/is not a committee and PMC member. The
community get a say in it.

As long as nobody complains the system is unfair then the board will
not get involved (the board is hands off in all matters except broken
community, and even then only at the request if the community).

Sent from my mobile device.

nicolas de loof

unread,
Feb 7, 2011, 4:33:41 AM2/7/11
to jenkin...@googlegroups.com
Considering Apache Tomcat, they use a rapid release schedule, but later vote to qualify a release (alpha, beta, public) and only publish announcements about public ones. The use don't get a continuous version numbering BUT only get stable releases, where contributors/early-adopters can get the latest code and/or test new features.


2011/2/7 Andrew Bayer <andrew...@gmail.com>

Tim Pizey

unread,
Feb 7, 2011, 6:02:11 AM2/7/11
to jenkin...@googlegroups.com
My anxiety with the ASF model is the possibility of the project
founder being overridden,
this, as I understand it, was the cause of Ceki's departure from log4j,
at base this is the cause of the current rename.

Two possible solutions:
1) Very restricted committer rights on Jenkins core, commiter rights
on plugins does not confer rights on jenkins-core.
2) Voting is weighted by proportion of commits on whole project, so
those with unassailable commit histories dictate direction.

all the best
TimP


--
Tim Pizey
http://pizey.net/~timp

nicolas de loof

unread,
Feb 7, 2011, 6:22:35 AM2/7/11
to jenkin...@googlegroups.com


2011/2/7 Tim Pizey <ti...@paneris.org>

My anxiety with the ASF model is the possibility of the project
founder being overridden,
this, as I understand it, was the cause of Ceki's departure from log4j,
at base this is the cause of the current rename.

Two possible solutions:
1) Very restricted committer rights on Jenkins core, commiter rights
on plugins does not confer rights on jenkins-core.
2) Voting is weighted by proportion of commits on whole project, so
those with unassailable commit histories dictate direction.

AFAIK Ceki's departure was caused by conflicts on backward compatibility vs innovation. Such rules must be clear on the project. Maybe log4j was too "open" to contributors at PMC level ? AFAIK there is no option to weight votes at Apache, anyway the PMC may require a high level of "merit" i.e. only accessible to historical / very active contributors. Jenkins could also have dedicated commit rights for core and plugins - Apache commons do so with commit rights for each module.

Ross Gardler

unread,
Feb 7, 2011, 7:29:30 AM2/7/11
to Jenkins Developers
An ASF collegue of mine, Upyavira, just pointed me to a useful
document he wrote recently "When Apache, when not"

http://www.odoko.co.uk/content/when-apache-when-not

Might be useful for some here.

Ross

Christoph Kutzinski

unread,
Feb 7, 2011, 8:34:50 AM2/7/11
to jenkin...@googlegroups.com
I absolutely agree. IMO the biggest problem with Hudson in the past (and now Jenkins) was that nearly every new release introduced a regression bug.

We need to fix this with a slower release cycle and more regression tests - i.e. a comprehensive test suite.


Christoph

-------- Original-Nachricht --------
> Datum: Sun, 6 Feb 2011 20:17:53 -0800
> Von: Andrew Bayer <andrew...@gmail.com>
> An: jenkin...@googlegroups.com
> Betreff: Re: Jenkins and ASF

dan twining

unread,
Feb 7, 2011, 9:12:16 AM2/7/11
to jenkin...@googlegroups.com
I agree with strong(er) testing. I'm not sure about the slower release cycle - dosn't this mean it just takes longer to find the regression? seems to go against the grain of Aglie / Continuous Delivery.

Andrew Bayer

unread,
Feb 7, 2011, 10:01:39 AM2/7/11
to jenkin...@googlegroups.com
Well, slower than once a week - it's really hard to do much testing when the window between release candidate branch creation and actual release is ~48 hours. I think even something like a two week release cycle - with the release candidate branch cut a week after release X, and actually releasing as release X+1 a week later - would improve things.

A.

Martijn Dashorst

unread,
Feb 7, 2011, 10:04:13 AM2/7/11
to Jenkins Developers
Some additional things to consider:

- all code 'owned' by an Apache project must be hosted on Apache
hardware. Currently only SVN is supported as a SCM, but work is in
progress to support GIT as well. This means that the github
infrastructure is currently out of the question (unless someone
convinces the ASF-board/infra that hosting project code on github is
OK)

- this holds true for most project infrastructure assets (issue
tracker — JIRA is supported and recently upgraded to 4.2.2), wiki
(confluence is supported), official website, mailing lists (migration
of current subscribers is not permitted—subscribers have to subscribe
themselves to the ASF list(s)).

Note that you can try to argue that those assets should remain where
they are, but that most likely everything needs to transfer to ASF
hosted hardware. For example the well established project Subversion
has migrated everything to the ASF, and the subscribers to the users/
dev/etc lists had to re-subscribe (this is a legal requirement—one
can't transfer email addresses from one entity to another without
consent of the owner of the email address).

I would love for jenkins to join the ASF. I think the community and
technology are pretty much ASF compatible, given my observations of
how developers contribute on the lists. That said, jenkins should
really enter the incubator to iron out the ASF requirements (legal
issues, release management policy—of which I read a couple of
interesting proposals here, how to run the project the Apache Way
(whatever that is :-).

Martijn
(who was part of the Wicket team that incubated at Apache as well)

Jerome Lacoste

unread,
Feb 7, 2011, 10:13:55 AM2/7/11
to jenkin...@googlegroups.com


On Monday, February 7, 2011 5:17:53 AM UTC+1, Andrew Bayer wrote:
I tend to agree - there are real benefits from the ultra-rapid release schedule, but I think something more like a monthly release, with more time for release candidates to get tested and the possibility of out-of-schedule releases going out when a critical fix is needed, etc, is probably better overall. 

If we add lots of automated testing and QA, there's no reason why the release cycle should slow down. In fact, properly done, it should go faster.
Think continous deployment. Look at e.g. facebook. 

Whether we want to add Long Supported releases for those for don't fit in the upgrade ASAP group of users is another question.

Cheers,

Jerome

pelegri

unread,
Feb 7, 2011, 10:20:30 AM2/7/11
to jenkin...@googlegroups.com

THanks. This is very enlightening

Eduard/o
--
View this message in context: http://jenkins.361315.n4.nabble.com/Jenkins-and-ASF-tp3262928p3264318.html

nicolas de loof

unread,
Feb 7, 2011, 10:24:32 AM2/7/11
to jenkin...@googlegroups.com
Can we configure Git with a remote on Apache SVN, and just push changes to Apache infra as an "official backup" ?
Having Git hosted at Apache is not a replacement for GitHub, as we will then miss pull request and other features supported by GitHub

2011/2/7 Martijn Dashorst <martijn....@gmail.com>

Martijn Dashorst

unread,
Feb 7, 2011, 10:46:55 AM2/7/11
to Jenkins Developers
Please note that I don't want to stifle the effort to join Apache: I
only want to set expectations that you will have quite a couple of
discussions regarding the infrastructure should you want to join.

On Feb 7, 4:24 pm, nicolas de loof <nicolas.del...@gmail.com> wrote:
> Can we configure Git with a remote on Apache SVN, and just push changes to
> Apache infra as an "official backup" ?
> Having Git hosted at Apache is not a replacement for GitHub, as we will then
> miss pull request and other features supported by GitHub

My guess is that it would be considered cheating: the community should
live on Apache owned hardware.

- Main development should happen on the Apache repository
(albeit the SVN or the newly supported GIT repository).

- Communication between developers of the project should
happen on the dev@ list (not around the water cooler in the
Cloudbees/sonatype/oracle/whatever headquarters): if it is
not on the dev-list it didn't happen.

But before throwing out the baby with the bath water, at least we
should take a look at the plans for git support at Apache. While it
will never be as great as using github—github is a commercial
enterprise with a stake in making it the best git experience—some
features might be implemented at Apache, or integrated with the Apache
git installation.

For example:
* Apache readonly GIT repositories are available at github:
https://github.com/apache/
* pull requests originating from github might be sent to the dev@
list
* perhaps github is willing to donate the "github behind the
firewall" setup to Apache (and infrastructure wants to support it)

I'm not sure about what the jenkins community expects from git at
Apache. This is probably best discussed with the proposal joining the
incubator since the relevant Apache people that are concerned with
infrastructure are not reading this list.

Again, I don't want to stifle the effort to join Apache, I only want
to set expectations that you will have quite a couple of discussions
regarding the infrastructure should you want to join.

Martijn

Christoph Kutzinski

unread,
Feb 7, 2011, 10:55:48 AM2/7/11
to jenkin...@googlegroups.com

>
> If we add lots of automated testing and QA, there's no reason why the
> release cycle should slow down. In fact, properly done, it should go
> faster.
> Think continous deployment. Look at e.g. facebook.

That's a different scenario. Facebook runs it's own platform and can do rollbacks quite easily if anything goes wrong during updates.
We (Jenkins) ship a product to customers and cannot easily (at least in no way I know) rollback the Jenkins installation at a customer when we find that a release is broken.


That being said, WHEN we have a really comprehensive automated test suite, we can switch back to faster release. For the moment - as we rely on manual testing still too much - it would IMO be better to slo down the release cycle.


Christoph

Kohsuke Kawaguchi

unread,
Feb 7, 2011, 1:23:47 PM2/7/11
to jenkin...@googlegroups.com, Andrew Bayer

I think our top priority should continue to be SFC, or SPI, given its
similarity. That's what was in the vote, and I think our reasoning to
choose that is still valid. We already have an established culture in
this project, and we want to be able to keep it --- it's not the matter
of right or wrong, but it's just a matter of what fits us with least
friction.

I also think we should separate the release process discussion from the
umbrella organization discussion. That is something we can and should
adjust on its own.


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

Andrew Bayer

unread,
Feb 7, 2011, 2:31:35 PM2/7/11
to Kohsuke Kawaguchi, jenkin...@googlegroups.com
I agree on the release process matter - I'm a little less sure on the ASF front. I think there's a very good chance we can fit our established culture into ASF fairly easily - for example, plugins wouldn't have to change at all, etc. The positive eagerness of many at ASF to bring Jenkins into the fold is a big deal, I think - we've got ASF courting us, not the other way around. =)

A.

Niklas Gustavsson

unread,
Feb 7, 2011, 3:43:07 PM2/7/11
to jenkin...@googlegroups.com
On Mon, Feb 7, 2011 at 8:31 PM, Andrew Bayer <andrew...@gmail.com> wrote:
> The positive eagerness of many at ASF to bring Jenkins into the
> fold is a big deal, I think - we've got ASF courting us, not the other way
> around. =)

Add another ASF:er to that list of courtiers :-) As the other Apache
people on this thread, I won't try to convince you of going to ASF but
will be happy to help with any questions. Like Ross, I do not have
much experience of the Jenkins community, besides being one of the ASF
Hudson (yeah, we need to change that name) admins.

/niklas

Thomas Ferris Nicolaisen

unread,
Feb 7, 2011, 3:51:58 PM2/7/11
to jenkin...@googlegroups.com
In my experience, keeping an SVN repo in sync as a secondary backup is tricky stuff.

The "push", or rather git-svn dcommit, from git to SVN includes a rewriting of history to add SVN-metadata to the git commits. The git repo needs to retain this metadata in order to continued syncing. There is an option to contain the metadata externally (somewhere inside .git/svn), but it's not recommended, and it would require this data to be rsynced around to those pushing to SVN.

Also, since SVN doesn't really grok proper branches, all history coming in through git-merges would be efficiently lost. There are ways to avoid this using rebasing and/or squashing, but as you probably know, rewriting history in a published repository (on GitHub) doesn't work so well.

(It comes to mind that Eclipse is already hosting projects on Git. Not sure if they do this kind of umbrella'ing though.)

pelegri

unread,
Feb 7, 2011, 3:54:19 PM2/7/11
to jenkin...@googlegroups.com

I had initially assumed that ASF was not an option. After clarifications,
it seems to me a possibility, but I don't know (yet) if it is the best one.

We just left a bad relationship; I suggest we continue to explore that
option, as well as the SFC option, but not rush to a new relationship right
away :)

Eduard/o
--
View this message in context: http://jenkins.361315.n4.nabble.com/Jenkins-and-ASF-tp3262928p3265102.html

Andrew Bayer

unread,
Feb 7, 2011, 3:56:28 PM2/7/11
to jenkin...@googlegroups.com
That's basically where I am - I want to make sure we investigate all our options thoroughly so that we can make the best informed decision possible.

A.

John-Mason P. Shackelford

unread,
Feb 7, 2011, 4:37:05 PM2/7/11
to jenkin...@googlegroups.com
I am not a committer, just lead a team which runs a decent sized
Hudson farm (7 nodes, 500+ jobs) for a FTSE 100 company. I suspect
that if plug-in developers focus support Jenkins, we'll be tracking
the same despite our substantial agreements with Oracle. In general a
move of Jenkins ASF, Eclipse seems positive. In several forums Jason
van Zyl has raised concerns about IP being a blocker in moving toward
one of these umbrellas but I haven't seen anyone suggest here that
they believe IP would be a blocker. Would anyone care to comment
(dispassionately) on the topic, clarify the issues and/or suggest a
way forward?


John-Mason Shackelford

Release Engineering

cactusman

unread,
Feb 7, 2011, 8:32:34 PM2/7/11
to jenkin...@googlegroups.com
> according to the gov meeting minutes [1], it is considered to be a
> valid strategy to run Jenkins under the ASF umbrella.
Really?
Jenkins Project migrated from java.net to github(and etc),
and is having a lot of problems in this matter.
Jenkins Project has also mailing list, repository, BTS, Wiki and etc.
Do you think missing something?
If also Jenkins will run under the ASF umbrella,
What is the benefit?

I don't think so, rather more trouble each.
For the reason, I disagree.

2011/2/7 Michael Hüttermann <michael.h...@googlemail.com>:


> Hello Andrew, hello all,
>
> according to the gov meeting minutes [1], it is considered to be a
> valid strategy to run Jenkins under the ASF umbrella. I've sent a
> short tweet about that and got a very overwhelming response from many
> different people, including a couple of guys that are activiley
> involved in the ASF structure. They offered support to check how to
> find a collaboration between Jenkins and ASF. I think hosting Jenkins
> as an ASF project would add even more creditability to Jenkins. I
> don't think existing licenses prevent such a movement. What do you
> think?
>
> Regards
> Michael
>
>

> [1] http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-02-04-23.02.html

--
cactusman

Martijn Dashorst

unread,
Feb 8, 2011, 3:16:07 AM2/8/11
to jenkin...@googlegroups.com
On Tue, Feb 8, 2011 at 2:32 AM, cactusman <cactus...@gmail.com> wrote:
> Jenkins Project has also mailing list, repository, BTS, Wiki and etc.
> Do you think missing something?
> If also Jenkins will run under the ASF umbrella,
> What is the benefit?

If the idea is to incorporate a Jenkins Foundation, I'd urge folks to
reconsider: it is very hard work to do so. In fact, the Subversion
project dissolved their foundation partly because it is so much work,
while it would be better to focus on writing code.

The ASF provides not just a SCM, JIRA and website. It provides legal
protection, an infrastructure for copyright licensing (CLA's and
software grants), a community model similar to the current jenkins
organization, but already formalized and engrained in the
organization. The ASF has a volunteer legal counsel helping out with
trademark issues, and other open source related litigation. The ASF
has over 10 years of experience running a Foundation. The ASF has
quite a number of high level sponsors providing monetary means to run
quite an infrastructure and as such is not dependent on one company.
The ASF has 10 years of experience letting companies with different
agendas work together on project on a level playing field.

While the ASF's processes and red tape will be considered difficult
and superfluous, it does provide a common ground for parties to work
together without having to pay to play or without having one
company/individual dictate the project.

From the Apache Software Foundation faq:

Why was the Apache Software Foundation created?

The Foundation was formed primarily to

- provide a foundation for open, collaborative software development
projects by supplying hardware, communication, and business
infrastructure;

- create an independent legal entity to which companies and individuals
can donate resources and be assured that those resources will be
used for the public benefit;

- provide a means for individual volunteers to be sheltered from legal
suits directed at the Foundation's projects; and,

- protect the 'Apache' brand, as applied to its software products, from
being abused by other organizations.

So joining the ASF certainly has its merits. The question for the
jenkins community is whether you think if having to abide to a couple
of rules that are currently not in place is worth the organizational
framework you gain by joining the ASF.

In my opinion, if you want to 'compete' with Hudson from Oracle, you
will have to up the game and at least provide a level playing field
for all contributors, proper code provenance and foster a healthy
community. The ASF provides an organizational framework to deliver on
these points.

Martijn

Stephen Connolly

unread,
Feb 12, 2011, 4:04:36 AM2/12/11
to jenkin...@googlegroups.com
Votes do not have to last for 72 hours. It is traditional to give at least 72 hours to allow for time zones, weekends, etc.

You would need at least 3 +1 binding votes to publish the release.

A Jenkins PMC could, IMHO, define its release voting policy as at least 24 hours and three binding +1 votes with automatic extension to 72h if the binding requirement is not met.  Releases cannot be vetoed, so such a short-circuit could probably be approved by the PMC

-Stephen

rgardler

unread,
Mar 4, 2011, 6:18:12 AM3/4/11
to Jenkins Developers
This topic has now died down so I'm unsubscribing from your list. If
you return to this at any point in the future and would like me to
provide any more background on the ASF side of things mail me directly
and I'll rejoin.

However, it seems you have a number of knowledgable ASF folk here
already.

Ross

On Feb 6, 11:19 pm, rgardler <ross.gard...@gmail.com> wrote:
> Just an intro of myself...
>
> I'm not a developer on Jenkins (or Hudson) and have never even read a
> mail on your lists prior to this one. Therefore I have no opinion
> about whether you should/should not enter theASF.
>
> I've joined this thread in order to help you understand what it means
> from theASFside of things. I'm active in the incubator and in a few
> other things at theASF.
>
> Please note I'm not subscribed to this list with one of my primary
> emails so I may be slow in responding. If you have something specific
> you want me to respond to copy just ping me at rgardler....apache.org
> and I'll be sure to come back and review the thread.
>
> I'll respond to a couple of points elsewhere in this thread now.
>
> Ross
>
> On Feb 6, 4:40 pm, Michael Hüttermann
>
> <michael.huetterm...@googlemail.com> wrote:
> > Hello Andrew, hello all,
>
> > according to the gov meeting minutes [1], it is considered to be a
> > valid strategy to run Jenkins under theASFumbrella. I've sent a
> > short tweet about that and got a very overwhelming response from many
> > different people, including a couple of guys that are activiley
> > involved in theASFstructure. They offered support to check how to
> > find a collaboration between Jenkins andASF. I think hosting Jenkins
> > as anASFproject would add even more creditability to Jenkins. I
> > don't think existing licenses prevent such a movement. What do you
> > think?
>
> > Regards
> > Michael
>
> > [1]http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-02-04-23.02....
Reply all
Reply to author
Forward
0 new messages