Jenkins and ASF
Michael Hüttermann
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
Nigel Magnay
On Sunday, February 6, 2011, Michael Hüttermann
Thomas Ferris Nicolaisen
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.
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.
pelegri
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:
nicolas de loof
Andrew Bayer
rgardler
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
rgardler
> Wouldn't that require following ASF release rules, which are a touch archaic?
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
>
> > 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
>
rgardler
> 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.
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).
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
> 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.
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.
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.
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
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
> 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.
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
I already asked for you. See http://markmail.org/thread/xpsgspwozy2aiotv
Ross
rgardler
> 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.
Ross
pelegri
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
Richard Bywater
pelegri
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
>
>
> 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
> 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
Andrew Bayer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQFNT1s00i2bPSHbMcURAgJ2AJ9eo1F/WkUIUnKTKNH6LxPgn4hTkgCgr/uk
mxWY4Y1fAss6VFsn3Gqs5c4=
=6Gxv
-----END PGP SIGNATURE-----
AJones
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
Sent from my mobile device.
Ross Gardler
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
Tim Pizey
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
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.
Ross Gardler
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
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
Andrew Bayer
Martijn Dashorst
- 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
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.
pelegri
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
Martijn Dashorst
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
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
>
> 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
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
Niklas Gustavsson
> 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
pelegri
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
John-Mason P. Shackelford
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
> valid strategy to run Jenkins under the ASF umbrella.
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
> 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
rgardler
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
>
> 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:
>
> > according to the gov meeting minutes [1], it is considered to be a
> > different people, including a couple of guys that are activiley
> > find a collaboration between Jenkins andASF. I think hosting Jenkins
> > as anASFproject would add even more creditability to Jenkins. I
> > think?
>
> > Regards
> > Michael
>