Hi, Just noticed that http://wiki.meego.com/Core_OS_Program/Kernel_policy came up and is on the agenda for TSG meeting tomorrow, so given that we have 24 hours to comment and I haven't seen it discussed in public, here's a couple of questions/comments from a hardware adaptation PoV (not speaking from N900 PoV):
Before I start on a rather long reply - the proposal looks great, will hopefully make some things clearer. > 6. The adaption kernels must follow the same release process/timing as the > rest of MeeGo; e.g. the same feature freeze, code complete dates etc etc. (nitpick since we're making this into policy: 'adaptation' not 'adaption') So, I'd like to ask how we will deal with the following situation that well may arise: * Vendor comes with a hardware adaptation for device/platform X and wants to contribute this for MeeGo. This contains an adaptation kernel. It passes all automatic core OS testing and is deemed compliant for 1.2. Vendor naturally wants to contribute this for MeeGo 1.2 device makers to use. Problem is that 1.2 timeframe has gone and passed, so he can't participate in normal release process but yet it's a perfectly fine hardware adaptation. My worry is that with this rule that we might be too stringent and making it more difficult to have people port MeeGo and share their HW adaptation work within the MeeGo project. So a tiny bit of flexibility is needed. I personally lean towards some variant as the following: * that we separate hardware adaptation from Core repository (including kernel but keeping kernel-headers in Core) into adaptation repositories (one for each/group as needed) * establish a set of expected kernel configuration options (as proposed) and a kernel ABI baseline (as kernel-headers does atm) * establish a test case suite to deem a hardware adaptation compliant and working (MCTS?) * adaptation kernels in MeeGo repositories must be following current compliance criteria (config options, security fixes, etc) as is set for the particular release it will be part of (must never be 'behind' global state, even counting the weekly releases in MeeGo) * if the above are established, the hardware adaptation repository can be released with MeGo. The counter-argument to all this might be that the vendor can just be participating in 1.3 release instead of trying to get his adaptation added to 1.2. But I think due to half-year schedule, I could imagine some companies wanting to let's say base on top of a vendor's MeeGo HW adaptation for a given board. And can't wait for 1.3 release. And making a product out of MeeGo should be easy, so we should try to centralize these BSPs/HW adaptations at meego.com and test them, instead of having shady HW adaptations laying about for download at vendor sites... BR Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
