On Wed, 27 Jul 2011 11:48:11 +0100, James Tunnicliffe james.tunnicliffe@linaro.org wrote:
A couple more observations:
First we have duplication of hardware packs, but not the checksum files and GPG signatures to go with them. The hardware packs are hardware, not distribution specific, so it is difficult to justify to have them in multiple locations. I imagine that this structure was designed to put everything in one directory that someone may need to get up and running with a Linaro distribution, but if they want to check their hardware packs are signed and correctly downloaded they still need to visit the hwpacks directory.
I think that if we are going to put the hwpacks in every directory then the other files should be there too.
I don't think it's a good idea to do this, as it implies that hwpack are rootfs specific, when they aren't. That ship seems to have sailed though.
Second we are still using http://releases.linaro.org/platform/linaro-n. I thought we had done away with the lettered naming convention to go with the date based ones.
To index the releases server automatically I need a predictable file structure. I don't mind what it is, as long as we stick to it. My suggestion is:
All OS binaries structured as: http://releases.linaro.org/platform/%5Brelease%5D/%5Bdistribution name]/[milestone]/
Hardware packs all in one place: http://releases.linaro.org/platform/%5Brelease%5D/hwpacks/%5Bmilestone%5D/
What's the release/milestone distinction here?
I think that the only thing not considered here is multiple versions of a single rootfs or hwpack.
We are currently generating both natty-based and oneiric-based rootfs. I don't know if we plan to release both ever, or if oneiric-based is just snapshots for now, and we will switch one month to release the oneiric-based and not release the natty-based. If someone could clarify the intent here it will help us decide if the hierarchy needs to accommodate that too.
If we would like to have hardware packs closer to the distributions, we have a problem of the hwpack directory being rather large - copying it into each distribution would make it more difficult to find the right files. This problem does go away completely if we automate the downloading of files for the user, which we now do with linaro-fetch-image[-ui].
Yes.
We can do both and use symlinks though :-)
I personally find it unnecessary to have separate directories for the linaro evaluation builds. The Ubuntu desktop and LEB builds seem to be identical (the md5sums files match at least!). Since we can link to specific places on the releases server in a release note, why not just link to the ubuntu-desktop directory? If we want to separate out Linaro Evaluation Builds we could have a structure like: http://releases.linaro.org/platform/11.07/linaro-evaluation-builds/ubuntu-de... http://releases.linaro.org/platform/11.07/community-supported/alip/release-c... http://releases.linaro.org/platform/11.07/hwpacks/release-candidate/
My guess is that Alexander will want something like this to maintain that separation.
I can see why http://releases.linaro.org/platform/linaro-n/ubuntu/leb-panda/latest/ exists, but I believe it is obsolete with the release of linaro-fetch-image or linaro-fetch-image-ui, which automate the whole download and install process. Those tools don't support Android builds yet though. In another twist though the Android builds exist in a third directory structure! http://releases.linaro.org/platform/linaro-n/android/11.07/panda/
Clearly this makes it easy for people with a panda board to get the files they need to run Android on it. The files seem to be unique, so it looks like it can be left alone, other than getting rid of the linaro-n.
It seems like these should fit in to your proposed structure above, with an image name of "android" or similar?
It should be simple enough to script copying the files from snapshots.linaro.org over to releases for the non-Android builds. I am happy to put together something like: create-linaro-release --source-snapshot YYMMDD:build --relese-type <alpha/beta/eac/rc/final> --relase-name <YY.MM>
While this is a good idea, I don't think it's organised enough to be done all at once right now. Builds are currently copied in chunks as they are ready.
While a script might be useful let's not make it a focus of this discussion. If the RMs want a script we can write it, but let's first decide on a layout.
Thanks,
James