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

From Eclipsepedia

Jump to: navigation, search
(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/<id> and projects/<name> in the latter I can get the config, nodes doesn't support configuration at all.
+
**new "REST" api, I personally find it confusing, eg. there is a difference bewteen project/&lt;id&gt; and projects/&lt;name&gt; 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 ListForumsIRC
Bugzilla
Open
Help Wanted
Bug Day
Contribute
Browse Source
Hudson-bust.png 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)