[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] RE: [cross-project-issues-dev]Re-spin process / DSDP-TM Re-spin request

Part of the integration testing effort could be mitigated, and in an automated fashion, if projects providing conformance tests, or at least that's my theory.  For frameworks that provide interfaces to be implemented by others it's difficult to ensure that an implementation conforms to the provided contract.  This is left up to one's own interpretation of the specification and puts the testing requirements and a through understanding of the specification on the implementer.  If projects provided conformance tests (e.g. Java TCK) this might ease some of the burden.

Again, this is just a theory but is something we're exploring in JFace Data Binding[1].  I realize that this won't solve all the issues, or even the majority, but it puts the testing of a specification into the hands of the framework and not the consumer thus removing some variance that can occur between implementations and hopefully work out some bugs closer to development time.  Plus if the tests, test harnesses, and required infrastructure are already written I think more developers would test their code.

-brad

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=182059

On Jul 16, 2007, at 12:07 PM, Mike Milinkovich wrote:

OK, that’s one good idea.

 

Anyone with others?

 

Mike Milinkovich

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@xxxxxxxxxxx

 

From: Gaff, Doug [mailto:doug.gaff@xxxxxxxxxxxxx]
Sent: Monday, July 16, 2007 10:05 AM
To: mike.milinkovich@xxxxxxxxxxx; Cross project issues; eclipse.org-planning-council
Cc: epp-dev@xxxxxxxxxxx; Mylyn developer discussions
Subject: RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev]Re-spin process / DSDP-TM Re-spin request

 

Employ Testers.  Seriously.

 

Obviously, the challenge that most projects have is that our plates are full just releasing our own stuff.  Doing a lot of cross-project integration testing falls to a close second.  If there were a few persona-based testers available, that would really help.

 

Doug G

 

From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Mike Milinkovich
Sent: Monday, July 16, 2007 9:49 AM
To: 'eclipse.org-planning-council'; 'Cross project issues'
Cc: epp-dev@xxxxxxxxxxx; 'Mylyn developer discussions'
Subject: RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev]Re-spin process / DSDP-TM Re-spin request

 

+1

 

To be honest, I didn’t even realize this was in question. Projects can decide to be in/out of any particular release train and always have the freedom to push out intermediate releases if it makes sense for their projects and its community.

 

I would like to pick up on Doug’s desire to see more integration testing between the projects involved in the release train. What can we at the Foundation / EMO do to help make that wish a reality?

 

Mike Milinkovich

Office: +1.613.224.9461 x228

Mobile: +1.613.220.3223

mike.milinkovich@xxxxxxxxxxx

 

From: eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Jeff McAffer
Sent: Thursday, July 12, 2007 10:19 PM
To: Cross project issues
Cc: 'Mylyn developer discussions'; 'Cross project issues'; eclipse.org-planning-council; epp-dev@xxxxxxxxxxx
Subject: RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin request

 


I agree as well.  The release trains are value add and need to really mean something.   Projects should do what they do, release when they release, and, from time to time, may choose to participate in a train.  The release trains are a great thing for consumers but, as Doug points our, they are not the only way of releasing something.

Jeff

Doug Schaefer <DSchaefer@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

07/09/2007 01:19 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To

"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>, "'Cross project issues'" <cross-project-issues-dev@xxxxxxxxxxx>

cc

"'Mylyn developer discussions'" <mylyn-dev@xxxxxxxxxxx>, epp-dev@xxxxxxxxxxx

Subject

RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev]        Re-spin process / DSDP-TM Re-spin        request

 




I agree, Mik. Different projects at different stages have different needs for release frequency. For the CDT, we would really like to stay annually to make sure the vendors adopting the CDT have predictable quality and schedule. However, having said that, we do get tempted to releasing more often but then we would lose the stability that having firm yearly dates gives us.
 
I think we may be losing sight of what these simultaneous releases were meant to be. Nothing is stopping you from releasing quarterly on your own. We certainly aren’t making these trains the only release vehicle available to projects, just a predictable one that commercial vendors redistributing Eclipse projects can depend on. For their benefit (being one of them ;), I’d love to see our next step in the evolution of the trains be doing actual integration testing between the projects. If the projects are releasing randomly, we would never be able to achieve that.
 
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead,
http://cdtdoug.blogspot.com

 



From: eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Mik Kersten
Sent:
Monday, July 09, 2007 12:55 PM
To:
'eclipse.org-planning-council'; 'Cross project issues'
Cc:
epp-dev@xxxxxxxxxxx; 'Mylyn developer discussions'
Subject:
RE: [eclipse.org-planning-council] RE: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin request

 
Just thought of a simpler way of stating this.  
 
While the SDK is mature enough for an annual release cycle, other projects can benefit the community by providing more frequent releases.  Both biannual and quarterly update schedules overlap well with the annual release train.  Since Mylyn is continuing to evolve rapidly, we would like Europa and EPP to consider supporting quarterly updates.
 
Mik
 
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Mik Kersten
Sent:
Monday, July 09, 2007 9:26 AM
To:
'Cross project issues'
Cc:
'Mylyn developer discussions'; 'eclipse.org-planning-council'; epp-dev@xxxxxxxxxxx
Subject:
[eclipse.org-planning-council] RE: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin request

 
+1 for increased frequency and figuring out how to coordinate this with EPP.  Here is Mylyn's point of view.  
 
Since we are part of the EPP distros it would be good to have a well-defined mechanism and process for getting the latest and greatest to users via EPP while supporting the Ganymede train and Europa maintenance releases.  Current constraints we see:
·  Platform and other core projects get adopted every 6 weeks by early adopters, but only yearly by the majority.  As long as automatic update checking is not turned on by default we cannot count on majority users getting new versions via update sites.
·  Some projects like Mylyn are evolving rapidly and ensure that majority users are always best off using the latest.
·  Many or most integrators don't want to port more than once a year, whereas we foresee the need to make breaking API changes, i.e. moving from 2.0 to 3.0, at some point during the Ganymede cycle.
·  Maintaining more than two streams is a pain.
 
Here's our current idea for how to accommodate these constraints, and I'm wondering how this fits for other projects and Europa/Ganymede/EPP planning.
1)      Support Platform 3.3 and 3.4 with a single stream for as long as possible, branch when necessary.  This means that we will be releasing the same version for the Ganymede train and Europa updates.  (We have used this scheme the past couple of years and ended up branching around Platform M4 each time because we are quite dependent on internals and API additions).
2)      Follow the 6 week schedule but make releases available to majority users on a quarterly basis, i.e. every other Ganymede release.  For Mylyn this would mean something like the following post-Europa schedule:
·  Week 6: Mylyn 2.1M (pushed to Mylyn update site only, i.e. can only count on early adopters getting it)
·  Week 12: Mylyn 2.1 (pushed to Europa/Ganymede/EPP sites)
·  Week 18: Mylyn 2.2M
·  Week 24: Mylyn 2.2
·  Week 30: Mylyn 2.3M
·  Week 36: Mylyn 2.3
·  Week 42: Mylyn 3.0 RC0 (incorporate API changes)
·  Weeks 48-52: Mylyn 3.0 (final)
 
Effects of this would be:
·  EPP could incorporate Mylyn updates once per quarter ensuring that the majority of users can work from the latest and greatest.
·  The “2.x” releases would have the same quality bar as Europa.
·  The “2.xM” would allow us to get feedback on UI changes from early adopters before releasing them to majority users.
·  Integrators only have to port once at the end of the cycle, at the same time that they would be moving to the 3.4 Platform.  
 
Mik
 
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of John Arthorne
Sent:
Monday, July 09, 2007 8:33 AM
To:
Cross project issues
Subject:
Re: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin request

 

Using the same update site makes sense to me. I guess the question then is how often the staging site is migrated to the release site. Did this only happen twice for Callisto (once in the fall and once in the winter)? Perhaps this frequency needs to be increased to accomodate the various release rhythms of the projects involved. The other important element in the coordinated release is the EPP packages. I would love to see a well known place for staging the EPP bits, so we can invite the community to grab the latest packages and participate in testing prior to release dates.

Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

07/09/2007 11:17 AM

 

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

 

To

Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>, "eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>

cc

 

Subject

Re: [cross-project-issues-dev] Re-spin process / DSDP-TM Re-spin         request


 

 

 

 





John,
My plan for the Europa Fall Maintenance Update Site was to use the same update site as the Europa release - I think that's what we did for Callisto and it makes sense for Europa as well. We'll Europa-matic build into the Europa staging site (as we did for the major release) until we are collectively happy with the bits and then we will upgrade those staging site bits to the release site.

I am already doing Europa-matic builds for the maintenance release (or the re-spin, or whatever we decide): the results are in the usual place: http://dash.eclipse.org/~bfreeman/europa/

If you think we should do something else (a separate Fall Maintenance Update Site, separate from the release site), let's talk about that...

- Bjorn

John Arthorne wrote:
I think this debate about respins is only happening because we don't yet have the Europa fall update site set up yet.  In the absence of this, Europa respins are the only way to get our critical fixes out there. I suggest we create a Europa fall update site as soon as possible so we can put the Europa June 29th release behind us.

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list