Quantcast

PROPOSAL: Moving the git plugin into the core distribution

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PROPOSAL: Moving the git plugin into the core distribution

Andrew Bayer
Subject says it all - this is directly prompted by https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide usage of the git plugin (the most of any non-core SCM plugin, and more than any non-core plugin other than greenballs and the Analysis plugins), it makes sense to start including git in the core. This wouldn't mean any change on the git plugin's development cycle - but we'd only update the core distro to use a newer version periodically, as is done with the subversion plugin currently. 

Any opposition to doing this, starting with, say, 1.413?

A.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Nigel Magnay
This sounds a good idea to me.

I don't know how the distros are currently made (I just wget a .war and use the winstone container), but we could do something like this :

- have a separate project, 'jenkins-distribution'. This may additionally build product installers (e.g IzPack with tomcat distro).

- that project contains jenkins itself, and the plugins to be shipped, referenced as git submodules

That way, in-house users (or commercial resellers / vendors) of Jenkins could actually fork the entire distro project and add in their own 'standard' modules as they wish..



On Wed, May 11, 2011 at 7:22 PM, Andrew Bayer <[hidden email]> wrote:
Subject says it all - this is directly prompted by https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide usage of the git plugin (the most of any non-core SCM plugin, and more than any non-core plugin other than greenballs and the Analysis plugins), it makes sense to start including git in the core. This wouldn't mean any change on the git plugin's development cycle - but we'd only update the core distro to use a newer version periodically, as is done with the subversion plugin currently. 

Any opposition to doing this, starting with, say, 1.413?

A.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Olivier Lamy-2
In reply to this post by Andrew Bayer
+1 !

2011/5/11 Andrew Bayer <[hidden email]>:

> Subject says it all - this is directly prompted
> by https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
> usage of the git plugin (the most of any non-core SCM plugin, and more than
> any non-core plugin other than greenballs and the Analysis plugins), it
> makes sense to start including git in the core. This wouldn't mean any
> change on the git plugin's development cycle - but we'd only update the core
> distro to use a newer version periodically, as is done with the subversion
> plugin currently.
> Any opposition to doing this, starting with, say, 1.413?
> A.



--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

kohsuke Kawaguchi (CB)
In reply to this post by Andrew Bayer

+1.

Good news is that we can relatively easily add/remove plugins that are
developed outside core from the get-go.

The current footprint of the git plugin is 2MB, so the size increase we
are looking at is from 37MB to 39MB.

On 05/11/2011 11:22 AM, Andrew Bayer wrote:

> Subject says it all - this is directly prompted by
> https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
> usage of the git plugin (the most of any non-core SCM plugin, and more
> than any non-core plugin other than greenballs and the Analysis
> plugins), it makes sense to start including git in the core. This
> wouldn't mean any change on the git plugin's development cycle - but
> we'd only update the core distro to use a newer version periodically, as
> is done with the subversion plugin currently.
>
> Any opposition to doing this, starting with, say, 1.413?
>
> A.


--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Andrew Gray
+1

On 12 May 2011 06:23, Kohsuke Kawaguchi <[hidden email]> wrote:

+1.

Good news is that we can relatively easily add/remove plugins that are developed outside core from the get-go.

The current footprint of the git plugin is 2MB, so the size increase we are looking at is from 37MB to 39MB.


On 05/11/2011 11:22 AM, Andrew Bayer wrote:
Subject says it all - this is directly prompted by
https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
usage of the git plugin (the most of any non-core SCM plugin, and more
than any non-core plugin other than greenballs and the Analysis
plugins), it makes sense to start including git in the core. This
wouldn't mean any change on the git plugin's development cycle - but
we'd only update the core distro to use a newer version periodically, as
is done with the subversion plugin currently.

Any opposition to doing this, starting with, say, 1.413?

A.


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

hagzag
+1

Sent from my iPhone

On May 12, 2011, at 7:58, Andrew Gray <[hidden email]> wrote:

+1

On 12 May 2011 06:23, Kohsuke Kawaguchi <[hidden email]> wrote:

+1.

Good news is that we can relatively easily add/remove plugins that are developed outside core from the get-go.

The current footprint of the git plugin is 2MB, so the size increase we are looking at is from 37MB to 39MB.


On 05/11/2011 11:22 AM, Andrew Bayer wrote:
Subject says it all - this is directly prompted by
https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
usage of the git plugin (the most of any non-core SCM plugin, and more
than any non-core plugin other than greenballs and the Analysis
plugins), it makes sense to start including git in the core. This
wouldn't mean any change on the git plugin's development cycle - but
we'd only update the core distro to use a newer version periodically, as
is done with the subversion plugin currently.

Any opposition to doing this, starting with, say, 1.413?

A.


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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Vincent Beretti
+1

On Thu, May 12, 2011 at 5:36 AM, [hidden email] <[hidden email]> wrote:
+1

Sent from my iPhone

On May 12, 2011, at 7:58, Andrew Gray <[hidden email]> wrote:

+1

On 12 May 2011 06:23, Kohsuke Kawaguchi <[hidden email][hidden email]> wrote:

+1.

Good news is that we can relatively easily add/remove plugins that are developed outside core from the get-go.

The current footprint of the git plugin is 2MB, so the size increase we are looking at is from 37MB to 39MB.


On 05/11/2011 11:22 AM, Andrew Bayer wrote:
Subject says it all - this is directly prompted by
https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
usage of the git plugin (the most of any non-core SCM plugin, and more
than any non-core plugin other than greenballs and the Analysis
plugins), it makes sense to start including git in the core. This
wouldn't mean any change on the git plugin's development cycle - but
we'd only update the core distro to use a newer version periodically, as
is done with the subversion plugin currently.

Any opposition to doing this, starting with, say, 1.413?

A.


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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

nicolas de loof-2
+1

A Must have !

2011/5/12 Vincent Beretti <[hidden email]>
+1


On Thu, May 12, 2011 at 5:36 AM, [hidden email] <[hidden email]> wrote:
+1

Sent from my iPhone

On May 12, 2011, at 7:58, Andrew Gray <[hidden email]> wrote:

+1

On 12 May 2011 06:23, Kohsuke Kawaguchi <[hidden email][hidden email]> wrote:

+1.

Good news is that we can relatively easily add/remove plugins that are developed outside core from the get-go.

The current footprint of the git plugin is 2MB, so the size increase we are looking at is from 37MB to 39MB.


On 05/11/2011 11:22 AM, Andrew Bayer wrote:
Subject says it all - this is directly prompted by
https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
usage of the git plugin (the most of any non-core SCM plugin, and more
than any non-core plugin other than greenballs and the Analysis
plugins), it makes sense to start including git in the core. This
wouldn't mean any change on the git plugin's development cycle - but
we'd only update the core distro to use a newer version periodically, as
is done with the subversion plugin currently.

Any opposition to doing this, starting with, say, 1.413?

A.


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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Benedikt Biallowons-2
+ 1

Am 12.05.2011 um 11:55 schrieb nicolas de loof:

+1

A Must have !

2011/5/12 Vincent Beretti <[hidden email]>
+1


On Thu, May 12, 2011 at 5:36 AM, [hidden email] <[hidden email]> wrote:
+1

Sent from my iPhone

On May 12, 2011, at 7:58, Andrew Gray <[hidden email]> wrote:

+1

On 12 May 2011 06:23, Kohsuke Kawaguchi <[hidden email][hidden email]> wrote:

+1.

Good news is that we can relatively easily add/remove plugins that are developed outside core from the get-go.

The current footprint of the git plugin is 2MB, so the size increase we are looking at is from 37MB to 39MB.


On 05/11/2011 11:22 AM, Andrew Bayer wrote:
Subject says it all - this is directly prompted by
https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
usage of the git plugin (the most of any non-core SCM plugin, and more
than any non-core plugin other than greenballs and the Analysis
plugins), it makes sense to start including git in the core. This
wouldn't mean any change on the git plugin's development cycle - but
we'd only update the core distro to use a newer version periodically, as
is done with the subversion plugin currently.

Any opposition to doing this, starting with, say, 1.413?

A.


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





PGP.sig (547 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Dean Yu
In reply to this post by Andrew Bayer
Re: PROPOSAL: Moving the git plugin into the core distribution Not against this, but a couple of general comments.

If a new version of the plugin goes into a core release, please make note of it in the core changelog. I made this request of the Subversion plugin in the past. We should extend the practice to all bundled plugins.

People will also need to be educated that the git plugin will now be subject to version pinning.

  -- Dean


On 5/11/11 11:22 AM, "Andrew Bayer" <andrew.bayer@...> wrote:

Subject says it all - this is directly prompted by https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide usage of the git plugin (the most of any non-core SCM plugin, and more than any non-core plugin other than greenballs and the Analysis plugins), it makes sense to start including git in the core. This wouldn't mean any change on the git plugin's development cycle - but we'd only update the core distro to use a newer version periodically, as is done with the subversion plugin currently. 

Any opposition to doing this, starting with, say, 1.413?

A.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Andrew Bayer
Agreed wholeheartedly on both counts.

A.

On Thu, May 12, 2011 at 11:54 AM, Dean Yu <[hidden email]> wrote:
Not against this, but a couple of general comments.

If a new version of the plugin goes into a core release, please make note of it in the core changelog. I made this request of the Subversion plugin in the past. We should extend the practice to all bundled plugins.

People will also need to be educated that the git plugin will now be subject to version pinning.

  -- Dean



On 5/11/11 11:22 AM, "Andrew Bayer" <andrew.bayer@...> wrote:

Subject says it all - this is directly prompted by https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide usage of the git plugin (the most of any non-core SCM plugin, and more than any non-core plugin other than greenballs and the Analysis plugins), it makes sense to start including git in the core. This wouldn't mean any change on the git plugin's development cycle - but we'd only update the core distro to use a newer version periodically, as is done with the subversion plugin currently. 

Any opposition to doing this, starting with, say, 1.413?

A.


Bap
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Bap
As things stand, when I install Jenkins I begin by doing one of two things

1. I need access to subversion repositories;
disable CVS, upgrade subversion plugin and install notifiers and  
publishers (and Chuck)

2. I can use Git :-)
disable CVS and subversion, install the Git plugin and other plugins  
that I will need/want.

Is it really necessary to bundle *any* SCM plugins? I have never used  
any that have been bundled.

If we want people to be able to get started quickly, then one option,  
is to provide the weekly latest and greatest without these plugins and  
only bundle them with the stable build. WDYT?

Bap.


Quoting Andrew Bayer <[hidden email]>:

> Agreed wholeheartedly on both counts.
>
> A.
>
> On Thu, May 12, 2011 at 11:54 AM, Dean Yu <[hidden email]> wrote:
>
>>  Not against this, but a couple of general comments.
>>
>> If a new version of the plugin goes into a core release, please make note
>> of it in the core changelog. I made this request of the Subversion plugin in
>> the past. We should extend the practice to all bundled plugins.
>>
>> People will also need to be educated that the git plugin will now be
>> subject to version pinning.
>>
>>   -- Dean
>>
>>
>>
>> On 5/11/11 11:22 AM, "Andrew Bayer" <[hidden email]> wrote:
>>
>> Subject says it all - this is directly prompted by
>> https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
>> usage of the git plugin (the most of any non-core SCM plugin, and more than
>> any non-core plugin other than greenballs and the Analysis plugins), it
>> makes sense to start including git in the core. This wouldn't mean any
>> change on the git plugin's development cycle - but we'd only update the core
>> distro to use a newer version periodically, as is done with the subversion
>> plugin currently.
>>
>> Any opposition to doing this, starting with, say, 1.413?
>>
>> A.
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Richard Bywater
+1 to the with/without bundle. Personally I currently don't use SVN or Git (we're stuck with Clearcase but trying to get to Mercurial) and its a little bit of a pain having to download larger and larger bundles that don't give me anything.

I can see similar requests to bundle SCM x into the core in the future - guess if we're going to have them bundled then what's the criteria?

Richard.

On Fri, May 13, 2011 at 8:04 AM, Bap <[hidden email]> wrote:
As things stand, when I install Jenkins I begin by doing one of two things

1. I need access to subversion repositories;
disable CVS, upgrade subversion plugin and install notifiers and publishers (and Chuck)

2. I can use Git :-)
disable CVS and subversion, install the Git plugin and other plugins that I will need/want.

Is it really necessary to bundle *any* SCM plugins? I have never used any that have been bundled.

If we want people to be able to get started quickly, then one option, is to provide the weekly latest and greatest without these plugins and only bundle them with the stable build. WDYT?

Bap.



Quoting Andrew Bayer <[hidden email]>:

Agreed wholeheartedly on both counts.

A.

On Thu, May 12, 2011 at 11:54 AM, Dean Yu <[hidden email]> wrote:

 Not against this, but a couple of general comments.

If a new version of the plugin goes into a core release, please make note
of it in the core changelog. I made this request of the Subversion plugin in
the past. We should extend the practice to all bundled plugins.

People will also need to be educated that the git plugin will now be
subject to version pinning.

 -- Dean



On 5/11/11 11:22 AM, "Andrew Bayer" <[hidden email]> wrote:

Subject says it all - this is directly prompted by
https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
usage of the git plugin (the most of any non-core SCM plugin, and more than
any non-core plugin other than greenballs and the Analysis plugins), it
makes sense to start including git in the core. This wouldn't mean any
change on the git plugin's development cycle - but we'd only update the core
distro to use a newer version periodically, as is done with the subversion
plugin currently.

Any opposition to doing this, starting with, say, 1.413?

A.





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

kohsuke Kawaguchi (CB)
In reply to this post by Bap

The challenge with removing Subversion and CVS is that those
functionalities are originally developed in the core, and separated into
a plugin in version 1.X (I think X was 1.300-ish but I could be wrong)

So if people are upgrading from a version earlier than 1.X and our
latest release doesn't have the Subversion plugin bundled, this
installation will run the risk of losing the SCM configuration until
Subversion plugin is installed.

I think this data loss is too risky, and that's why we still bundle
those plugins.


On 05/12/2011 01:04 PM, Bap wrote:

> As things stand, when I install Jenkins I begin by doing one of two things
>
> 1. I need access to subversion repositories;
> disable CVS, upgrade subversion plugin and install notifiers and
> publishers (and Chuck)
>
> 2. I can use Git :-)
> disable CVS and subversion, install the Git plugin and other plugins
> that I will need/want.
>
> Is it really necessary to bundle *any* SCM plugins? I have never used
> any that have been bundled.
>
> If we want people to be able to get started quickly, then one option,
> is to provide the weekly latest and greatest without these plugins and
> only bundle them with the stable build. WDYT?
>
> Bap.
>
>
> Quoting Andrew Bayer<[hidden email]>:
>
>>  Agreed wholeheartedly on both counts.
>>
>>  A.
>>
>>  On Thu, May 12, 2011 at 11:54 AM, Dean Yu<[hidden email]>  wrote:
>>
>>>   Not against this, but a couple of general comments.
>>>
>>>  If a new version of the plugin goes into a core release, please make note
>>>  of it in the core changelog. I made this request of the Subversion plugin in
>>>  the past. We should extend the practice to all bundled plugins.
>>>
>>>  People will also need to be educated that the git plugin will now be
>>>  subject to version pinning.
>>>
>>>    -- Dean
>>>
>>>
>>>
>>>  On 5/11/11 11:22 AM, "Andrew Bayer"<[hidden email]>  wrote:
>>>
>>>  Subject says it all - this is directly prompted by
>>>  https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
>>>  usage of the git plugin (the most of any non-core SCM plugin, and more than
>>>  any non-core plugin other than greenballs and the Analysis plugins), it
>>>  makes sense to start including git in the core. This wouldn't mean any
>>>  change on the git plugin's development cycle - but we'd only update the core
>>>  distro to use a newer version periodically, as is done with the subversion
>>>  plugin currently.
>>>
>>>  Any opposition to doing this, starting with, say, 1.413?
>>>
>>>  A.
>>>
>>>
>>
>
>


--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

kohsuke Kawaguchi (CB)

No, because Git plugin was never implemented as a core functionality, we
can remove it.

On 05/12/2011 02:39 PM, Bap wrote:

> Which means that if we add Git, we'll never be able to remove that either?!
>
> Bap.
>
> Quoting Kohsuke Kawaguchi<[hidden email]>:
>
>>
>>  The challenge with removing Subversion and CVS is that those
>>  functionalities are originally developed in the core, and separated
>>  into a plugin in version 1.X (I think X was 1.300-ish but I could be
>>  wrong)
>>
>>  So if people are upgrading from a version earlier than 1.X and our
>>  latest release doesn't have the Subversion plugin bundled, this
>>  installation will run the risk of losing the SCM configuration until
>>  Subversion plugin is installed.
>>
>>  I think this data loss is too risky, and that's why we still bundle
>>  those plugins.
>>
>>
>>  On 05/12/2011 01:04 PM, Bap wrote:
>>>  As things stand, when I install Jenkins I begin by doing one of two things
>>>
>>>  1. I need access to subversion repositories;
>>>  disable CVS, upgrade subversion plugin and install notifiers and
>>>  publishers (and Chuck)
>>>
>>>  2. I can use Git :-)
>>>  disable CVS and subversion, install the Git plugin and other plugins
>>>  that I will need/want.
>>>
>>>  Is it really necessary to bundle *any* SCM plugins? I have never used
>>>  any that have been bundled.
>>>
>>>  If we want people to be able to get started quickly, then one option,
>>>  is to provide the weekly latest and greatest without these plugins and
>>>  only bundle them with the stable build. WDYT?
>>>
>>>  Bap.
>>>
>>>
>>>  Quoting Andrew Bayer<[hidden email]>:
>>>
>>>>  Agreed wholeheartedly on both counts.
>>>>
>>>>  A.
>>>>
>>>>  On Thu, May 12, 2011 at 11:54 AM, Dean Yu<[hidden email]>   wrote:
>>>>
>>>>>   Not against this, but a couple of general comments.
>>>>>
>>>>>  If a new version of the plugin goes into a core release, please make note
>>>>>  of it in the core changelog. I made this request of the
>>>>>  Subversion plugin in
>>>>>  the past. We should extend the practice to all bundled plugins.
>>>>>
>>>>>  People will also need to be educated that the git plugin will now be
>>>>>  subject to version pinning.
>>>>>
>>>>>    -- Dean
>>>>>
>>>>>
>>>>>
>>>>>  On 5/11/11 11:22 AM, "Andrew Bayer"<[hidden email]>   wrote:
>>>>>
>>>>>  Subject says it all - this is directly prompted by
>>>>>  https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
>>>>>  usage of the git plugin (the most of any non-core SCM plugin, and
>>>>>  more than
>>>>>  any non-core plugin other than greenballs and the Analysis plugins), it
>>>>>  makes sense to start including git in the core. This wouldn't mean any
>>>>>  change on the git plugin's development cycle - but we'd only
>>>>>  update the core
>>>>>  distro to use a newer version periodically, as is done with the subversion
>>>>>  plugin currently.
>>>>>
>>>>>  Any opposition to doing this, starting with, say, 1.413?
>>>>>
>>>>>  A.
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>  --
>>  Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
>>
>
>


--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

dan twining-2
So the flaw in Bap's logic about never being able to remove Git in the future is (I think) this?...

If a pre-1.300 customer using SVN upgrades all the way to a 1.X, where there's no SVN functionality at all, without going through an interim version that installed SVN as a plugin, they'll have broken builds, which would only get fixed by installing the SVN plugin manually.

Is this likely?

And is this the sort of thing that can be solved with a 2.0 release, where there's a strong hint that upgrading may require more thought than just blindly upgrading the war?

The programmer in me has a preference for Jenkins to ship without any SCM plugins at all, but the success of things like Jenkins isn't only about code, it's about things like barriers-to-entry, easy-of-use etc. I think from that PoV, shipping with popular SCM plugins is worthwhile. But my opinion is very much humble.



On 12 May 2011 22:44, Kohsuke Kawaguchi <[hidden email]> wrote:

No, because Git plugin was never implemented as a core functionality, we can remove it.

On 05/12/2011 02:39 PM, Bap wrote:
Which means that if we add Git, we'll never be able to remove that either?!

Bap.


Quoting Kohsuke Kawaguchi<[hidden email]>:


 The challenge with removing Subversion and CVS is that those
 functionalities are originally developed in the core, and separated
 into a plugin in version 1.X (I think X was 1.300-ish but I could be
 wrong)

 So if people are upgrading from a version earlier than 1.X and our
 latest release doesn't have the Subversion plugin bundled, this
 installation will run the risk of losing the SCM configuration until
 Subversion plugin is installed.

 I think this data loss is too risky, and that's why we still bundle
 those plugins.


 On 05/12/2011 01:04 PM, Bap wrote:
 As things stand, when I install Jenkins I begin by doing one of two things

 1. I need access to subversion repositories;
 disable CVS, upgrade subversion plugin and install notifiers and
 publishers (and Chuck)

 2. I can use Git :-)
 disable CVS and subversion, install the Git plugin and other plugins
 that I will need/want.

 Is it really necessary to bundle *any* SCM plugins? I have never used
 any that have been bundled.

 If we want people to be able to get started quickly, then one option,
 is to provide the weekly latest and greatest without these plugins and
 only bundle them with the stable build. WDYT?

 Bap.


 Quoting Andrew Bayer<[hidden email]>:

 Agreed wholeheartedly on both counts.

 A.

 On Thu, May 12, 2011 at 11:54 AM, Dean Yu<[hidden email]>   wrote:

 Not against this, but a couple of general comments.

 If a new version of the plugin goes into a core release, please make note
 of it in the core changelog. I made this request of the
 Subversion plugin in
 the past. We should extend the practice to all bundled plugins.

 People will also need to be educated that the git plugin will now be
 subject to version pinning.

  -- Dean



 On 5/11/11 11:22 AM, "Andrew Bayer"<[hidden email]>   wrote:

 Subject says it all - this is directly prompted by
 https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
 usage of the git plugin (the most of any non-core SCM plugin, and
 more than
 any non-core plugin other than greenballs and the Analysis plugins), it
 makes sense to start including git in the core. This wouldn't mean any
 change on the git plugin's development cycle - but we'd only
 update the core
 distro to use a newer version periodically, as is done with the subversion
 plugin currently.

 Any opposition to doing this, starting with, say, 1.413?

 A.







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





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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

nicolas de loof-2
Could we have some auto-povisioning of SCM plugins ? 
i.e. when a (new or existing) job requires SCM plugin XX, automagically install the adequate plugin from update center

This would be cool (but maybe not simple to do, especially without some hot-plugin installation)
Could be a work area for the next jenkins hackathlon ;)

2011/5/13 dan twining <[hidden email]>
So the flaw in Bap's logic about never being able to remove Git in the future is (I think) this?...

If a pre-1.300 customer using SVN upgrades all the way to a 1.X, where there's no SVN functionality at all, without going through an interim version that installed SVN as a plugin, they'll have broken builds, which would only get fixed by installing the SVN plugin manually.

Is this likely?

And is this the sort of thing that can be solved with a 2.0 release, where there's a strong hint that upgrading may require more thought than just blindly upgrading the war?

The programmer in me has a preference for Jenkins to ship without any SCM plugins at all, but the success of things like Jenkins isn't only about code, it's about things like barriers-to-entry, easy-of-use etc. I think from that PoV, shipping with popular SCM plugins is worthwhile. But my opinion is very much humble.



On 12 May 2011 22:44, Kohsuke Kawaguchi <[hidden email]> wrote:

No, because Git plugin was never implemented as a core functionality, we can remove it.

On 05/12/2011 02:39 PM, Bap wrote:
Which means that if we add Git, we'll never be able to remove that either?!

Bap.


Quoting Kohsuke Kawaguchi<[hidden email]>:


 The challenge with removing Subversion and CVS is that those
 functionalities are originally developed in the core, and separated
 into a plugin in version 1.X (I think X was 1.300-ish but I could be
 wrong)

 So if people are upgrading from a version earlier than 1.X and our
 latest release doesn't have the Subversion plugin bundled, this
 installation will run the risk of losing the SCM configuration until
 Subversion plugin is installed.

 I think this data loss is too risky, and that's why we still bundle
 those plugins.


 On 05/12/2011 01:04 PM, Bap wrote:
 As things stand, when I install Jenkins I begin by doing one of two things

 1. I need access to subversion repositories;
 disable CVS, upgrade subversion plugin and install notifiers and
 publishers (and Chuck)

 2. I can use Git :-)
 disable CVS and subversion, install the Git plugin and other plugins
 that I will need/want.

 Is it really necessary to bundle *any* SCM plugins? I have never used
 any that have been bundled.

 If we want people to be able to get started quickly, then one option,
 is to provide the weekly latest and greatest without these plugins and
 only bundle them with the stable build. WDYT?

 Bap.


 Quoting Andrew Bayer<[hidden email]>:

 Agreed wholeheartedly on both counts.

 A.

 On Thu, May 12, 2011 at 11:54 AM, Dean Yu<[hidden email]>   wrote:

 Not against this, but a couple of general comments.

 If a new version of the plugin goes into a core release, please make note
 of it in the core changelog. I made this request of the
 Subversion plugin in
 the past. We should extend the practice to all bundled plugins.

 People will also need to be educated that the git plugin will now be
 subject to version pinning.

  -- Dean



 On 5/11/11 11:22 AM, "Andrew Bayer"<[hidden email]>   wrote:

 Subject says it all - this is directly prompted by
 https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
 usage of the git plugin (the most of any non-core SCM plugin, and
 more than
 any non-core plugin other than greenballs and the Analysis plugins), it
 makes sense to start including git in the core. This wouldn't mean any
 change on the git plugin's development cycle - but we'd only
 update the core
 distro to use a newer version periodically, as is done with the subversion
 plugin currently.

 Any opposition to doing this, starting with, say, 1.413?

 A.







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





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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

Nigel Magnay


On Fri, May 13, 2011 at 10:56 AM, nicolas de loof <[hidden email]> wrote:
Could we have some auto-povisioning of SCM plugins ? 
i.e. when a (new or existing) job requires SCM plugin XX, automagically install the adequate plugin from update center

This would be cool (but maybe not simple to do, especially without some hot-plugin installation)
Could be a work area for the next jenkins hackathlon ;)
 
That's an awesome idea - a bit like how the m2 master pom specifies some plugin versions, but doesn't necessarily download them until needed..

 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PROPOSAL: Moving the git plugin into the core distribution

domi@fortysix.ch
In reply to this post by kohsuke Kawaguchi (CB)
I also think that plugins should not be bundled...
...how many installations prior to 1.300 might be out there? And between 1.300 and 1.400, there is the move from Hudson to Jenkins anyway.
So I think everyone really moving from Hudson to Yenkins looks at least into https://wiki.jenkins-ci.org/display/JENKINS/Upgrading+from+Hudson+to+Jenkins and could be informed.
/Domi


On 12.05.2011, at 23:12, Kohsuke Kawaguchi wrote:

>
> The challenge with removing Subversion and CVS is that those functionalities are originally developed in the core, and separated into a plugin in version 1.X (I think X was 1.300-ish but I could be wrong)
>
> So if people are upgrading from a version earlier than 1.X and our latest release doesn't have the Subversion plugin bundled, this installation will run the risk of losing the SCM configuration until Subversion plugin is installed.
>
> I think this data loss is too risky, and that's why we still bundle those plugins.
>
>
> On 05/12/2011 01:04 PM, Bap wrote:
>> As things stand, when I install Jenkins I begin by doing one of two things
>>
>> 1. I need access to subversion repositories;
>> disable CVS, upgrade subversion plugin and install notifiers and
>> publishers (and Chuck)
>>
>> 2. I can use Git :-)
>> disable CVS and subversion, install the Git plugin and other plugins
>> that I will need/want.
>>
>> Is it really necessary to bundle *any* SCM plugins? I have never used
>> any that have been bundled.
>>
>> If we want people to be able to get started quickly, then one option,
>> is to provide the weekly latest and greatest without these plugins and
>> only bundle them with the stable build. WDYT?
>>
>> Bap.
>>
>>
>> Quoting Andrew Bayer<[hidden email]>:
>>
>>> Agreed wholeheartedly on both counts.
>>>
>>> A.
>>>
>>> On Thu, May 12, 2011 at 11:54 AM, Dean Yu<[hidden email]>  wrote:
>>>
>>>>  Not against this, but a couple of general comments.
>>>>
>>>> If a new version of the plugin goes into a core release, please make note
>>>> of it in the core changelog. I made this request of the Subversion plugin in
>>>> the past. We should extend the practice to all bundled plugins.
>>>>
>>>> People will also need to be educated that the git plugin will now be
>>>> subject to version pinning.
>>>>
>>>>   -- Dean
>>>>
>>>>
>>>>
>>>> On 5/11/11 11:22 AM, "Andrew Bayer"<[hidden email]>  wrote:
>>>>
>>>> Subject says it all - this is directly prompted by
>>>> https://issues.jenkins-ci.org/browse/JENKINS-9598, but given the wide
>>>> usage of the git plugin (the most of any non-core SCM plugin, and more than
>>>> any non-core plugin other than greenballs and the Analysis plugins), it
>>>> makes sense to start including git in the core. This wouldn't mean any
>>>> change on the git plugin's development cycle - but we'd only update the core
>>>> distro to use a newer version periodically, as is done with the subversion
>>>> plugin currently.
>>>>
>>>> Any opposition to doing this, starting with, say, 1.413?
>>>>
>>>> A.
>>>>
>>>>
>>>
>>
>>
>
>
> --
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/

Loading...