Re: Opensourcing a plugin under a different github org

[Surya Gaddipati]

Apologize for the late response to this.  Really Appreciate quick responses 
here.  I understand where everyone is coming from, it a tricky issue

>  - you are welcome to put your company logo in the plugin pages, like 
some others do. 
> - you can use the company names in the package names if that helps. 
>- we can highlight you and your plugin on http://jenkins-ci.org/node 
like we did with [1] for [2] 

I like these but the problem is that we are not a tools company so its 
unlikely that new hires would go to jenkins update center/jenkins to learn 
about opensourcing at the company. 

- if you want to mirror the repo in your org, that would help your 
prospective employees to find them more easily. 


This might work. We would still want to accept PR in the original repo 
though, we want stars to be on the original repo too. Is that something 
that would work?


Here is the plugin we are trying to get into update center. 

https://github.com/groupon/DotCi

Surya


On Monday, March 24, 2014 1:04:19 PM UTC-5, Surya Gaddipati wrote:
>
> My employer is interested in opensourcing a plugin that we developed in 
> house. But we would like our plugin to be under github org not jenkins-ci ( 
> for obvious reasons) . 
>
> Is it possible to make plugin  show up in the default jenkins update 
> center?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Jesse Glick]

On Wed, Apr 2, 2014 at 2:15 PM, Jan Ruzicka
 wrote:
> See the repository description [1] in section after " $repoMap of $id => repo 
> ".
> Each line that has slash means different github organization.

A lot of those are in fact forked into jenkinsci. I suspect the map is
just poorly maintained.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Jan Ruzicka]

Hi,

There is quite bit of plugins that are not under Jenkins-ci org under github.
See the repository description [1] in section after " $repoMap of $id => repo ".
Each line that has slash means different github organization.

Jan

[1] 
https://github.com/jenkinsci/backend-jenkins-plugin-changes-plugin/blob/master/RepoInfo.txt



-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Stephen Connolly]

On Tuesday, 1 April 2014, Kohsuke Kawaguchi 
wrote:

> On 03/26/2014 03:06 AM, Nigel Magnay wrote:
>
>>
>> +1.
>> I don't like the idea of having some plugins referenced under the
>> official update center that don't actually come from the jenkinsci
>> github organization.
>> The deal seems quite simple to me: either accept to host your plugin
>> under the jenkins github org, or accept it doesn't appear in the
>> official/main public plugins list ?
>>
>>
>> So the cost is that some organisations and individuals may refuse to do
>> that (for the reasons described), so you get less overall plugins in the
>> ecosystem. You're not forcing them to assign copyright. You're not
>> forcing them to use the MIT license. You're not even forcing the plugins
>> to be open-source. What's the benefit of forcing them to commit to a
>> particular /organisation/ ? That seems a curiously prescriptive
>> requirement for a project that in all other ways seems so culturally
>> 'open'. They are, after all, giving this away to you /for free/.
>>
>
> Hmm, perhaps we didn't write it down in [1] because we kinda take it for
> granted, but we don't want proprietary plugins in the update center.


This is part of the reason why, for example, CloudBees operate our own
update center infrastructure, because we have proprietary plugins and we
respect this community so we put our open source plugins in the community
organisation and publish those to the community update center. Our closed
source plugins go to our own update center(s)... And we have even got one
or two open source "meta plugins" that install our update centers in
Jenkins (and install the cert to validate our metadata against... the Certs
are why it's not just a simple "type in the URL").


- Stephen (wearing his CloudBees hat today)


> As for the reasons behind why we want to force people to a particular
> GitHub organization, I already mentioned some of those in my original
> response.
>
> To reiterate, one is the continuity. For example, parameterized trigger
> plugin was originally developed by Tom Huybrechts, but now it's maintained
> by totally different people.
>
> The situation I'm trying to avoid is that with Ant task or Maven plugin,
> where there are hundreds of Ant tasks and Maven plugins out there, which
> presumably does what the author wanted perfectly, but if someone else wants
> to make a little bit of change to make it work for a slightly different use
> case, then he'd have to fork it, give it a different GAV ID, and release it
> to use it.
>
> Come to think of it, I can think of another example of this. Build
> pipeline plugin was a popular plugin originally developed outside our org,
> and the development by the original author eventually got stalled, and the
> rest of us couldn't carry it forward. It took a conscious effort to bring
> it here, which wouldn't have happened for less important plugins.
>
>
> Another motivation is to use this as an incentive to bring plugin
> developers to the community. We get to learn where they are, some of them
> will hack on other plugins or core, and it creates one place where we can
> run massive "git grep" to find out who is using what extension points, one
> place where users can come to file issues, and so on.
>
> Yes, in theory any rules like that discourage some companies and
> individuals from participating. But when we look at 906 plugins, I think
> it's fair to say we've struck a right balance.
>
>
>  I think there's a secondary benefit /to me/, to being _in the early
>> days_ outside the jenkins gitub org. When you're mostly noodling around
>> with a plugin, it's unclear sometimes if the direction is correct, there
>> may be huge refactorings and change between releases. External
>> contributions aren't all that useful, because things are moving too
>> fast. Once it reaches a 'degree of maturity', I'd push it over to the
>> jenkinsci org - which is my tacit statement of 'seems to be useful /
>> working to a certian extent -- have at it'. I then /benefit/ because -
>> anecdotally - you get more contributors that way.
>>
>> I can see bad scenarios where orgs may end up conforming to the letter
>> of that rule, but behaving in a way that's inconsistent
>> with the spirit of what 'having your plugin in the jenkinsci org'
>> /ought/ to mean (especially in terms of the way it deals with
>> contributions and commits). This way madness and politics lie.
>>
>
> I believe in the autonomy of people who are doing the actual work, so if
> you feel like the plugin is still at the early stage and not ready for
> other people to hack on, then I respect that.
>
> But isn't it just a matter of having a README that states so? (And if I
> discover that README says "don't hack on this just yet because this is
> still very much a work in progress and very fluid" but no commit in the
> past 6 months, I'd probably feel comfortable making changes anyway.)
>
>
>  As an aside, It would be nice if Jenkins s

Re: Opensourcing a plugin under a different github org

[Kohsuke Kawaguchi]

On 03/25/2014 06:12 PM, Surya Gaddipati wrote:

 >You say it is for obvious reasons you'd want them listed under different
 >org, but I'd like to ask you why that is.

One of incentives for my employer is 'brand building' in terms of open
source presence which could help us attract more qualified people.
And a company's github page is a what usually people checkout


OK. I hope you see where I'm coming from and why the project operates 
the way it is.


With respect to brand building, trying to brainstorm...

 - you are welcome to put your company logo in the plugin pages, like
   some others do.
 - you can use the company names in the package names if that helps.
 - we can highlight you and your plugin on http://jenkins-ci.org/node
   like we did with [1] for [2]
 - if you want to mirror the repo in your org, that would help your
   prospective employees to find them more easily.

Would some combination of those do?

[1] https://jenkins-ci.org/content/office-hours-next-week-metadata-plugin
[2] 
http://developer.sonymobile.com/2012/11/22/sony-contributes-to-jenkins-software-tool/





For example, this is my plugin
https://github.com/jenkinsci/slave-utilization-plugin
which has close to 200 stars

But it is nowhere to be seen on my github page
https://github.com/jenkinsci/slave-utilization-plugin


Surya



On Monday, March 24, 2014 1:04:19 PM UTC-5, Surya Gaddipati wrote:

My employer is interested in opensourcing a plugin that we developed
in house. But we would like our plugin to be under github org not
jenkins-ci ( for obvious reasons) .

Is it possible to make plugin  show up in the default jenkins update
center?

--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.



--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

--
You received this message because you are subscribed to the Google Groups "Jenkins 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Kohsuke Kawaguchi]

On 03/26/2014 03:06 AM, Nigel Magnay wrote:


+1.
I don't like the idea of having some plugins referenced under the
official update center that don't actually come from the jenkinsci
github organization.
The deal seems quite simple to me: either accept to host your plugin
under the jenkins github org, or accept it doesn't appear in the
official/main public plugins list ?


So the cost is that some organisations and individuals may refuse to do
that (for the reasons described), so you get less overall plugins in the
ecosystem. You're not forcing them to assign copyright. You're not
forcing them to use the MIT license. You're not even forcing the plugins
to be open-source. What's the benefit of forcing them to commit to a
particular /organisation/ ? That seems a curiously prescriptive
requirement for a project that in all other ways seems so culturally
'open'. They are, after all, giving this away to you /for free/.


Hmm, perhaps we didn't write it down in [1] because we kinda take it for 
granted, but we don't want proprietary plugins in the update center.


As for the reasons behind why we want to force people to a particular 
GitHub organization, I already mentioned some of those in my original 
response.


To reiterate, one is the continuity. For example, parameterized trigger 
plugin was originally developed by Tom Huybrechts, but now it's 
maintained by totally different people.


The situation I'm trying to avoid is that with Ant task or Maven plugin, 
where there are hundreds of Ant tasks and Maven plugins out there, which 
presumably does what the author wanted perfectly, but if someone else 
wants to make a little bit of change to make it work for a slightly 
different use case, then he'd have to fork it, give it a different GAV 
ID, and release it to use it.


Come to think of it, I can think of another example of this. Build 
pipeline plugin was a popular plugin originally developed outside our 
org, and the development by the original author eventually got stalled, 
and the rest of us couldn't carry it forward. It took a conscious effort 
to bring it here, which wouldn't have happened for less important plugins.



Another motivation is to use this as an incentive to bring plugin 
developers to the community. We get to learn where they are, some of 
them will hack on other plugins or core, and it creates one place where 
we can run massive "git grep" to find out who is using what extension 
points, one place where users can come to file issues, and so on.


Yes, in theory any rules like that discourage some companies and 
individuals from participating. But when we look at 906 plugins, I think 
it's fair to say we've struck a right balance.




I think there's a secondary benefit /to me/, to being _in the early
days_ outside the jenkins gitub org. When you're mostly noodling around
with a plugin, it's unclear sometimes if the direction is correct, there
may be huge refactorings and change between releases. External
contributions aren't all that useful, because things are moving too
fast. Once it reaches a 'degree of maturity', I'd push it over to the
jenkinsci org - which is my tacit statement of 'seems to be useful /
working to a certian extent -- have at it'. I then /benefit/ because -
anecdotally - you get more contributors that way.

I can see bad scenarios where orgs may end up conforming to the letter
of that rule, but behaving in a way that's inconsistent
with the spirit of what 'having your plugin in the jenkinsci org'
/ought/ to mean (especially in terms of the way it deals with
contributions and commits). This way madness and politics lie.


I believe in the autonomy of people who are doing the actual work, so if 
you feel like the plugin is still at the early stage and not ready for 
other people to hack on, then I respect that.


But isn't it just a matter of having a README that states so? (And if I 
discover that README says "don't hack on this just yet because this is 
still very much a work in progress and very fluid" but no commit in the 
past 6 months, I'd probably feel comfortable making changes anyway.)




As an aside, It would be nice if Jenkins supported >1 configured plugin
repository. The process of pushing out 'this might fix your issue'
SNAPSHOTS to end-users is pretty tedious, it'd be nice to say 'just
install the latest SNAPSHOT build and see if that works'.


The experimental update center [2] is an effort torward this direction, 
and all you have to do to participate is to release with 'alpha' or 
'beta' in the version number.


You are right that letting people install bug fixes more quickly is a 
good thing. I think a mechanism that lets you click a button in [3] and 
install it in your local Jenkins would be nice.





[1] https://wiki.jenkins-ci.org/display/JENKINS/Governance+Document
[2] http://jenkins-ci.org/content/experimental-plugins-update-center
[3] https://jenkins.ci.cloudbees.com/job/plugins
--
Kohsuke Kawaguchi | CloudBee

Re: Opensourcing a plugin under a different github org

[Nigel Magnay]

>
>
>
> Open source is also about making things together, not just making things
> public.
>
>
>
Not necessarily.

There are plenty of projects that are open source, that are not interested
in contributions. Google Guava, for one.

Putting things in jenkinsci group probably *should* mean 'open to
contributions and collaboration'. But that won't fit everyone's model.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Jerome Lacoste]

On Wednesday, March 26, 2014 2:12:36 AM UTC+1, Surya Gaddipati wrote:
>
> >You say it is for obvious reasons you'd want them listed under different 
> >org, but I'd like to ask you why that is.
>
> One of incentives for my employer is 'brand building' in terms of open 
> source presence which could help us attract more qualified people.  
> And a company's github page is a what usually people checkout
>

In a sense, it's the fact that your public got forked into jenkinsci org, 
and from there, your work lost visibility a bit.

Maybe github need to rework the repository popularity representation by 
taking into account the history of the fork.

Or, better, show under your own organization, the popular project hosted in 
different organizations to which your own members also contribute to. 
Something to suggest to github !

Open source is also about making things together, not just making things 
public.

Jerome


> For example, this is my plugin 
> https://github.com/jenkinsci/slave-utilization-plugin
> which has close to 200 stars 
>
> But it is nowhere to be seen on my github page 
> https://github.com/jenkinsci/slave-utilization-plugin 
>
>
> Surya
>
>
>
> On Monday, March 24, 2014 1:04:19 PM UTC-5, Surya Gaddipati wrote:
>>
>> My employer is interested in opensourcing a plugin that we developed in 
>> house. But we would like our plugin to be under github org not jenkins-ci ( 
>> for obvious reasons) . 
>>
>> Is it possible to make plugin  show up in the default jenkins update 
>> center?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Emanuele Zattin]

I agree with Kohsuke. What would happen if the the original writer of a
non-hosted plugin stops supporting it? Somebody would probably end up
forking it (if it's on Github) and might even host it in the jenkins
organisation. It's kind of unclear what would happen in such scenario.

A pragmatic approach would be for Jenkins to support the visualisation of
the originating company name/logo in the plugin manager. That would give
big visibility to companies that embrace open-source and contribute plugins
to the Jenkins ecosystem.

Emanuele Zattin
---
-I don't have to know an answer. I don't feel frightened by not knowing
things; by being lost in a mysterious universe without any purpose -- which
is the way it really is, as far as I can tell, possibly. It doesn't
frighten me.- Richard Feynman


On Wed, Mar 26, 2014 at 11:06 AM, Nigel Magnay wrote:

>
> +1.
>> I don't like the idea of having some plugins referenced under the
>> official update center that don't actually come from the jenkinsci github
>> organization.
>> The deal seems quite simple to me: either accept to host your plugin
>> under the jenkins github org, or accept it doesn't appear in the
>> official/main public plugins list ?
>>
>>
> So the cost is that some organisations and individuals may refuse to do
> that (for the reasons described), so you get less overall plugins in the
> ecosystem. You're not forcing them to assign copyright. You're not forcing
> them to use the MIT license. You're not even forcing the plugins to be
> open-source. What's the benefit of forcing them to commit to a particular
> *organisation* ? That seems a curiously prescriptive requirement for a
> project that in all other ways seems so culturally 'open'. They are, after
> all, giving this away to you *for free*.
>
> I think there's a secondary benefit *to me*, to being *in the early days* 
> outside
> the jenkins gitub org. When you're mostly noodling around with a plugin,
> it's unclear sometimes if the direction is correct, there may be huge
> refactorings and change between releases. External contributions aren't all
> that useful, because things are moving too fast. Once it reaches a 'degree
> of maturity', I'd push it over to the jenkinsci org - which is my tacit
> statement of 'seems to be useful / working to a certian extent -- have at
> it'. I then *benefit* because - anecdotally - you get more contributors
> that way.
>
> I can see bad scenarios where orgs may end up conforming to the letter of
> that rule, but behaving in a way that's inconsistent
> with the spirit of what 'having your plugin in the jenkinsci org' *ought*to 
> mean (especially in terms of the way it deals with contributions and
> commits). This way madness and politics lie.
>
> As an aside, It would be nice if Jenkins supported >1 configured plugin
> repository. The process of pushing out 'this might fix your issue'
> SNAPSHOTS to end-users is pretty tedious, it'd be nice to say 'just install
> the latest SNAPSHOT build and see if that works'.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Nigel Magnay]

> +1.
> I don't like the idea of having some plugins referenced under the official
> update center that don't actually come from the jenkinsci github
> organization.
> The deal seems quite simple to me: either accept to host your plugin under
> the jenkins github org, or accept it doesn't appear in the official/main
> public plugins list ?
>
>
So the cost is that some organisations and individuals may refuse to do
that (for the reasons described), so you get less overall plugins in the
ecosystem. You're not forcing them to assign copyright. You're not forcing
them to use the MIT license. You're not even forcing the plugins to be
open-source. What's the benefit of forcing them to commit to a particular
*organisation* ? That seems a curiously prescriptive requirement for a
project that in all other ways seems so culturally 'open'. They are, after
all, giving this away to you *for free*.

I think there's a secondary benefit *to me*, to being *in the early
days* outside
the jenkins gitub org. When you're mostly noodling around with a plugin,
it's unclear sometimes if the direction is correct, there may be huge
refactorings and change between releases. External contributions aren't all
that useful, because things are moving too fast. Once it reaches a 'degree
of maturity', I'd push it over to the jenkinsci org - which is my tacit
statement of 'seems to be useful / working to a certian extent -- have at
it'. I then *benefit* because - anecdotally - you get more contributors
that way.

I can see bad scenarios where orgs may end up conforming to the letter of
that rule, but behaving in a way that's inconsistent
with the spirit of what 'having your plugin in the jenkinsci org'
*ought*to mean (especially in terms of the way it deals with
contributions and
commits). This way madness and politics lie.

As an aside, It would be nice if Jenkins supported >1 configured plugin
repository. The process of pushing out 'this might fix your issue'
SNAPSHOTS to end-users is pretty tedious, it'd be nice to say 'just install
the latest SNAPSHOT build and see if that works'.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Surya Gaddipati]

>You say it is for obvious reasons you'd want them listed under different 
>org, but I'd like to ask you why that is.

One of incentives for my employer is 'brand building' in terms of open 
source presence which could help us attract more qualified people.  
And a company's github page is a what usually people checkout

For example, this is my plugin 
https://github.com/jenkinsci/slave-utilization-plugin
which has close to 200 stars 

But it is nowhere to be seen on my github page 
https://github.com/jenkinsci/slave-utilization-plugin 


Surya



On Monday, March 24, 2014 1:04:19 PM UTC-5, Surya Gaddipati wrote:
>
> My employer is interested in opensourcing a plugin that we developed in 
> house. But we would like our plugin to be under github org not jenkins-ci ( 
> for obvious reasons) . 
>
> Is it possible to make plugin  show up in the default jenkins update 
> center?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Baptiste Mathus]

+1.
I don't like the idea of having some plugins referenced under the official
update center that don't actually come from the jenkinsci github
organization.
The deal seems quite simple to me: either accept to host your plugin under
the jenkins github org, or accept it doesn't appear in the official/main
public plugins list ?


2014-03-25 1:00 GMT+01:00 Richard Bywater :

> +1 to trying to keep them in the same place.
>
>
> On Tue, Mar 25, 2014 at 12:36 PM, Kohsuke Kawaguchi wrote:
>
>>
>> We might not be enforcing it today, but it's at least my intention that
>> we want all the plugins in the community update center be hosted on our
>> GitHub org. To me, it's an important part of creating an incentive for
>> people to come to the community.
>>
>> There's also the continuity problem --- if you write a plugin that works
>> for you and you move on to other projects, and if somebody else takes over
>> the plugin to carry it forward, we have no way of tracking whose plugins
>> should be "official."
>>
>> You say it is for obvious reasons you'd want them listed under different
>> org, but I'd like to ask you why that is.
>>
>> If it is the credit problem, we have companies like Praqma who develops
>> plugins and posts them in the Jenkins org, and they'd still take credits by
>> putting their logos on Wiki [1]. Other companies use their company names as
>> package names.
>>
>>
>>
>>
>> [1] https://wiki.jenkins-ci.org/display/JENKINS/PRQA+Plugin
>>
>>
>> On 03/24/2014 11:04 AM, Surya Gaddipati wrote:
>>
>>> My employer is interested in opensourcing a plugin that we developed in
>>> house. But we would like our plugin to be under github org not
>>> jenkins-ci ( for obvious reasons) .
>>>
>>> Is it possible to make plugin  show up in the default jenkins update
>>> center?
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Kohsuke Kawaguchi  http://kohsuke.org/
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Richard Bywater]

+1 to trying to keep them in the same place.


On Tue, Mar 25, 2014 at 12:36 PM, Kohsuke Kawaguchi  wrote:

>
> We might not be enforcing it today, but it's at least my intention that we
> want all the plugins in the community update center be hosted on our GitHub
> org. To me, it's an important part of creating an incentive for people to
> come to the community.
>
> There's also the continuity problem --- if you write a plugin that works
> for you and you move on to other projects, and if somebody else takes over
> the plugin to carry it forward, we have no way of tracking whose plugins
> should be "official."
>
> You say it is for obvious reasons you'd want them listed under different
> org, but I'd like to ask you why that is.
>
> If it is the credit problem, we have companies like Praqma who develops
> plugins and posts them in the Jenkins org, and they'd still take credits by
> putting their logos on Wiki [1]. Other companies use their company names as
> package names.
>
>
>
>
> [1] https://wiki.jenkins-ci.org/display/JENKINS/PRQA+Plugin
>
>
> On 03/24/2014 11:04 AM, Surya Gaddipati wrote:
>
>> My employer is interested in opensourcing a plugin that we developed in
>> house. But we would like our plugin to be under github org not
>> jenkins-ci ( for obvious reasons) .
>>
>> Is it possible to make plugin  show up in the default jenkins update
>> center?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to jenkinsci-dev+unsubscr...@googlegroups.com
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Kohsuke Kawaguchi  http://kohsuke.org/
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Kohsuke Kawaguchi]

We might not be enforcing it today, but it's at least my intention that 
we want all the plugins in the community update center be hosted on our 
GitHub org. To me, it's an important part of creating an incentive for 
people to come to the community.


There's also the continuity problem --- if you write a plugin that works 
for you and you move on to other projects, and if somebody else takes 
over the plugin to carry it forward, we have no way of tracking whose 
plugins should be "official."


You say it is for obvious reasons you'd want them listed under different 
org, but I'd like to ask you why that is.


If it is the credit problem, we have companies like Praqma who develops 
plugins and posts them in the Jenkins org, and they'd still take credits 
by putting their logos on Wiki [1]. Other companies use their company 
names as package names.





[1] https://wiki.jenkins-ci.org/display/JENKINS/PRQA+Plugin

On 03/24/2014 11:04 AM, Surya Gaddipati wrote:

My employer is interested in opensourcing a plugin that we developed in
house. But we would like our plugin to be under github org not
jenkins-ci ( for obvious reasons) .

Is it possible to make plugin  show up in the default jenkins update center?

--
You received this message because you are subscribed to the Google
Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to jenkinsci-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.



--
Kohsuke Kawaguchi  http://kohsuke.org/

--
You received this message because you are subscribed to the Google Groups "Jenkins 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[nicolas de loof]

yes, no problem, even it's easier for contributors to find its source code
when present in jenkinsci org.


2014-03-24 19:04 GMT+01:00 Surya Gaddipati :

> My employer is interested in opensourcing a plugin that we developed in
> house. But we would like our plugin to be under github org not jenkins-ci (
> for obvious reasons) .
>
> Is it possible to make plugin  show up in the default jenkins update
> center?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Opensourcing a plugin under a different github org

[Bruno P. Kinoshita]

I believe it is, the Dynamic Parameter seems to be hosted elsewhere 
https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Dynamic+Parameter+Plug-in
 
HTH

Bruno

>
> From: Surya Gaddipati 
>To: jenkinsci-dev@googlegroups.com 
>Sent: Monday, March 24, 2014 3:04 PM
>Subject: Opensourcing a plugin under a different github org
> 
>
>
>My employer is interested in opensourcing a plugin that we developed in house. 
>But we would like our plugin to be under github org not jenkins-ci ( for 
>obvious reasons) . 
>
>
>Is it possible to make plugin  show up in the default jenkins update center?
-- 
>You received this message because you are subscribed to the Google Groups 
>"Jenkins Developers" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to jenkinsci-dev+unsubscr...@googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Opensourcing a plugin under a different github org

[Surya Gaddipati]

My employer is interested in opensourcing a plugin that we developed in 
house. But we would like our plugin to be under github org not jenkins-ci ( 
for obvious reasons) . 

Is it possible to make plugin  show up in the default jenkins update center?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.