Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Agenda: Planning Council face-to-face June 20-21



  • How can we make Ganymede better than Europa?
  • Should we agree to rules about conformance UI guidelines? About framework integration at the UI or API levels?
  • How do we guarantee early adoption of intermediate milestones of between projects rather than waiting for last minute integration testing?
  • How do we ensure API cleanliness (i.e. not relying on other project's internals)?
  • Concerns about the Eclipse Top-Level Project splitting streams (3.x vs. 4.0)?
  • Performance and scalability. Is there consensus ? Actions to improve ? Measurements ?
While I don't want to sound like a broken record, I think that having the capability to consume
across projects at the level of plugins and to do this in an automated way would be a great
leap forward - certainly from what I have experienced in STP-land.  I think this would also
help with the integration testing - faults may be found quicker as plugins become available
and there is a greater chance (maybe!) that consuming projects will consider submitting 
patchs when a single plugin causes issues :)

I had the pleasure of Thomas Hallgren's (Buckminster) company for a day recently, where 
we put together the first  step in converting STP to use a Buckminster-based materialization
system. This was a serious eye-opener for me - I discovered how much STP was consuming
from other projects and got a very clear view of the dependencies across the board. A full
scale changeover proposal will be put to the PMC after Europa.


(#2) Eclipse IP Policy Improvements.
Due to our plenary with the Board, we have the golden opportunity to explain to the Board how the current IP policy is hampering the project's collective ability to do timely, good work. I'd like us to concentrate on two things:
  • Specific situations that caused you and your project pain / hampered development during Europa (e.g., Ant 1.7 and the STP project's need for external third-party libraries). General statements like "it's too hard" are less useful than specifics, so please take the opportunity to poll the committers on your project and get as much detail as you can.
  • Specific suggestions that you all have for improving the IP policy and process - starting from the fact that we're always going to have an IP policy, how can we make it better? Better documentation? Examples? Tools? Relaxed constraints in certain situations?

The IP process has some kinks and I think I can safely state the symptoms, but not necessarily
the malaise or the cure (if one exists). One issue is that the process is human-resource intensive
and during a big bang of a release like Europa, there is bound to be treacling of the throughput.
Naturally, only so much can be automated and the rest must depend on humans, and bursty load
characteristics are always going to occur.

Another is that while so much of the process is clearly and succintly documented (and much 
praise and appreciation for that), there are some pieces that are folkloric in nature, i.e. that
need to be formalized.  STP ran into this when we said that we intended to ship Apache software
that was at RC or milestone stage, rather than at a full sanctioned release point.

A third concern, again STP specific, is how we are going to keep up with constant release 
churn for runtimes that we consume - runtimes that have ad-hoc or little tooling stand 
to benefit from STP's efforts, and of course STP benefits from the runtimes. Unfortunately,
runtimes can be very, well, unfussy is kind word, about the amount of other OSS projects
that they consume - in fact 'bonding' of OSS projects is a community reach-out and relationships
between projects, initially driven by functional re-use, is a good thing in general, but it means
a big load on the shoulders of the IP team.  

On the last concern, I think that there is some room for a 'tiered system' where, along with 
a bulletproofed EPL-sanctioned download, it should be possible for projects to construct
and maintain, on the Eclipse infrastructure, a non-bulletproofed distribution of software
that is friendly-licensed and which can be refreshed regularly with the need  for a full 
discovery process to be applied at each refresh.  These friendly distributions would 
effectively form the bundle of prerequisites for the Eclipse technology being downloaded.
On an ongoing basis, the elements of the bundle will be tracked through the IP process
and be orbitized, so that there is a constant osmosis of these external dependencies 
through the Eclipse process and yet users can still pull down the third-party elements
they need to get up and going with the tooling as soon as possible (the 15 minutes is now
down to 7, remember).

Looking forward to the discussions at the meeting,

  best regards,
     Oisin
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Back to the top