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) |
|||
| Line 4: | Line 4: | ||
Add or comment on agenda items here, just prefix the item with your name so we can identify you on the call: | Add or comment on agenda items here, just prefix the item with your name so we can identify you on the call: | ||
| − | *2.x? | + | |
| − | ** What is the status on the next release on the 2.x line? | + | *2.x? |
| + | **What is the status on the next release on the 2.x line? | ||
*3.0.0 | *3.0.0 | ||
| − | ** [susan] M2/M3 Release | + | **[susan] M2/M3 Release |
| − | ** [susan] Website and wiki | + | **[susan] Website and wiki |
| − | ** [susan] Initial Code Contribution | + | **[susan] Initial Code Contribution |
| − | ** [susan] Issues migration | + | **[susan] Issues migration |
| − | * [Winston] Hudson performance in a enterprise installation, defining best practice, dedicating a release for performance analysis. | + | *[Winston] Hudson performance in a enterprise installation, defining best practice, dedicating a release for performance analysis. |
| − | * [Henrik] What are the core team's priorities besides the eclipse migration? upcoming features? | + | *[Henrik] What are the core team's priorities besides the eclipse migration? upcoming features? [http://www.eclipse.org/projects/project-plan.php?projectid=technology.hudson project plan] |
| − | * [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) | + | *[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. | + | **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 | + | **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/ | + | **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. |
| − | * [Henrik] Collaboration on testing the hudson UI. Right now we have several testing "frameworks" in play for hudson. Right now we have | + | *[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): Don't know it but assume it is for plugin developers writing their own tests | + | **hudson-test-framework (part of core): Don't know it but assume it is for plugin developers writing their own tests |
| − | ** hudson-test-harness: Extensive "white-box" testing of hudson | + | **hudson-test-harness: Extensive "white-box" testing of hudson |
| − | ** hudson-test-ui: Small selenium based testing package primarily for cascading projects | + | **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. | + | **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. |
I suggest we look into unifying hudson-test-ui with my prototype, but where should it be located and which plugins should be tested?. (and we should try to run the plugin's own tests against out hudson cores) | I suggest we look into unifying hudson-test-ui with my prototype, but where should it be located and which plugins should be tested?. (and we should try to run the plugin's own tests against out hudson cores) | ||
Revision as of 10:27, 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 |
|---|
Agenda
Add or comment on agenda items here, just prefix the item with your name so we can identify you on the call:
- 2.x?
- What is the status on the next release on the 2.x line?
- 3.0.0
- [susan] M2/M3 Release
- [susan] Website and wiki
- [susan] Initial Code Contribution
- [susan] Issues migration
- [Winston] Hudson performance in a enterprise installation, defining best practice, dedicating a release for performance analysis.
- [Henrik] What are the core team's priorities besides the eclipse migration? upcoming features? project plan
- [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.
- [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): Don't know it but assume it is for plugin developers writing their own tests
- hudson-test-harness: Extensive "white-box" testing of hudson
- 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.
I suggest we look into unifying hudson-test-ui with my prototype, but where should it be located and which plugins should be tested?. (and we should try to run the plugin's own tests against out hudson cores)