Hi,
Here's the following rationale: 1. as a user, I would like to easily find the released Linaro components: * Linaro Evaluation Build (Android and Ubuntu LEB) * Tools (linaro-image-tools) * Working Groups (kernel, u-boot, gcc, gdb, qemu, powerdebug, powertop, etc...) 2. as a user, I would like to download the release for my ${board} in one central place. 3. as a release manager on the road to monthly releases, I would like to adjust the current layout to match the release process.
The current layout has some issues: - a user should go through several paths to get a rootfs and a hardware pack. - a user should go through several websites to find Linaro goods (releases.l.o, launchpad.net) - newcomers like Android doesn't fit well - every team has a different release process
To resolve these user stories, we came up with 2 layouts proposal. Please, see the document attached. Feebdacks/suggestions on the proposals are welcome!
Note: we planned to start with platform directory only. The working-groups could come later when we agree on the approach.
Cheers,
Fathi
Hey
On Thu, May 26, 2011, Fathi Boudra wrote:
==== releases.linaro.org layout proposal 1====
Jamie, Alexander and myself once had a long and relatively painful discussion about the ideal layout; my main argument in the discussion was that the names and contents of our releases will keep changing, we will rebrand the names we use for our outputs (e.g. "LEB" or platform images), we will add and remove outputs, so my proposal was for the toplevel to be the date of the release, much like the http://releases.ubuntu.com/ toplevel. For a similar discussion on snapshots.linaro.org, http://cdimage.ubuntu.com/ might be a good example where there's only a toplevel by "project", then subdirs by date or arch, or whatever. The main advantage of having a /$year-$month/ toplevel is that you magically historize the old product names; people will want the latest release anyway. Back when Alexander, Jamie and I had this discussion, there was an area of confusion for the end-user because we had 6-monthly outputs and monthly outputs, and monthly outputs were not on releases.linaro.org.
But interestingly your argument is about user experience, not about the best layout. I don't think browsing a file hierarchy over http is a particularly friendly user experience, nor reading multiple web pages, downloading multiple bits. A better user experience is if we can provide pre-built consumable images as we discussed at Budapest, or if we can provide a tool to download the right hwpack + rootfs for your board and then run linaro-media-create automatically; James Tunnicliffe is working on such a "TestDrive" tool. It's fair to say that we could make the web user experience better, but instead of changing the layout, could we simply provide entry points to browse related things together? For instance we could offer a search page to find all OMAP related downloads. Or we could generate a page per board with all the latest files related to this board.
As part of TestDrive, James Tunnicliffe wrote a tool to scan images on releases.linaro.org and generate a sqlite3 db. We could use this tool or this db, or a similar approach, as the source of information for "everything related to beagleboard" or "latest images for all platforms". Integration with Launchpad could we done via launchpadlib; no need to copy the tarballs around, or change existing practices or hosting locations.
Cheers,
Hi,Fathi Boudra
IT is a good idea and Thanks for the work.
On 26 May 2011 17:24, Loïc Minier loic.minier@linaro.org wrote:
HeyOn Thu, May 26, 2011, Fathi Boudra wrote:
==== releases.linaro.org layout proposal 1====
Jamie, Alexander and myself once had a long and relatively painful discussion about the ideal layout; my main argument in the discussion was that the names and contents of our releases will keep changing, we will rebrand the names we use for our outputs (e.g. "LEB" or platform images), we will add and remove outputs, so my proposal was for the toplevel to be the date of the release, much like the http://releases.ubuntu.com/ toplevel. For a similar discussion on snapshots.linaro.org, http://cdimage.ubuntu.com/ might be a good example where there's only a toplevel by "project", then subdirs by date or arch, or whatever. The main advantage of having a /$year-$month/ toplevel is that you magically historize the old product names; people will want the latest release anyway. Back when Alexander, Jamie and I had this discussion, there was an area of confusion for the end-user because we had 6-monthly outputs and monthly outputs, and monthly outputs were not on releases.linaro.org.
But interestingly your argument is about user experience, not about the best layout. I don't think browsing a file hierarchy over http is a particularly friendly user experience, nor reading multiple web pages, downloading multiple bits. A better user experience is if we can provide pre-built consumable images as we discussed at Budapest, or if we can provide a tool to download the right hwpack + rootfs for your board and then run linaro-media-create automatically; James Tunnicliffe is working on such a "TestDrive" tool. It's fair to say that we could make the web user experience better, but instead of changing the layout, could we simply provide entry points to browse related things together? For instance we could offer a search page to find all OMAP related downloads. Or we could generate a page per board with all the latest files related to this board.
As part of TestDrive, James Tunnicliffe wrote a tool to scan images on releases.linaro.org and generate a sqlite3 db. We could use this tool or this db, or a similar approach, as the source of information for "everything related to beagleboard" or "latest images for all platforms". Integration with Launchpad could we done via launchpadlib; no need to copy the tarballs around, or change existing practices or hosting locations.
Cheers,
Loïc Minier
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Thu, May 26, 2011 at 11:24 AM, Loïc Minier loic.minier@linaro.org wrote:
Hey
On Thu, May 26, 2011, Fathi Boudra wrote:
==== releases.linaro.org layout proposal 1====
Jamie, Alexander and myself once had a long and relatively painful discussion about the ideal layout; my main argument in the discussion was that the names and contents of our releases will keep changing, we will rebrand the names we use for our outputs (e.g. "LEB" or platform images), we will add and remove outputs, so my proposal was for the toplevel to be the date of the release, much like the http://releases.ubuntu.com/ toplevel. For a similar discussion on snapshots.linaro.org, http://cdimage.ubuntu.com/ might be a good example where there's only a toplevel by "project", then subdirs by date or arch, or whatever. The main advantage of having a /$year-$month/ toplevel is that you magically historize the old product names; people will want the latest release anyway. Back when Alexander, Jamie and I had this discussion, there was an area of confusion for the end-user because we had 6-monthly outputs and monthly outputs, and monthly outputs were not on releases.linaro.org.
But interestingly your argument is about user experience, not about the best layout. I don't think browsing a file hierarchy over http is a particularly friendly user experience, nor reading multiple web pages, downloading multiple bits. A better user experience is if we can provide pre-built consumable images as we discussed at Budapest, or if we can provide a tool to download the right hwpack + rootfs for your board and then run linaro-media-create automatically; James Tunnicliffe is working on such a "TestDrive" tool. It's fair to say that we could make the web user experience better, but instead of changing the layout, could we simply provide entry points to browse related things together? For instance we could offer a search page to find all OMAP related downloads. Or we could generate a page per board with all the latest files related to this board.
Noone seriously wants to design a great user experience around a HTTP file browsing hierarchy. However, the hierarchy there should make sense and using user experience to test whether it makes sense is one valid way to do that imo.
And yes, I agree with you that this is not the main landing page for users that want to consume linaro images and copmonents (that will be http://linaro.org/remote/downloads like); however, all this does not mean we shouldn't fix the layout to be more consistent and better reflect our new monthly release model.
So in other words, whatever we do and argue, we have to do something about the layout for this release, because the current layout does not work well anymore, e.g.
1. refers to linaro-n which is quite ubuntu centric 2. doesn't reflect monthly releases very well (see how ubuntu has beta/alpha, 11.04 11.05 in that hierarchy) 3. doesn't scale to allow working group outputs to be included in a clean way 4. there is no place fit android in the current layout
As part of TestDrive, James Tunnicliffe wrote a tool to scan images on releases.linaro.org and generate a sqlite3 db. We could use this tool or this db, or a similar approach, as the source of information for "everything related to beagleboard" or "latest images for all platforms". Integration with Launchpad could we done via launchpadlib; no need to copy the tarballs around, or change existing practices or hosting locations.
All those arguments are good. But thats all on top for me. We can certainly invest in improved tools and webservices etc. However, we need to discuss how to layout the releases.linaro.org webserver for this release to fix immediate issues.
Lets move step by step and focus in this thread on the layout of releases.linaro.org. We can discuss the big download future picture outside of this thread ;).
On Thu, May 26, 2011, Alexander Sack wrote:
Lets move step by step and focus in this thread on the layout of releases.linaro.org. We can discuss the big download future picture outside of this thread ;).
Linaro strives to be transparent and open, but design by committee or by vote suck, and discussing the layout of files on a server with the whole world doesn't make sense if we already agree we want to provide an UI to abstract it this layout away.
I agree the current layout isn't the best; what I believe is a more sustainable layout where we wont have to maintain URL redirections over time would be: /$year-$month/$project/ with project being an ouput of a team; either a platform output, or a working output; project could be android, or powerdebug.
On Thu, May 26, 2011 at 12:40 PM, Loïc Minier loic.minier@linaro.org wrote:
On Thu, May 26, 2011, Alexander Sack wrote:
Lets move step by step and focus in this thread on the layout of releases.linaro.org. We can discuss the big download future picture outside of this thread ;).
Linaro strives to be transparent and open, but design by committee or by vote suck, and discussing the layout of files on a server with the whole world doesn't make sense if we already agree we want to provide an UI to abstract it this layout away.
I agree the current layout isn't the best; what I believe is a more sustainable layout where we wont have to maintain URL redirections over time would be: /$year-$month/$project/ with project being an ouput of a team; either a platform output, or a working output; project could be android, or powerdebug.
yes, thats the other option we discussed ... see here: http://releases.linaro.org/.11.04/ for an example ... I am fine with either keeping platform and working groups split or merging them as you suggest.
On Thu, May 26, 2011 at 11:38:41AM +0200, Alexander Sack wrote:
On Thu, May 26, 2011 at 11:24 AM, Loïc Minier loic.minier@linaro.org wrote:
Hey
On Thu, May 26, 2011, Fathi Boudra wrote:
==== releases.linaro.org layout proposal 1====
Jamie, Alexander and myself once had a long and relatively painful discussion about the ideal layout; my main argument in the discussion was that the names and contents of our releases will keep changing, we will rebrand the names we use for our outputs (e.g. "LEB" or platform images), we will add and remove outputs, so my proposal was for the toplevel to be the date of the release, much like the http://releases.ubuntu.com/ toplevel. For a similar discussion on snapshots.linaro.org, http://cdimage.ubuntu.com/ might be a good example where there's only a toplevel by "project", then subdirs by date or arch, or whatever. The main advantage of having a /$year-$month/ toplevel is that you magically historize the old product names; people will want the latest release anyway. Back when Alexander, Jamie and I had this discussion, there was an area of confusion for the end-user because we had 6-monthly outputs and monthly outputs, and monthly outputs were not on releases.linaro.org.
But interestingly your argument is about user experience, not about the best layout. I don't think browsing a file hierarchy over http is a particularly friendly user experience, nor reading multiple web pages, downloading multiple bits. A better user experience is if we can provide pre-built consumable images as we discussed at Budapest, or if we can provide a tool to download the right hwpack + rootfs for your board and then run linaro-media-create automatically; James Tunnicliffe is working on such a "TestDrive" tool. It's fair to say that we could make the web user experience better, but instead of changing the layout, could we simply provide entry points to browse related things together? For instance we could offer a search page to find all OMAP related downloads. Or we could generate a page per board with all the latest files related to this board.
Noone seriously wants to design a great user experience around a HTTP file browsing hierarchy. However, the hierarchy there should make sense and using user experience to test whether it makes sense is one valid way to do that imo.
And yes, I agree with you that this is not the main landing page for users that want to consume linaro images and copmonents (that will be http://linaro.org/remote/downloads like); however, all this does not mean we shouldn't fix the layout to be more consistent and better reflect our new monthly release model.
Just adding my perspective...
I guess it's a comment on the nature of the website frontend that people are quickly dumped into the HTTP folders and have to find their way from there.
If we consider that's not user-friendly enough, it would be good if we could enumerate all the released files in a database with adequate metadata, and then we can make all the release info intelligible, up to date and searchable on www.linaro.org.
At present, the website and wiki release information feels too manual, and that just isn't going to scale over time.
Note that this approach supplements, but does not replace, the need for an HTTP hierarchy with long-term stable URIs.
We should avoid overengineering the URIs themselves, because the more information we try to shoehorn into them the more we're going to have to keep changing them in the future to address unforeseen requirements.
So in other words, whatever we do and argue, we have to do something about the layout for this release, because the current layout does not work well anymore, e.g.
- refers to linaro-n which is quite ubuntu centric
- doesn't reflect monthly releases very well (see how ubuntu has
beta/alpha, 11.04 11.05 in that hierarchy) 3. doesn't scale to allow working group outputs to be included in a clean way 4. there is no place fit android in the current layout
As part of TestDrive, James Tunnicliffe wrote a tool to scan images on releases.linaro.org and generate a sqlite3 db. We could use this tool or this db, or a similar approach, as the source of information for "everything related to beagleboard" or "latest images for all platforms". Integration with Launchpad could we done via launchpadlib; no need to copy the tarballs around, or change existing practices or hosting locations.
All those arguments are good. But thats all on top for me. We can certainly invest in improved tools and webservices etc. However, we need to discuss how to layout the releases.linaro.org webserver for this release to fix immediate issues.
Lets move step by step and focus in this thread on the layout of releases.linaro.org. We can discuss the big download future picture outside of this thread ;).
People do expect releases.linaro.org to be an archive of old releases, as well as a repository of new releases.
Can I ask that the URIs of all components of old releases should continue to work (i.e., we either don't move that stuff ever, or we provide aliases)?
I've had complaints from people that their old scripts, or their attempts to reproduce old releases were broken by the most recent rearrangement.
Cheers ---Dave
On Thu, May 26, 2011 at 12:44 PM, Dave Martin dave.martin@linaro.org wrote:
People do expect releases.linaro.org to be an archive of old releases, as well as a repository of new releases.
Can I ask that the URIs of all components of old releases should continue to work (i.e., we either don't move that stuff ever, or we provide aliases)?
I've had complaints from people that their old scripts, or their attempts to reproduce old releases were broken by the most recent rearrangement.
Yes, this was a one time mistake (oversight) and we reverted that change quickly afterwards. All changes we do here should have proper redirects etc. in place to keep the old URLs working
On 26 May 2011 11:56, Alexander Sack asac@linaro.org wrote:
On Thu, May 26, 2011 at 12:44 PM, Dave Martin dave.martin@linaro.org wrote:
People do expect releases.linaro.org to be an archive of old releases, as well as a repository of new releases.
Can I ask that the URIs of all components of old releases should continue to work (i.e., we either don't move that stuff ever, or we provide aliases)?
I've had complaints from people that their old scripts, or their attempts to reproduce old releases were broken by the most recent rearrangement.
Yes, this was a one time mistake (oversight) and we reverted that change quickly afterwards. All changes we do here should have proper redirects etc. in place to keep the old URLs working
1. My vote is to leave the layout as it is for what is up (so we don't break anything) 2. I don't care about the layout for future releases, provided I can index it using simple rules. 3. Once I have finished the TestDrive GUI, see if we can use the same principles to create a simple to use web page, that doesn't expose the storage file system.
We should be able to query the server with a board type and some data about what release/shapshot you want and be provided with a download page with both the hardware pack and the OS image to download (and probably with a linaro-media-create line as well). I am sure this could be refined so that a page could be prodded by a user or script to return a tar ball of both (gzipped inside).
On 11 May 26, Fathi Boudra wrote:
Hi,
Here's the following rationale:
- as a user, I would like to easily find the released Linaro components:
- Linaro Evaluation Build (Android and Ubuntu LEB)
- Tools (linaro-image-tools)
- Working Groups (kernel, u-boot, gcc, gdb, qemu, powerdebug, powertop, etc...)
- as a user, I would like to download the release for my ${board} in
one central place. 3. as a release manager on the road to monthly releases, I would like to adjust the current layout to match the release process.
The current layout has some issues:
- a user should go through several paths to get a rootfs and a hardware pack.
- a user should go through several websites to find Linaro goods
(releases.l.o, launchpad.net)
- newcomers like Android doesn't fit well
- every team has a different release process
+1
The current layout assumes that outsiders know exactly what all our codenames mean - alip, nano, headless, developer, hwpack, etc. (!)
Hell, even I don't know what the differences are.
To resolve these user stories, we came up with 2 layouts proposal. Please, see the document attached. Feebdacks/suggestions on the proposals are welcome!
Note: we planned to start with platform directory only. The working-groups could come later when we agree on the approach.
Cheers,
Fathi
Linaro Release Manager | Platform Project Manager
==== releases.linaro.org current layout ====
platform/linaro-n |-- platform/linaro-n/alip | |-- platform/linaro-n/alip/beta-2 | `-- platform/linaro-n/alip/latest -> beta-2 |-- platform/linaro-n/android | |-- platform/linaro-n/android/11.04 | | |-- platform/linaro-n/android/11.04/beaglexm | | `-- platform/linaro-n/android/11.04/panda | `-- platform/linaro-n/android/latest -> 11.04/ |-- platform/linaro-n/developer | |-- platform/linaro-n/developer/beta-2 | `-- platform/linaro-n/developer/latest -> beta-2 |-- platform/linaro-n/hwpacks | |-- platform/linaro-n/hwpacks/beta-2 | `-- platform/linaro-n/hwpacks/latest -> beta-2 |-- platform/linaro-n/nano | |-- platform/linaro-n/nano/beta-2 | `-- platform/linaro-n/nano/latest -> beta-2 `-- platform/linaro-n/ubuntu-desktop |-- platform/linaro-n/ubuntu-desktop/alpha-3 |-- platform/linaro-n/ubuntu-desktop/beta |-- platform/linaro-n/ubuntu-desktop/beta-2 `-- platform/linaro-n/ubuntu-desktop/latest -> beta-2
==== releases.linaro.org layout proposal 1====
platform |-- platform/11.05 | |-- platform/11.05/android | | |-- platform/11.05/android/beaglexm | | |-- platform/11.05/android/ndk | | |-- platform/11.05/android/panda | | |-- platform/11.05/android/sdk | | `-- platform/11.05/android/toolchain | |-- platform/11.05/tools | | |-- platform/11.05/tools/linaro-image-tools | `-- platform/11.05/ubuntu | |-- platform/11.05/ubuntu/panda | | |-- platform/11.05/ubuntu/panda | | `-- platform/11.05/ubuntu/snowball | `-- platform/11.05/ubuntu/snowball [-- platform/11.06 `-- platform/latest -> 11.06
working-groups |-- working-groups/11.05 | |-- working-groups/11.05/graphics | |-- working-groups/11.05/kernel | |-- working-groups/11.05/multimedia | |-- working-groups/11.05/power-management | `-- working-groups/11.05/toolchain
You're again forcing people to know the difference between platform and working groups' output. None of the upstreams that we invited to Budapest knew the difference (or cared for that matter). I suspect the same is true for some of our consumers.
|-- working-groups/11.06 | |-- working-groups/11.06/graphics | |-- working-groups/11.06/kernel | |-- working-groups/11.06/multimedia | |-- working-groups/11.06/power-management | |-- working-groups/11.06/toolchain `-- working-groups/latest -> 11.06
==== releases.linaro.org layout proposal 2 ====
platform |-- platform/android | |-- platform/android/11.05 | | |-- platform/android/11.05/beaglexm | | `-- platform/android/11.05/panda | |-- platform/android/11.06 | | |-- platform/android/11.06/beaglexm | | `-- platform/android/11.06/panda | `-- platform/android/latest -> 11.06 |-- tools/linaro-image-tools | |-- tools/linaro-image-tools/0.4.7 | |-- tools/linaro-image-tools/0.4.8 | `-- tools/linaro-image-tools/latest -> 0.4.8 `-- platform/ubuntu |-- platform/ubuntu/11.05 | |-- platform/ubuntu/11.06/panda | `-- platform/ubuntu/11.06/snowball |-- platform/ubuntu/11.06 | |-- platform/ubuntu/11.06/panda | `-- platform/ubuntu/11.06/snowball `-- platform/ubuntu/latest -> 11.06
working-groups |-- working-groups/graphics | |-- working-groups/graphics/11.05 | |-- working-groups/graphics/11.06 | `-- working-groups/graphics/latest -> 11.06 |-- working-groups/kernel | |-- working-groups/kernel/11.05 | |-- working-groups/kernel/11.06 | `-- working-groups/kernel/latest -> 11.06 |-- working-groups/multimedia | |-- working-groups/multimedia/11.05 | |-- working-groups/multimedia/11.06 | `-- working-groups/multimedia/latest -> 11.06 |-- working-groups/power-management | |-- working-groups/power-management/11.05 | |-- working-groups/power-management/11.06 | `-- working-groups/power-management/latest -> 11.06 `-- working-groups/toolchain |-- working-groups/toolchain/11.05 |-- working-groups/toolchain/11.06 `-- working-groups/toolchain/latest -> 11.06
If I were an outsider, what I'd really like is this:
1. Go to releases.linaro.org 2. Click on LATEST 3. Get a directory with links to the latest of everything: hwpacks, toolchain, powedebug, etc. Also, these names should not contain version info. So, linaro-toolchain-latest.tar.gz and not linaro-toolchain-4.6.x.tar.gz 4. Now I can write a simple script that rsyncs releases.linaro.org/latest every month. We should probably just supply that script too.
There should also be a webpage under the directory listing (I believe apache can do that) that explains what the various names mean - alip vs. nano vs. developer vs. headless, etc.
OTOH, providing TestDrive would be the best solution. (I didn't know it was being taken up finally this cycle. I've now subscribed to the wiki page)
Regards, Amit
Hi,
I'd like to add an extra constraint on the design if possible. As everyone has pointed out we want an index in to this stuff that users will use, so I think my constraint has a place. It has been complained about many times, but it's not going to go away without some work on our part.
Currently we require sysadmin intervention when we add a new image/hwpack so that they can be synced to snapshots.linaro.org. I would like to remove this restriction, but one of the issues is that the hierarchy we have on snapshots.linaro.org is nothing like the one that is produced by offspring.
We can obviously change offspring, but the current hierarchy doesn't obey simple rules that we can code in to the tool.
This affects snapshots more than releases. However, releases can be done with a click from within offspring now, rather than by someone copying files around. If we want to use that feature the releases should use the same hierarchy as snapshots.
Thefore my request is that there be a set of simple rules used to place the results of a build that uses information available to offspring.linaro.org.
Thanks,
James
On Thu, 26 May 2011 08:54:59 +0000, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi,
Here's the following rationale:
- as a user, I would like to easily find the released Linaro components:
- Linaro Evaluation Build (Android and Ubuntu LEB)
- Tools (linaro-image-tools)
- Working Groups (kernel, u-boot, gcc, gdb, qemu, powerdebug, powertop, etc...)
- as a user, I would like to download the release for my ${board} in
one central place. 3. as a release manager on the road to monthly releases, I would like to adjust the current layout to match the release process.
The current layout has some issues:
- a user should go through several paths to get a rootfs and a hardware pack.
- a user should go through several websites to find Linaro goods
(releases.l.o, launchpad.net)
- newcomers like Android doesn't fit well
- every team has a different release process
To resolve these user stories, we came up with 2 layouts proposal. Please, see the document attached. Feebdacks/suggestions on the proposals are welcome!
Note: we planned to start with platform directory only. The working-groups could come later when we agree on the approach.
Cheers,
Fathi
Linaro Release Manager | Platform Project Manager ==== releases.linaro.org current layout ====
platform/linaro-n |-- platform/linaro-n/alip | |-- platform/linaro-n/alip/beta-2 | `-- platform/linaro-n/alip/latest -> beta-2 |-- platform/linaro-n/android | |-- platform/linaro-n/android/11.04 | | |-- platform/linaro-n/android/11.04/beaglexm | | `-- platform/linaro-n/android/11.04/panda | `-- platform/linaro-n/android/latest -> 11.04/ |-- platform/linaro-n/developer | |-- platform/linaro-n/developer/beta-2 | `-- platform/linaro-n/developer/latest -> beta-2 |-- platform/linaro-n/hwpacks | |-- platform/linaro-n/hwpacks/beta-2 | `-- platform/linaro-n/hwpacks/latest -> beta-2 |-- platform/linaro-n/nano | |-- platform/linaro-n/nano/beta-2 | `-- platform/linaro-n/nano/latest -> beta-2 `-- platform/linaro-n/ubuntu-desktop |-- platform/linaro-n/ubuntu-desktop/alpha-3 |-- platform/linaro-n/ubuntu-desktop/beta |-- platform/linaro-n/ubuntu-desktop/beta-2 `-- platform/linaro-n/ubuntu-desktop/latest -> beta-2
==== releases.linaro.org layout proposal 1====
platform |-- platform/11.05 | |-- platform/11.05/android | | |-- platform/11.05/android/beaglexm | | |-- platform/11.05/android/ndk | | |-- platform/11.05/android/panda | | |-- platform/11.05/android/sdk | | `-- platform/11.05/android/toolchain | |-- platform/11.05/tools | | |-- platform/11.05/tools/linaro-image-tools | `-- platform/11.05/ubuntu | |-- platform/11.05/ubuntu/panda | | |-- platform/11.05/ubuntu/panda | | `-- platform/11.05/ubuntu/snowball | `-- platform/11.05/ubuntu/snowball [-- platform/11.06 `-- platform/latest -> 11.06
working-groups |-- working-groups/11.05 | |-- working-groups/11.05/graphics | |-- working-groups/11.05/kernel | |-- working-groups/11.05/multimedia | |-- working-groups/11.05/power-management | `-- working-groups/11.05/toolchain |-- working-groups/11.06 | |-- working-groups/11.06/graphics | |-- working-groups/11.06/kernel | |-- working-groups/11.06/multimedia | |-- working-groups/11.06/power-management | |-- working-groups/11.06/toolchain `-- working-groups/latest -> 11.06
==== releases.linaro.org layout proposal 2 ====
platform |-- platform/android | |-- platform/android/11.05 | | |-- platform/android/11.05/beaglexm | | `-- platform/android/11.05/panda | |-- platform/android/11.06 | | |-- platform/android/11.06/beaglexm | | `-- platform/android/11.06/panda | `-- platform/android/latest -> 11.06 |-- tools/linaro-image-tools | |-- tools/linaro-image-tools/0.4.7 | |-- tools/linaro-image-tools/0.4.8 | `-- tools/linaro-image-tools/latest -> 0.4.8 `-- platform/ubuntu |-- platform/ubuntu/11.05 | |-- platform/ubuntu/11.06/panda | `-- platform/ubuntu/11.06/snowball |-- platform/ubuntu/11.06 | |-- platform/ubuntu/11.06/panda | `-- platform/ubuntu/11.06/snowball `-- platform/ubuntu/latest -> 11.06
working-groups |-- working-groups/graphics | |-- working-groups/graphics/11.05 | |-- working-groups/graphics/11.06 | `-- working-groups/graphics/latest -> 11.06 |-- working-groups/kernel | |-- working-groups/kernel/11.05 | |-- working-groups/kernel/11.06 | `-- working-groups/kernel/latest -> 11.06 |-- working-groups/multimedia | |-- working-groups/multimedia/11.05 | |-- working-groups/multimedia/11.06 | `-- working-groups/multimedia/latest -> 11.06 |-- working-groups/power-management | |-- working-groups/power-management/11.05 | |-- working-groups/power-management/11.06 | `-- working-groups/power-management/latest -> 11.06 `-- working-groups/toolchain |-- working-groups/toolchain/11.05 |-- working-groups/toolchain/11.06 `-- working-groups/toolchain/latest -> 11.06
On Thu, May 26, 2011 at 8:54 PM, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi,
Here's the following rationale:
- as a user, I would like to easily find the released Linaro components:
- Linaro Evaluation Build (Android and Ubuntu LEB)
- Tools (linaro-image-tools)
- Working Groups (kernel, u-boot, gcc, gdb, qemu, powerdebug, powertop, etc...)
- as a user, I would like to download the release for my ${board} in
one central place. 3. as a release manager on the road to monthly releases, I would like to adjust the current layout to match the release process.
The current layout has some issues:
- a user should go through several paths to get a rootfs and a hardware pack.
- a user should go through several websites to find Linaro goods
(releases.l.o, launchpad.net)
- newcomers like Android doesn't fit well
- every team has a different release process
To resolve these user stories, we came up with 2 layouts proposal. Please, see the document attached. Feebdacks/suggestions on the proposals are welcome!
Note: we planned to start with platform directory only. The working-groups could come later when we agree on the approach.
I'm quite happy with hosting our releases on Launchpad. It ties everything related to that product together quite well. I would like some type of landing page though especially when we start doing binary releases and if we do a toolchain stable branch.
-- Michael
Bringing up the monthly integration blueprint again...
We could list the builds from these pages. All of the delivered components will hopefully be listed on the blueprint, we could also list the test results and build instructions in one place as well as anything else. People would be able to get everything they need in one place.
What are monthly integration blueprints?
I've sent this text around to a few people, but here it is for everyone:
For better or worse Android builds are fairly monolithic in their construction. There's a lot of layering violations and out-right hacks people do to get things working.
To ship Android images everyone's going to need to pull Android builds, integrate their changes, and test the results - especially in the kernel, multimedia and graphics domains.
Here's what I'm thinking:
I want to create a monthly Android integration blueprint. In the blueprint all the leads and PoCs and Landing teams will list what they're going to deliver by the 3rd week of the month. Each team would then take and test their changes against the latest Android build and send the changes for integration. The changes would bake for a week and then get released. The BP would then turn into the release note.
We are getting a Gerrit instance going to ease patch submission and testing. Once that's working people will be able to push to it, have their change tested across all targets and merged. Gerrit would also be modified to track upstreaming. Until Gerrit gets going this process will be done manually.
Any comments, questions, concerns? What this boils down to is a need to have much closer ties between all the groups. The goal is an Android image that has the best available components. Getting there requires a lot of work that cuts across all domains in strange and unforeseen ways.
-Zach
On 26 May 2011 21:00, Michael Hope michael.hope@linaro.org wrote:
On Thu, May 26, 2011 at 8:54 PM, Fathi Boudra fathi.boudra@linaro.org wrote:
Hi,
Here's the following rationale:
- as a user, I would like to easily find the released Linaro components:
- Linaro Evaluation Build (Android and Ubuntu LEB)
- Tools (linaro-image-tools)
- Working Groups (kernel, u-boot, gcc, gdb, qemu, powerdebug, powertop, etc...)
- as a user, I would like to download the release for my ${board} in
one central place. 3. as a release manager on the road to monthly releases, I would like to adjust the current layout to match the release process.
The current layout has some issues:
- a user should go through several paths to get a rootfs and a hardware pack.
- a user should go through several websites to find Linaro goods
(releases.l.o, launchpad.net)
- newcomers like Android doesn't fit well
- every team has a different release process
To resolve these user stories, we came up with 2 layouts proposal. Please, see the document attached. Feebdacks/suggestions on the proposals are welcome!
Note: we planned to start with platform directory only. The working-groups could come later when we agree on the approach.
I'm quite happy with hosting our releases on Launchpad. It ties everything related to that product together quite well. I would like some type of landing page though especially when we start doing binary releases and if we do a toolchain stable branch.
-- Michael
Hi Michael,
On 27 May 2011 02:00, Michael Hope michael.hope@linaro.org wrote:
I'm quite happy with hosting our releases on Launchpad. It ties everything related to that product together quite well. I would like some type of landing page though especially when we start doing binary releases and if we do a toolchain stable branch.
I don't want to change your current workflow. I'm fine if you continue to release as you do on Launchpad, I'll take care to copy your released code to releases.linaro.org host.
Cheers,
Fathi
-
Alexander Sack -
Amit Kucheria -
Dave Martin -
Fathi Boudra -
James Tunnicliffe -
James Westby -
Jello huang -
Loïc Minier -
Michael Hope -
Zach Pfeffer