View source for DTP PMC Meeting, July 22, 2008

&larr;[[DTP PMC Meeting | Back to DTP PMC Meeting Page]]
==Attendees==
*Brian Fitzpatrick
*Linda Chan
*John Graham
*Sheila Sholars

==Regrets==

==Agenda==
*Tagging for the 1.6.1 M1/M2 release
*Planning for next major release (Io/Galileo/1.7/2.0/June 2009)
*Open discussion

==Minutes==
*Tag issue
**The case where someone delivers a change to the M1 branch, but not Head, would be an accident. 
**John is proposing that we write a Java program that grabs the map files and compares them to make sure that fixes are delivered to both streams and that versioning is correct. The Head branch must always have the higher version number. 
**Ask committer to notate in the bug to indicate which versions were tagged in both branches with the same tag. This would indicate that the change is more atomic, even across branches. So long as the head stream is at a higher version, we shouldn't conflict. 
**Key point - Head/M2 stream must have the higher version than the M1 branch to avoid any update site confusion
**As long as the timestamps in the two streams are equivalent or the newer branch is higher, we should be fine.
**Any check-in should always make the head stream have the later timestamp. 
**2 conditions - check in to both places and the head timestamp should be greater than the timestamp for the same plug-in in the older stream
**'''make sure deliver fixes to both streams - if the change goes to M1 it must also go to Head, but not the other way'''
**'''change for M1 only is conceivable, but needs to be justified'''
**'''set timestamp in M1 stream to the shanghai time and the head/M2 branch to timestamp+5 minutes'''
**'''or update the third number in the version - but only do it once in a release'''
*abiding by version rules is important
**what's the policy on updating the version #s? http://wiki.eclipse.org/DTP_Plug-in_Versioning_Policy
**how do you know if the plugin version has been updated once per release or not? look to see when the manifest.mf file was **updated last in the history
**need to establish a better discipline to update the correct segment of the version number
**version comparison tool around to compare current version & past version - generates a report
**possibly use the report generated at the end of the release (send to team leads) and check to make sure things are as expected

==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
**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

[[Category:Data Tools Platform]]