Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "DTP PMC Meeting, July 15, 2008"

(New page: ← Back to DTP PMC Meeting Page ==Attendees== *Brian Fitzpatrick *Linda Chan *John Graham *Sheila Sholars ==Regrets== ==Agenda== *The early release question (Loi...)
 
(Minutes)
 
(One intermediate revision by the same user not shown)
Line 15: Line 15:
  
 
==Minutes==
 
==Minutes==
 +
*Discussed the Bugzilla "scrubbing" pass we're going to ask team leads and committers to start next week
 +
**Bugs typically fall into three categories - No Target Milestone, with a Target Milestone set, and set to Future
 +
**We want to go back to all bugs set for previous releases (0.7, 0.9, 1.0, 1.5 and their related maintenance version #s) and see if the bugs are still appropriate.
 +
**If appropriate to Ganymede and forward, work on it for the maintenance release or save for the next major release.
 +
**If things have changed (i.e. UI or API) to make the bug not an issue any more, set to a resolution of "Obsolete"
 +
**If it might be valid, but we're not looking to fix it in the maintenance release of by June of next year, set to a resolution of "Won't Fix"
 +
**Remember to add a tag of "helpwanted" if there's a bug you run across that is still valid, but we're not planning on fixing unless we get some additional help for it.
 +
*Discussed the early or off-cycle patch/release requested by Loic & IBM.
 +
**Want to keep criteria generic so we don't paint ourselves into a corner going forward.
 +
**Criteria includes:
 +
***Number of bugs/patches and quality/severity of bugs. A small number may not warrant a release, but if it's one major bug (like the Data Source Explorer not functioning) it would warrant a fix.
 +
***Who's requesting the early/off-cycle release? If it's someone or an organization who's been very active in the community, that would most likely be considered over a request from someone who's been relatively quiet in the community.
 +
***Who's going to "pay" for the release with respect to actually doing the work and then testing?
 +
***When is the release requested for? Is it near an already planned release? Or does it fall between releases, such as between the February (SR2) maintenance release and the June release?
 +
***How will the early/off-cycle release be distributed? Via download zips or an update site?
 +
**Sheila was going back to Loic & the IBMers to determine if the proposal from yesterday would be acceptable or not. The dates and proposal were as follows:
 +
***To summarize ('cause I think I just threw enough dates in there it looks like they were in a blender on puree)...
 +
****1) We shift the DTP 1.6.1 M1 date to August 1, 2008, which is effectively the 7/31 SH build.
 +
****2) We lock down changes to the 1.6/1.6.1 stream from Aug 1 to Aug 7, except for any critical fixes deemed required for the milestone.
 +
****3) On Aug 7, we release 1.6.1 M1 publicly and re-open the 1.6/1.6.1 stream for continued development.
 +
****4) With the proposed rampdown for the maintenance release train, we shift the DTP 1.6.1 M2 date to August 29 (effectively the August 28th SH build for us).
 +
****5) From that point forward, we roll with the standard rampdown policy for RC1 (effectively our M2) and RC2 of the SR1 release train.
 +
***The goal here is not to force an early release of 1.6.1 if we can help it and just adjust dates for the M1 & M2 milestone builds a bit.
 +
*John mentioned he had checked on the JBoss/Red Hat ODA driver and not received very favorable information about donating it back to DTP due to issues of a political nature at Eclipse rather than technical concerns.
  
 
==Action Items==
 
==Action Items==

Latest revision as of 17:53, 15 July 2008

Back to DTP PMC Meeting Page

Attendees

  • Brian Fitzpatrick
  • Linda Chan
  • John Graham
  • Sheila Sholars

Regrets

Agenda

  • The early release question (Loic's 1.6.0.1 request)
  • Setting up a "scrubbing" pass during the maintenance release
  • Planning for next major release
  • Open discussion

Minutes

  • Discussed the Bugzilla "scrubbing" pass we're going to ask team leads and committers to start next week
    • Bugs typically fall into three categories - No Target Milestone, with a Target Milestone set, and set to Future
    • We want to go back to all bugs set for previous releases (0.7, 0.9, 1.0, 1.5 and their related maintenance version #s) and see if the bugs are still appropriate.
    • If appropriate to Ganymede and forward, work on it for the maintenance release or save for the next major release.
    • If things have changed (i.e. UI or API) to make the bug not an issue any more, set to a resolution of "Obsolete"
    • If it might be valid, but we're not looking to fix it in the maintenance release of by June of next year, set to a resolution of "Won't Fix"
    • Remember to add a tag of "helpwanted" if there's a bug you run across that is still valid, but we're not planning on fixing unless we get some additional help for it.
  • Discussed the early or off-cycle patch/release requested by Loic & IBM.
    • Want to keep criteria generic so we don't paint ourselves into a corner going forward.
    • Criteria includes:
      • Number of bugs/patches and quality/severity of bugs. A small number may not warrant a release, but if it's one major bug (like the Data Source Explorer not functioning) it would warrant a fix.
      • Who's requesting the early/off-cycle release? If it's someone or an organization who's been very active in the community, that would most likely be considered over a request from someone who's been relatively quiet in the community.
      • Who's going to "pay" for the release with respect to actually doing the work and then testing?
      • When is the release requested for? Is it near an already planned release? Or does it fall between releases, such as between the February (SR2) maintenance release and the June release?
      • How will the early/off-cycle release be distributed? Via download zips or an update site?
    • Sheila was going back to Loic & the IBMers to determine if the proposal from yesterday would be acceptable or not. The dates and proposal were as follows:
      • To summarize ('cause I think I just threw enough dates in there it looks like they were in a blender on puree)...
        • 1) We shift the DTP 1.6.1 M1 date to August 1, 2008, which is effectively the 7/31 SH build.
        • 2) We lock down changes to the 1.6/1.6.1 stream from Aug 1 to Aug 7, except for any critical fixes deemed required for the milestone.
        • 3) On Aug 7, we release 1.6.1 M1 publicly and re-open the 1.6/1.6.1 stream for continued development.
        • 4) With the proposed rampdown for the maintenance release train, we shift the DTP 1.6.1 M2 date to August 29 (effectively the August 28th SH build for us).
        • 5) From that point forward, we roll with the standard rampdown policy for RC1 (effectively our M2) and RC2 of the SR1 release train.
      • The goal here is not to force an early release of 1.6.1 if we can help it and just adjust dates for the M1 & M2 milestone builds a bit.
  • John mentioned he had checked on the JBoss/Red Hat ODA driver and not received very favorable information about donating it back to DTP due to issues of a political nature at Eclipse rather than technical concerns.

Action Items

  • Hold off on RC milestones for 1.6.1 unless we get a better understanding of why we might need them
  • New dependencies need to be approved, especially those across other projects, orbit, 3rd party, or whatever - need to write up as part of the DTP policies and procedures
  • Need to add some policy regarding extension point documentation. Declare that if new extension points are added, they must have documentation by the mid-point milestone.

Tabled for Later Discussion

  • Discuss after Ganymede release
    • Discuss DTP charter change to simplify addition of a committer to two or more subprojects at the same time without going through separate committer elections
    • Perhaps in the future come up with a Component architecture document that shows DTP dependencies to consumers
    • Schedule a "scrubbing" pass of the bug backlog after 1.6 (over the summer) to close bugs that we won't ever fix (minor tweaks, things that have been obsoleted along the way, etc.) to try and reduce the bug count
    • Things to consider for next major release (June 2009) - JDK 1.4 end of life, move to JDK 1.5 in next release? Depends on platform support. Something to discuss going forward

Back to the top