Equinox/Meeting Minutes/20091013
< Equinox | Meeting Minutes
Revision as of 10:59, 13 October 2009 by Tjwatson.us.ibm.com (Talk | contribs)
Agenda
- Left over from last week: Ways to inject through extension registry and e4.
- What to do about logging and tracing enhancements
- Retention policy
Attendees
- Tom
- DJ
- Pascal
- Andrew
- Jeff
- Simon
Minutes
- Retention policy
- Once released always available, never delete old content
- One repository containing SR1, SR2, SR3 for Galileo
- One repository for Helios etc.
- Eclipse project retention policy
- For updates of the IDE
- Folks want the latest to show up for doing updates
- For builds
- Folks want to have control over the versions and need durable repositories.
- Concerns for performance
- Duplication of artifacts
- Could make the root URL (e.g. galileo/) the latest
- Each new SR could get a stable URL (e.g. galileo/SRX)
- Do we need to fix this now?
- Do we need to get an SR0 URL for Galileo?
- Would allow for us to test revert and check differences in mirroring.
- Can we get by with make a stable SR1 an SR2 Galileo?
- Do we need to get an SR0 URL for Galileo?
- We should do the right thing for SR2 so that we know it will work for Helios
- Pascal recommends a composite repo for SR1/SR2 of Galileo and restore SR0.
- We will not know how much has changed until the exercise is done.
- We need to make a composite repository with SR0/SR1/SR2 of Galileo to get experience.
- We could make the constituents (SRs) a diff of the previous SR
- Other option is to make self contained SR repos as constituents of the big composite repo.
- Could make aggregate-SRs and stand alone SR repos.
- Once released always available, never delete old content