Community
Participate
Working Groups
This is to continue discussion Markus and I started in email. It involved both the "common repository" builds and EPP ... but, we'll track here. I just didn't want to lose it ... there's some opportunity to make things easier for committers/participants, I think. <fromMarkus> Maybe we have to re-think our procedure with SR2 in general. When we prepare for our release in June every year, we are using *two* repositories for the Simultaneous Release: E.g. .../staging and .../indigo. Important is that we use one repository for the continuous integration (.../staging) and the other one for the milestone builds. But when we are doing our build for the SRx releases we are using only one: .../maintenance. This one is in sync only on Friday, sometimes a few days longer, but because of its nature it cannot be used for testing the EPP package upgrade. A very similar problem is in the ...technology/packages/indigo/... repository: There is only one and it is a composite repository for milestones etc. *before* we release in June, and for releases only *after* our release in June (SR1 + SR2). The only reason for me copying the not-yet-release bits to this directory is that I want to have the final bits in a separate directory on a separate bunch of disks in case someone (me?) deletes the other ones by accident. </fromMarkus>
Just to document the "need" and current locations, working backwards, we need both common repo and packages (and also, the "packaging repository") to be available and "in sync" from a number of places: releases: the usual live-for-ever distributions milestones: the usual milestones (which currently are available in 'releases' before the yearly release). milestones eventually become releases. staging: a temporary home, usually lasting a few days, from which milestones are created. maintenance: also a staging area, but for maintenance builds, eventually moving to 'releases' for SR1 and SR2. build machines: for common repo, we actually just have one location on build machines, where results are held, before moving to (one of) the staging locations. Not sure about EPP ... those may be stored "per workspace"? At times I wonder if common repo should be stored for each build, in workspace ... though would get huge quickly, and we could not keep too many. So ... the "audiences" for these are fairly obvious, but will enumerate, since I think the issue is one group is often over looked: releases: general public (for true releases, or early testers for milestones), committers, release engineers. milestones (currently in stored in 'releases' until release): ditto staging: releng and committers to sanity check installs and updates before promoting. maintenance: ditto, but there's not place to "promote" it to, until final maintenance release. build machines: currently sort of "unused" except by release engineers doing the build. Seems there ought to be some better way take advantage of build machine versions for those few times someone needs an earlier than usual check of their stuff. [So, sorry for the "dump" ... just wanted to capture a little of the issues so we could maybe improve in future ... others' perspectives would be appreciated.]
The EPP project does not have its "own" Packager anymore. EPP uses other technologies, such as Eclipse Tycho, Maven and Eclipse PDE. Therefore any remaining bugs are now being closed as WONTFIX. If this bug is still relevant, please make a comment and we'll move it to the correct project/component for further investigation. This change was made as part of a bulk change.
