Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox/Meeting Minutes/20091013"
< Equinox | Meeting Minutes
Line 15: | Line 15: | ||
== Minutes == | == Minutes == | ||
+ | * Retention policy | ||
+ | ** Once released always available, never delete old content | ||
+ | *** One repository containing SR1, SR2, SR3 for Galileo | ||
+ | *** One repository for Helios etc. | ||
+ | ** [http://wiki.eclipse.org/Eclipse_Project_Update_Sites 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? | ||
+ | ** 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. |
Latest revision as of 10:59, 13 October 2009
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