Latest revision as of 14:23, 20 February 2012

	Community Meeting 20-Feb-2012

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