Difference between revisions of "Hudson-ci/community meetings/Feb202012"

From Eclipsepedia

Jump to: navigation, search
(Minutes)
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{hudson|pageTitle=Community Meeting 20-Feb-2012}}  
 
{{hudson|pageTitle=Community Meeting 20-Feb-2012}}  
  
= Agenda  =
+
= Minutes =
  
Add or comment on agenda items here, just prefix the item with your name so we can identify you on the call:
+
 
*2.x?
+
*2.x status?
** What is the status on the next release on the 2.x line?
+
**few minor fixes, nothing substantial - nothing on the user lists.
 +
**reassess at next public meeting unless major bugs reported
 +
**SVN plugin can be released
 +
***doesn't require core release  
 +
***on separate branch
 +
***doing code cleanup, optimization and fixing security bug
 +
***4 JUNIT failures to fix and then release
 +
***within next week
 +
***Steven will send OCA for team members
  
 
*3.0.0  
 
*3.0.0  
** [susan] M2/M3 Release  
+
**M2 - pre-EclipseCon (mar 26th)
** [susan] Website and wiki
+
**M3 for cleanup javascript libs/use JQuery UI
** [susan] Initial Code Contribution
+
**RC May
** [susan] Issues migration
+
**Release June - do we need to tie in as a Technology release? Geoff/Winston think not - Duncan to check.
 +
**Initial Code Contribution
 +
*** 3 rejected
 +
****Duncan working with author for JAXEN and XOM
 +
****JLINE - winston says this has already been removed from distribution and is not needed
 +
*** Groovy remains a problem that needs resolving
 +
**** Winston still looking into it
 +
**** one major problem is its use in Matrix project. security and test harness. If removed from core - will need to be added by plugins (post build etc) that will need to enter a new optional dependency for Hudson.
 +
**** Stapler libraries - primary lib - uses non-standard implementation in github - Hudson has now downgraded to java.net version 1.155 in M1
 +
** New Machines
 +
*** setup and builds started
 +
*** cannot communicate with outside world yet
 +
 
 +
*[Winston] Hudson performance in a enterprise installation, defining best practice, dedicating a release for performance analysis.
 +
** Winston looking into code base - not intended for large installations
 +
*** like Eclipse Foundation - 400 projects, very active, builds every second and very full
 +
*** sluggish and needs reboot every week
 +
**** Gerrit plugin identified as one problem - being worked on
 +
**** memory leaks - remoting, slave builds, class loaders - needs more investigation
 +
**** installed as standalone (not load balanced server) - do use Apache Proxy, but not well optimized in code
 +
*** need to look at architecture - to ascertain why static served by application itself and resources allocation
 +
*** one thread per executor is another are of problem (Hudson loves threads)
 +
**** Henrik suggested checking the differences post Java5 for IO
 +
**** need to edit document - Eclipse Installing Hudson - still says Hudson only needs 1.5 Java
 +
*** Henrik uses monitoring plugin - checks http requests
 +
 
 +
*[Henrik] What are the core team's priorities besides the eclipse migration? upcoming features?
 +
** see [http://www.eclipse.org/projects/project-plan.php?projectid=technology.hudson project plan]  
 +
** enterprise working - as per above and best practice - which containers are best etc.
 +
 
 +
*[Henrik] Out approach to scripting Hudson seems half-hearted at best, how do we improve this? (We need a unified way that plugins can easily attach themselves to)
 +
**CLI works: but is limited in its API plus requires special access through firewalls etc.
 +
**old "REST" api: I can configure a project, but it generally lacks in api
 +
**new "REST" api, I personally find it confusing, eg. there is a difference bewteen project/<id> and projects/<name> in the latter I can get the config, nodes doesn't support configuration at all.
 +
*** wants to use Hudson UI as much as possible - so script as much as possible
 +
**** cant manage hudson nodes (yet) and other missing items in CLI/old REST API
 +
**** new REST API is the future approach for Winston
 +
***** Henrik feels this is very restricted at present
 +
***** problem is how this will work with old plugins that rely on CLI
 +
 
 +
*[Henrik] Collaboration on testing the hudson UI. Right now we have several testing "frameworks" in play for hudson. Right now we have
 +
**hudson-test-framework (part of core): for plugin developers writing their own tests
 +
**hudson-test-harness: Extensive "white-box" testing of hudson
 +
**Winston and Henrik to look into merging these two:
 +
***hudson-test-ui: Small selenium based testing package primarily for cascading projects
 +
***plugin-tester (https://github.com/hudson-plugins/plugin-tester): My prototype for testing a plugin in hudson using selenium tests. Similar to hudson-test-ui except my version tests against multiple hudson cores, and allows each test class to specify which plugins should be installed.
 +
 
 +
* plugins
 +
** winston asked for help moving plugins to BIRT or updating JFreechart
 +
 
 +
* Steven's group - after SVNkit done
 +
**taking ownership of SVN and GIT plugins
 +
**clean up JIRA severe bugs on plugins - for instance 14 blockers for Maven. Could be historical and they can be cleared easily.
 +
**any changes that need to go into Eclipse - give patches to Winston to commit
 +
**those patches then contribute to getting Eclipse commiter status.
 +
 
 +
 
 +
 
 +
<br>
 +
 
 +
'''Attendees:'''
 +
 
 +
Geoff Waymark
 +
 
 +
Brian Fry
 +
 
 +
Henrik Lynggaard Hansen
 +
 
 +
Steve Christou, Jeff, Ryan - SVN plugin
 +
 
 +
Denis Tyrell
  
* [Winston] Hudson performance in a enterprise installation, defining best practice, dedicating a release for performance analysis.
+
Winston Prakash
  
* [Henrik] What are the core team's priorities besides the eclipse migration? upcoming features?
+
Susan Duncan
* [Henrik] Out approach to scripting Hudson seems half-hearted at best, how do we improve this? (We need a unified way that plugins can easily attach themselves to)
+
** CLI works: but is limited in its API plus requires special access through firewalls etc.
+
** old "REST" api: I can configure a project, but it generally lacks in api
+
** new "REST" api, I can get state but I cannot seem to figure out how to configure project, nodes etc. e.g. can't find url for projects config.xml, nodes doesn't support configuration at all.
+

Latest revision as of 14:23, 20 February 2012

Hudson Continuous Integration Server
Website
Download
Community
Mailing ListForumsIRC
Bugzilla
Open
Help Wanted
Bug Day
Contribute
Browse Source
Hudson-bust.png Community Meeting 20-Feb-2012











[edit] Minutes

  • 2.x status?
    • few minor fixes, nothing substantial - nothing on the user lists.
    • reassess at next public meeting unless major bugs reported
    • SVN plugin can be released
      • doesn't require core release
      • on separate branch
      • doing code cleanup, optimization and fixing security bug
      • 4 JUNIT failures to fix and then release
      • within next week
      • Steven will send OCA for team members
  • 3.0.0
    • M2 - pre-EclipseCon (mar 26th)
    • M3 for cleanup javascript libs/use JQuery UI
    • RC May
    • Release June - do we need to tie in as a Technology release? Geoff/Winston think not - Duncan to check.
    • Initial Code Contribution
      • 3 rejected
        • Duncan working with author for JAXEN and XOM
        • JLINE - winston says this has already been removed from distribution and is not needed
      • Groovy remains a problem that needs resolving
        • Winston still looking into it
        • one major problem is its use in Matrix project. security and test harness. If removed from core - will need to be added by plugins (post build etc) that will need to enter a new optional dependency for Hudson.
        • Stapler libraries - primary lib - uses non-standard implementation in github - Hudson has now downgraded to java.net version 1.155 in M1
    • New Machines
      • setup and builds started
      • cannot communicate with outside world yet
  • [Winston] Hudson performance in a enterprise installation, defining best practice, dedicating a release for performance analysis.
    • Winston looking into code base - not intended for large installations
      • like Eclipse Foundation - 400 projects, very active, builds every second and very full
      • sluggish and needs reboot every week
        • Gerrit plugin identified as one problem - being worked on
        • memory leaks - remoting, slave builds, class loaders - needs more investigation
        • installed as standalone (not load balanced server) - do use Apache Proxy, but not well optimized in code
      • need to look at architecture - to ascertain why static served by application itself and resources allocation
      • one thread per executor is another are of problem (Hudson loves threads)
        • Henrik suggested checking the differences post Java5 for IO
        • need to edit document - Eclipse Installing Hudson - still says Hudson only needs 1.5 Java
      • Henrik uses monitoring plugin - checks http requests
  • [Henrik] What are the core team's priorities besides the eclipse migration? upcoming features?
    • see project plan
    • enterprise working - as per above and best practice - which containers are best etc.
  • [Henrik] Out approach to scripting Hudson seems half-hearted at best, how do we improve this? (We need a unified way that plugins can easily attach themselves to)
    • CLI works: but is limited in its API plus requires special access through firewalls etc.
    • old "REST" api: I can configure a project, but it generally lacks in api
    • new "REST" api, I personally find it confusing, eg. there is a difference bewteen project/<id> and projects/<name> in the latter I can get the config, nodes doesn't support configuration at all.
      • wants to use Hudson UI as much as possible - so script as much as possible
        • cant manage hudson nodes (yet) and other missing items in CLI/old REST API
        • new REST API is the future approach for Winston
          • Henrik feels this is very restricted at present
          • problem is how this will work with old plugins that rely on CLI
  • [Henrik] Collaboration on testing the hudson UI. Right now we have several testing "frameworks" in play for hudson. Right now we have
    • hudson-test-framework (part of core): for plugin developers writing their own tests
    • hudson-test-harness: Extensive "white-box" testing of hudson
    • Winston and Henrik to look into merging these two:
      • hudson-test-ui: Small selenium based testing package primarily for cascading projects
      • plugin-tester (https://github.com/hudson-plugins/plugin-tester): My prototype for testing a plugin in hudson using selenium tests. Similar to hudson-test-ui except my version tests against multiple hudson cores, and allows each test class to specify which plugins should be installed.
  • plugins
    • winston asked for help moving plugins to BIRT or updating JFreechart
  • Steven's group - after SVNkit done
    • taking ownership of SVN and GIT plugins
    • clean up JIRA severe bugs on plugins - for instance 14 blockers for Maven. Could be historical and they can be cleared easily.
    • any changes that need to go into Eclipse - give patches to Winston to commit
    • those patches then contribute to getting Eclipse commiter status.



Attendees:

Geoff Waymark

Brian Fry

Henrik Lynggaard Hansen

Steve Christou, Jeff, Ryan - SVN plugin

Denis Tyrell

Winston Prakash

Susan Duncan