Difference between revisions of "Virgo/Community/Minutes-2010-08-24"

From Eclipsepedia

Jump to: navigation, search
m (Discussion)
m (Discussion)
Line 14: Line 14:
 
#* The proposed enhancement to the Kernel Launcher to allow a start policy to be plugged in is now relegated to an enhancement Bugzilla [https://bugs.eclipse.org/bugs/show_bug.cgi?id=323469 323469] (and given low priority).
 
#* The proposed enhancement to the Kernel Launcher to allow a start policy to be plugged in is now relegated to an enhancement Bugzilla [https://bugs.eclipse.org/bugs/show_bug.cgi?id=323469 323469] (and given low priority).
 
# A patch to make the proposed upgrade to Equinox 3.6 simpler was included in the builds ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=322990 Bug 322990]).
 
# A patch to make the proposed upgrade to Equinox 3.6 simpler was included in the builds ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=322990 Bug 322990]).
# Tests of the command extensions to query 'inner frameworks' require JVM options -- and so as not to disturb every integration test how can we make this optional restricted 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 somewhere (maybe on the Wiki) for people to read.
+
# 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. T his 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. T his 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.
 
* 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.

Revision as of 13:01, 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

  1. 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).
  2. A patch to make the proposed upgrade to Equinox 3.6 simpler was included in the builds (Bug 322990).
  3. 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.
  4. Publishing to p2 repositories was discussed again. T his 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'. That is, it is very tempting to put lots of unrelated changes in with the single idea -- simply because they are 'close by' in the code. I don't think anyone is 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 out.

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