Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Hudson-ci/community meetings/Feb202012"
(→Agenda) |
(→Minutes) |
||
(14 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}} | ||
− | = | + | = Minutes = |
− | + | ||
− | *2.x? | + | *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 | *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 [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 Prakash | ||
− | + | Susan Duncan |
Latest revision as of 14:23, 20 February 2012
Hudson Continuous Integration Server | |
Website | |
Download | |
Community | |
Mailing List • Forums • IRC • mattermost | |
Issues | |
Open • Help Wanted • Bug Day | |
Contribute | |
Browse Source |
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
- 3 rejected
- 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
- Winston looking into code base - not intended for large installations
- [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
- wants to use Hudson UI as much as possible - so script as much as possible
- [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