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 "Virgo/Community/Minutes-2010-08-24"
m (→Discussion) |
m (→Discussion) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 16: | Line 16: | ||
# Tests of the command extensions to query 'inner frameworks' require JVM options -- and so as not to disturb every integration test we want to restrict this to a single project (or the projects that need it)? I suggested there is a way already (which we use when profiling or eternally debugging from Eclipse) and I'll put this up soon (on the Wiki) for others to know about. | # Tests of the command extensions to query 'inner frameworks' require JVM options -- and so as not to disturb every integration test we want to restrict this to a single project (or the projects that need it)? I suggested there is a way already (which we use when profiling or eternally debugging from Eclipse) and I'll put this up soon (on the Wiki) for others to know about. | ||
# Publishing to p2 repositories was discussed again. This is an enhancement we have been considering for some time, though there are a number of interesting issues around it. One is that the p2 clients (for resolving from and publishing to repositories) are klunky and put a burden on otherwise simple build/test scripts in ant/ivy. Another is that we need to understand the requirements of builds published thereby -- where do they go and who uses them? Are they for resolution in builds, or run-time resolving? Or are they only for primary products -- e.g. RELEASEs of the kernel? This topic will require both technical refinement and better requirement analysis before it becomes viable. A series of (enhancement) bugzillas might help to stabilise a direction. | # Publishing to p2 repositories was discussed again. This is an enhancement we have been considering for some time, though there are a number of interesting issues around it. One is that the p2 clients (for resolving from and publishing to repositories) are klunky and put a burden on otherwise simple build/test scripts in ant/ivy. Another is that we need to understand the requirements of builds published thereby -- where do they go and who uses them? Are they for resolution in builds, or run-time resolving? Or are they only for primary products -- e.g. RELEASEs of the kernel? This topic will require both technical refinement and better requirement analysis before it becomes viable. A series of (enhancement) bugzillas might help to stabilise a direction. | ||
| − | + | # There are still potentially some performance issues during builds (particularly the web build) running out of perm-gen space in the middle of a sequence of integration tests. We hope that SAP can put up their findings. The Dev team have spotted some leaks and fixed them recently, though more analysis and profiling can only help. | |
| − | + | # File structure changes as preliminary to Eclipse integration: | |
| − | + | #* Boris ''et al'' have found that some files in kernel/lib (or is it lib/kernel) are not necessary, and so more things are getting on the classpath than need to be there. Any reductions of unnecessary stuff is welcome. | |
| − | + | #* I wasn't sure if there other file structure changes needed, or desirable. | |
| − | After the discussion I made the general point that Bugzillas that include patches or enhancements can often include 'too much'. | + | After the discussion I made the general point that Bugzillas that include patches or enhancements can often include 'too much'. It is tempting to include unrelated changes with another idea -- simply because they are 'close by' in the code. I don't think anyone is particularly at fault here, but if patches are ruthlessly reduced to the smallest possible units they are more likely to get in. Small is beautiful, and minimal is marvellous. |
| − | So, silly as it may seem, if you spot a single line correction (or 'improvement') while writing your magnum opus, please resist the urge to 'just put it in'. If a single line bugzilla patch is raised, it can get in much more easily than a collection of changes, and is quicker and simpler for all concerned. If the change is unrelated, or just 'independent' in the sense that it ''could'' be made separately without harm, then please separate it | + | So, silly as it may seem, if you spot a single line correction (or 'improvement') while writing your ''magnum opus'', please resist the urge to 'just put it in'. If a single line bugzilla patch is raised, it can get in much more easily than a collection of changes, and is quicker and simpler for all concerned. If the change is unrelated, or just 'independent' in the sense that it ''could'' be made separately without harm, then please ''do'' separate it. That way it won't be 'caught up' in a long discussion (and possible rejection) that has nothing to do with it. |
== Status == | == Status == | ||
Latest revision as of 13:07, 24 August 2010
Attendees
- Steve Powell - VMware
- Borislav Kapukaranov - SAP
Only two again this week (Hristo is on vacation) but Boris (a colleague of Hristo's) made up for this in a series of great issues...
Discussion
- The Kernel Launcher and the Eclipse Launcher:
- Boris explained that launching the Virgo bundles embedded in an Eclipse instance will not require considerable modifications to the Kernel Launcher, though I pointed out that the bundles initiated here are not necessarily suitable for concurrent and unpredictable order of start -- still it would be nice to try it.
- The proposed enhancement to the Kernel Launcher to allow a start policy to be plugged in is now relegated to an enhancement Bugzilla 323469 (and given low priority).
- A patch to make the proposed upgrade to Equinox 3.6 simpler was included in the builds (Bug 322990).
- Tests of the command extensions to query 'inner frameworks' require JVM options -- and so as not to disturb every integration test we want to restrict this to a single project (or the projects that need it)? I suggested there is a way already (which we use when profiling or eternally debugging from Eclipse) and I'll put this up soon (on the Wiki) for others to know about.
- Publishing to p2 repositories was discussed again. This is an enhancement we have been considering for some time, though there are a number of interesting issues around it. One is that the p2 clients (for resolving from and publishing to repositories) are klunky and put a burden on otherwise simple build/test scripts in ant/ivy. Another is that we need to understand the requirements of builds published thereby -- where do they go and who uses them? Are they for resolution in builds, or run-time resolving? Or are they only for primary products -- e.g. RELEASEs of the kernel? This topic will require both technical refinement and better requirement analysis before it becomes viable. A series of (enhancement) bugzillas might help to stabilise a direction.
- There are still potentially some performance issues during builds (particularly the web build) running out of perm-gen space in the middle of a sequence of integration tests. We hope that SAP can put up their findings. The Dev team have spotted some leaks and fixed them recently, though more analysis and profiling can only help.
- File structure changes as preliminary to Eclipse integration:
- Boris et al have found that some files in kernel/lib (or is it lib/kernel) are not necessary, and so more things are getting on the classpath than need to be there. Any reductions of unnecessary stuff is welcome.
- I wasn't sure if there other file structure changes needed, or desirable.
After the discussion I made the general point that Bugzillas that include patches or enhancements can often include 'too much'. It is tempting to include unrelated changes with another idea -- simply because they are 'close by' in the code. I don't think anyone is particularly at fault here, but if patches are ruthlessly reduced to the smallest possible units they are more likely to get in. Small is beautiful, and minimal is marvellous.
So, silly as it may seem, if you spot a single line correction (or 'improvement') while writing your magnum opus, please resist the urge to 'just put it in'. If a single line bugzilla patch is raised, it can get in much more easily than a collection of changes, and is quicker and simpler for all concerned. If the change is unrelated, or just 'independent' in the sense that it could be made separately without harm, then please do separate it. That way it won't be 'caught up' in a long discussion (and possible rejection) that has nothing to do with it.
Status
- CQs (Contribution Questionnaires -- carriers of the IP process) are proceeding apace; the largest of these being the Tomcat dependencies.
- We are upgrading to Tomcat 6.0.29 (embedded version) in Gemini Web and Virgo (which depends upon GW). This involves lots of IP work, and also publishing modified bundles for our use in the SpringSource EBR. The original intent was to use 6.0.28, but there are issues with this release which mean that we have had to change horses in mid-ip-stream.
- Contributions are still coming, and the number of open issues is increasing. Most, but not all, of these would disrupt the Virgo Release schedule, which is already a bit tight, so quite a few of these changes will not see the light of day until after October (at the earliest). This should not stop discussion, and we are delighted to see SAP strongly represented in these activities.
- Glyn is on vacation again and will back next week.
- Chris is also away, and will return in two weeks.
- Next Monday is a public holiday here in the UK, so Glyn and I may be a little soporific on the call the day after! (Well I might be, Glyn seems never to flag.)
Hope to hear from you next week!
Steve Powell