On the future of Hudson hosting and infrastructure
Locked
RE: Re: Re: On the future of Hudson hosting and infrastructure
 
|
Mostly because it's a way for Hudson to start leveraging a DVCS while not changing the process on the core.
From: [hidden email] on behalf of David Carr Sent: Wed 6/3/2009 8:58 AM To: [hidden email] Subject: Re: Re: On the future of Hudson hosting and infrastructure What would be the benefit of having the plugins in separate |
Re: Re: On the future of Hudson hosting and infrastructure
|
In reply to this post by davidmc24
On Wed, Jun 3, 2009 at 11:58 AM, David Carr <[hidden email]> wrote:
> What would be the benefit of having the plugins in separate > repositories from Hudson core? It would be nice to benefit from the maven style of plugin resolution, where the Hudson server could be configured with one or several repositories to query for plugins. For in-house development of plugins, this would make it easier to upgrade to new versions of such plugins. James --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
RE: Re: Re: On the future of Hudson hosting and infrastructure
|
|
James Synge wrote:
> It would be nice to benefit from the maven style of plugin resolution, > where the Hudson server could be configured with one or several > repositories to query for plugins. For in-house development of > plugins, this would make it easier to upgrade to new versions of such > plugins. This is a good idea (although David and I were talking about source repositories). Is there an issue request for this? If not, you should submit one.
Justin
|
Re: Re: Re: On the future of Hudson hosting and infrastructure
|
Indeed - another upshot to that would be for situations where the Hudson server doesn't have direct access to the outside world - being able to mirror the plugin repo would be very useful in that case.
A. On Wed, Jun 3, 2009 at 9:15 AM, Edelson, Justin <[hidden email]> wrote:
|
|
In reply to this post by Erik Ramfelt
+1 on JIRA as the issue tracker. JIRA is very easy to use and a lot of open source projects already use it (Apache and Codehaus). It also has good SVN integration (if you add an issue number to an svn comment it will pick it up) and works with Mylyn.
It would also be nice to move the wiki to Confluence (Atlassian's wiki product) and also get an open source license for Clover as well. I'm a big fan of the Atlassian stuff, it's great.
(They do have a build server product as well, heh heh). Ken On Wed, Jun 3, 2009 at 2:13 AM, Erik Ramfelt <[hidden email]> wrote: I feel the same thing, and using the issue tracker is very |
Re: On the future of Hudson hosting and infrastructure
|
For wiki's I prefer the simplier once. Confluence has lots of extra
stuff. So I'd prefer Trac, it's simple and allows links between
everything.
If you want to do code coverage, I'd suggest Coburtura as it's already open source. Ken Liu wrote: +1 on JIRA as the issue tracker. JIRA is very easy to use and a lot of open source projects already use it (Apache and Codehaus). It also has good SVN integration (if you add an issue number to an svn comment it will pick it up) and works with Mylyn. -- Jon Schewe | http://mtu.net/~jpschewe If you see an attachment named signature.asc, this is my digital signature. See http://www.gnupg.org for more information. For I am convinced that neither death nor life, neither angels nor demons, neither the present nor the future, nor any powers, neither height nor depth, nor anything else in all creation, will be able to separate us from the love of God that is in Christ Jesus our Lord. - Romans 8:38-39 |
Re: On the future of Hudson hosting and infrastructure
|
In reply to this post by Andrew Bayer
Andrew Bayer wrote: The more I look at Kenai, the more I think it's the right way to go. While I'm not sure if splitting out the plugins into a separate SCM makes sense, having the freedom to do that sort of thing would be a very good thing. We'd also be able to eat our own cooking even more thoroughly than we do now, with the planned addition of Hudson support to Kenai. And getting JIRA would, of course, be a good thing.I believe that you should be able to. As a side note, I am interested in knowing the rationale on where to host Hudson regardless of whether Kenai is chosen or not (probably more so if it isn't) and where we need to improve our site. Our goal is to build a compeling project hosting service so we need to understand what it means to our users. Thanks! Fred
--
Frederic Jean Sun Microsystems, Inc. |
Re: On the future of Hudson hosting and infrastructure
|
In reply to this post by Andrew Bayer
GlassFish had initially planned to move to Kenai for GFv3 development
but Kenai was not ready then and we decided postpone the move. But Kenai have improved a lot since then and I believe they are ready for large projects now. They are also very eager to help projects move there. Kenai just announced Hudson support yesterday. I'm sure the team would bend backwards to make Hudson move there. - eduard/o Andrew Bayer wrote: > The more I look at Kenai, the more I think it's the right way to go. > While I'm not sure if splitting out the plugins into a separate SCM > makes sense, having the freedom to do that sort of thing would be a very > good thing. We'd also be able to eat our own cooking even more > thoroughly than we do now, with the planned addition of Hudson support > to Kenai. And getting JIRA would, of course, be a good thing. > > I do still have a couple concerns/questions, though. Would we still be > able to have Fisheye hooked up to our SVN repo? I absolutely adore > Fisheye and would really like to be able to keep it. > > A. > > On Tue, Jun 2, 2009 at 6:08 PM, Edelson, Justin > <[hidden email] <mailto:[hidden email]>> wrote: > > One interesting option provided by Kenai is having a single project > with multiple repositories. So the main Hudson could still be in SVN > and the plugins tree could be moved to Git or Mercurial. > > ------------------------------------------------------------------------ > *From:* Frederic Jean [mailto:[hidden email] > <mailto:[hidden email]>] > *Sent:* Tue 6/2/2009 5:39 PM > > *To:* [hidden email] <mailto:[hidden email]> > *Subject:* Re: On the future of Hudson hosting and infrastructure > > Another thing to consider is whether we should also change SCM tool > for the Hudson code. I personally would not mind going from > Subversion to one of the DVCSes. > > Fred > > Frederic Jean wrote: >> We do have a few sizable projects on kenai.com <http://kenai.com>. >> JRuby is one of them. Kenai development itself is hosted on >> kenai.com <http://kenai.com>. >> >> We are looking to provide a Hosted Hudson offering as part of >> Kenai.com. Today's technical session did mention it (although it >> barely gave it justice). The Hudson server they mentioned is >> hosted Kenai's infrastructure. The plan is to host the production >> service on the Sun (probably Oracle by then) cloud. >> >> We certainly hope that Oracle will choose to retain and continue >> to invest in Kenai. I can tell you that there is strong interest >> within Sun to see Kenai thrive and to move major projects over >> from Collabnet based infrastructure to either kenai.com >> <http://kenai.com> proper or distinct deployments of the kenai >> technology. This explains why we invested in the NetBeans/Kenai >> integration (which I am using right now to chat with my teammates >> :) ). >> >> Fred >> >> Edelson, Justin wrote: >>> FWIW, JRuby is a non-trivial project and is now hosted on Kenai. >>> >>> My vague understanding is that Sun is looking to deprecate >>> java.net <http://java.net> in favor of Kenai. I also heard from >>> someone at the JavaOne booth that they had plans soon to make >>> Hudson available to Kenai users shortly. >>> >>> Justin >>> >>> ------------------------------------------------------------------------ >>> *From:* R. Tyler Ballance [mailto:[hidden email]] >>> *Sent:* Tue 6/2/2009 3:28 PM >>> *To:* [hidden email] <mailto:[hidden email]> >>> *Subject:* Re: On the future of Hudson hosting and infrastructure >>> >>> On Tue, Jun 02, 2009 at 04:22:29PM -0600, Frederic Jean wrote: >>> > I'll unfortunately will not be able to attend since I didn't >>> make it to >>> > J1. I would like to suggest moving it to kenai.com >>> <http://kenai.com> (full disclosure: I am >>> > one of the engineers behind kenai.com <http://kenai.com> so >>> I am a little biased... ) >>> >>> <devils-advocate> >>> >>> I've personally never heard of Kenai before, and it does look quite >>> fancy but I am curious as to whether it can "withstand" a larger >>> project >>> like Hudson. Browsing through the projects listing I can't find >>> anything >>> "big" so to speak. >>> >>> Hudson is not huge, but we're talking about thousands of tickets, >>> hundreds of megabytes of source and jar files, and plenty of >>> releases in >>> any given month. >>> >>> I'm curious as to how "proven" and supported a beta (Google beta? >>> or Sun >>> beta?) product from Sun would be to move the entire project over to, >>> instead of a non-beta, established collaboration site like: >>> SourceForge, >>> Berlios, GitHub, etc (or even "our own" infrastructure) >>> >>> </devils-advocate> >>> >>> >>> > >>> > Fred >>> > >>> > Andrew Bayer wrote: >>> > >>> > Hey all - >>> > >>> > So, as we all know, java.net <http://java.net> is >>> extremely unreliable, and that, as a >>> > result, causes a *lot* of problems for Hudson development >>> and usage - >>> > when java.net <http://java.net>'s down, issues can't be >>> filed or modified, users can't >>> > download Hudson, plugins can't be updated, etc... On top >>> of that, the >>> > java.net <http://java.net> issue system frankly sucks - >>> it's just not usable, really. >>> > Given the amount of traffic on the mailing list and in IRC >>> relating to >>> > java.net <http://java.net>, and the difficulties >>> developers have in fixing bugs (and the >>> > difficulties users have in finding whether their issues >>> have already/are >>> > being worked on/etc), I think we've hit the point where we >>> need to have >>> > a real discussion about Hudon's hosting/infrastructure >>> going forward. I >>> > don't know if there are Sun-related reasons requiring >>> Hudson to stay at >>> > java.net <http://java.net>, but if not, moving to another >>> host/issues system/etc is really >>> > something we should pursue. >>> > >>> > Given that we've got a decent chunk of the Hudson dev >>> community in the >>> > Bay Area right now, thanks to JavaOne, I'm wondering if we >>> might want to >>> > actually meet up in person to discuss this. I'm planning >>> to try to crash >>> > the BOF tomorrow night (here's hoping they're not checking >>> badges by >>> > then!), but rtyler has offered to host a sitdown at >>> Slide's offices, at >>> > 2nd and Brannan, maybe after the BOF, or possibly sometime >>> in the >>> > afternoon/earlier in the evening (he thinks he can expense >>> food!). >>> > Kohsuke, is this something worth getting together to >>> discuss? If so, >>> > does sometime tomorrow sound like it would work for you? >>> How about >>> > anyone else in town, be it for JavaOne or whatever? >>> > >>> > A. >>> > >>> > -- >>> > >>> > Frederic Jean >>> > Staff Engineer, SW >>> > >>> > Sun Microsystems, Inc. >>> > 500 Eldorado Blvd >>> > Broomfield, CO 80241 US >>> > Phone 303-223-7949/31084 >>> > Email [hidden email] <mailto:[hidden email]> >>> >>> -- >>> -R. Tyler Ballance >>> Slide, Inc. >>> >> >> -- >> >> *Frederic Jean* >> Staff Engineer, SW >> >> Sun Microsystems, Inc. >> 500 Eldorado Blvd >> Broomfield, CO 80241 US >> Phone 303-223-7949/31084 >> Email [hidden email] <mailto:[hidden email]> >> > > -- > > *Frederic Jean* > Staff Engineer, SW > > Sun Microsystems, Inc. > 500 Eldorado Blvd > Broomfield, CO 80241 US > Phone 303-223-7949/31084 > Email [hidden email] <mailto:[hidden email]> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
|
|
In reply to this post by Jon Schewe
I just realized that the current Hudson wiki is already running on Confluence and appears to be hosted separately from java.net (meaning that performance is fine). So maybe doesn't make sense to discuss changing wikis at this time.
Ken
On Wed, Jun 3, 2009 at 2:26 PM, Jon Schewe <[hidden email]> wrote:
|
Re: On the future of Hudson hosting and infrastructure
|
Were there any discussion duing J1 and if so what was the outcome of it?
//Erik On Thu, Jun 4, 2009 at 00:26, Ken Liu<[hidden email]> wrote: > I just realized that the current Hudson wiki is already running on > Confluence and appears to be hosted separately from java.net (meaning that > performance is fine). So maybe doesn't make sense to discuss changing wikis > at this time. > Ken > > On Wed, Jun 3, 2009 at 2:26 PM, Jon Schewe <[hidden email]> wrote: >> >> For wiki's I prefer the simplier once. Confluence has lots of extra stuff. >> So I'd prefer Trac, it's simple and allows links between everything. >> >> If you want to do code coverage, I'd suggest Coburtura as it's already >> open source. >> >> Ken Liu wrote: >> >> +1 on JIRA as the issue tracker. JIRA is very easy to use and a lot of >> open source projects already use it (Apache and Codehaus). It also has good >> SVN integration (if you add an issue number to an svn comment it will pick >> it up) and works with Mylyn. >> It would also be nice to move the wiki to Confluence (Atlassian's wiki >> product) and also get an open source license for Clover as well. I'm a big >> fan of the Atlassian stuff, it's great. >> >> (They do have a build server product as well, heh heh). >> Ken >> >> On Wed, Jun 3, 2009 at 2:13 AM, Erik Ramfelt <[hidden email]> wrote: >>> >>> I feel the same thing, and using the issue tracker is very >>> frustrating. The issue tracker is actually one of the reasons why I >>> use Mylyn so I dont have to interact with it personally. Im for moving >>> to a new place, but i reccon there might be politics behind it. >>> >>> My wish list for a new place: >>> * Jira as the issue tracker (or anything similar and modern) >>> * Wiki that can use the existing wiki pages or at least do a simple >>> conversion >>> * It can host a Hudson build server, so we can have a place where core >>> and all plugins does not get built in one free style job where it is >>> impossible to get the latest snapshots. >>> >>> regards >>> //Erik >>> >>> >>> >>> On Wed, Jun 3, 2009 at 10:12, Jorg Heymans <[hidden email]> >>> wrote: >>> > +1000 to moving away from java.net ! Here's a rant i had written a >>> > while ago, and after yesterday's outage i was planning to send it out >>> > today : >>> > >>> > <RANT> >>> > >>> > Sometimes i really wonder how much longer Hudson as a project can >>> > afford to stay on dev.java.net without losing momentum or hurt its >>> > user/developer community. There might be some politics behind the >>> > java.net hosting, but really: >>> > >>> > - 10-30 seconds response time for every click ? >>> > - download browsing through a tree widget (??) that takes several >>> > minutes to expand just to get to the plugin you want, that is if it >>> > doesn't time out beforehand ! >>> > - prehistoric issue tracker, dog slow in navigation and search. Last >>> > time i tried to add a comment to an existing issue i gave up after >>> > several minutes of clicking, waiting and searching. >>> > >>> > Hudson is a killer tool that deserves a killer and modern hosting >>> > infrastructure so let's give it one. There are enough alternatives out >>> > there. >>> > </RANT> >>> > >>> > >>> > Feeling much more relieved now, >>> > Jorg >>> > >>> > On Wed, Jun 3, 2009 at 12:14 AM, Andrew Bayer <[hidden email]> >>> > wrote: >>> >> Hey all - >>> >> >>> >> So, as we all know, java.net is extremely unreliable, and that, as a >>> >> result, >>> >> causes a *lot* of problems for Hudson development and usage - when >>> >> java.net's down, issues can't be filed or modified, users can't >>> >> download >>> >> Hudson, plugins can't be updated, etc... On top of that, the java.net >>> >> issue >>> >> system frankly sucks - it's just not usable, really. Given the amount >>> >> of >>> >> traffic on the mailing list and in IRC relating to java.net, and the >>> >> difficulties developers have in fixing bugs (and the difficulties >>> >> users have >>> >> in finding whether their issues have already/are being worked on/etc), >>> >> I >>> >> think we've hit the point where we need to have a real discussion >>> >> about >>> >> Hudon's hosting/infrastructure going forward. I don't know if there >>> >> are >>> >> Sun-related reasons requiring Hudson to stay at java.net, but if not, >>> >> moving >>> >> to another host/issues system/etc is really something we should >>> >> pursue. >>> >> >>> >> Given that we've got a decent chunk of the Hudson dev community in the >>> >> Bay >>> >> Area right now, thanks to JavaOne, I'm wondering if we might want to >>> >> actually meet up in person to discuss this. I'm planning to try to >>> >> crash the >>> >> BOF tomorrow night (here's hoping they're not checking badges by >>> >> then!), but >>> >> rtyler has offered to host a sitdown at Slide's offices, at 2nd and >>> >> Brannan, >>> >> maybe after the BOF, or possibly sometime in the afternoon/earlier in >>> >> the >>> >> evening (he thinks he can expense food!). Kohsuke, is this something >>> >> worth >>> >> getting together to discuss? If so, does sometime tomorrow sound like >>> >> it >>> >> would work for you? How about anyone else in town, be it for JavaOne >>> >> or >>> >> whatever? >>> >> >>> >> A. >>> >> >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [hidden email] >>> > For additional commands, e-mail: [hidden email] >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [hidden email] >>> For additional commands, e-mail: [hidden email] >>> >> >> >> -- >> Jon Schewe | http://mtu.net/~jpschewe >> If you see an attachment named signature.asc, this is my digital >> signature. See http://www.gnupg.org for more information. >> >> For I am convinced that neither death nor life, neither angels nor >> demons, neither the present nor the future, nor any powers, >> neither height nor depth, nor anything else in all creation, will >> be able to separate us from the love of God that is in Christ >> Jesus our Lord. - Romans 8:38-39 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
| Powered by Nabble | See how NAML generates this page |
