2010/12/1 Clark, Joel <[email protected]>: > > >>Dave Neary wrote: >> >>Does all of this really need to be a prerequisite to allowing a >>long-time, active community member to upload & distribute an image? >> >>Till can write, in really >>small letters underneath, "If anyone has problems with the image, >>contact me at [email protected]" and then Till will be >>doing your triage for you. >> >>Cheers, >>Dave. > > I don't get it either. If the "long-time, active community member" is > willing to build, test, upload, distribute and deal with problems from > anybody who uses his image, why not take advantage of the existing automated > processes for code management, build, distribution and issue tracking? Is the > goal here to make sure the beagleboard is not supported on meego.com?
I think we're going in a circle here. Long story short: When development is being done, especially proof of concepts, there will always be images created that doesn't fit in an ordinary release process. But has to be shared with a MeeGo contributor audience such as a team. So what's proposed is an exchange area, where people can upload and other people download. Images would be deleted after a time period. It would also make sure that teams don't end up using internal company infrastructure for such things - like we do with our acceptance/sanity images currently. These should be publically accessible for those wanting to get into daily testing. An example can be for example development images related to integrating a new graphics driver where I'd have to share it with QA guys to verify nothing is going sour. For the Beagleboard image, such an area would allow for a process where the kickstart file is evolved to an initial working state, images published to the relevant teams and interested contributors. Based on that work FEA#'s set up for the hardware adaptation, the needed roles attached and included as part of the real release process. That's obviously where things should go eventually. But in the very early stages, release process is overkill for the initial images to get things started. .. I don't think we should be in a position where we put any incoming hardware adaptation, even the proof of concepts into the MeeGo release process. If something is released from repo.meego.com it should be quality. We did it like this in the N900 hardware adaptation, starting out as a quite broken proof of concept of MeeGo on ARM, evolving into something part of the release process and now automatically generated alongside the rest. BR Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
