On Friday 12 December 2014 08:23:59 Carsten Haitzler wrote: > > Good question. I don't know where it is documented. I know of that because > > Tizen IVI 3.0 has a target release date for the end of the year (and no, I > > don't know where that is documented either). Since IVI releases 3.0, we > > conclude that Tizen:Common for the 3.0 branch must be feature-frozen, if > > not deep-frozen. > > Thus, if you want to enforce things like "sorry - kdbus is too late now as > release is N weeks away" policies, this should be documented. I know that > most people around me see mind 2015 as a target for Tizen 3.0 and so are > working with that date in mind, thus happily stuffing kdbus related patches > in, upgrading efl even as we speak right now, etc. etc. etc.
Just to be clear: this is my personal opinion on how software gets developed. I'm not an architect and deadlines are not up to me. I am simply saying that I see Tizen IVI 3.0 released soon (and we've been saying so for a year), which seems to imply to me that the core that it's based on is also feature frozen. To illustrate by taking the reverse argument: suppose that in one month we upgrade a major component of Tizen:Common 3.0, like the kernel, systemd or gcc and now suddenly we have a problem for the released version of Tizen IVI. Either we'll force that update to the released version, which is QA work and usually distros don't do such upgrades, or we have to tell Tizen IVI to build with older versions. > Since tizen 3 common is ... common ... it's expected that changes all > profiles would share are going to get put into there... and it's going to > happen and keep happening unless things like release dates, freeze periods > etc are clearly communicated and up in "blinky lights". :) Right. Like I said, the release date for IVI 3.0 has been talked about several times, in presentations, private meetings with architects and other settings. I am assuming here that the IVI release affects Common. > I think that perhaps our model for doing releases is a bit broken. Given the > disparate needs of Tizen profiles, maybe Tizen common should be more of a > rolling release. Maybe every 3 months it pops out a stable release that > then is picked up by whatever profiles want it at that time. A regular > release schedule will then reduce confusion over release dates. It's > predictable. This will also work well with those that care about commercial > schedules. There are well known dates for trhe next stable release from > common to merge into their profile. That makes sense and would probably work better. > One last thing - kdbus has been held up as a major feature of Tizen 3.0 for > a very long time now. Core feature. If it's taking longer, then Tizen 3.0 > takes longer. Same as Crosswalk - would you do Tizen 3.0 without crosswalk > if it was late? As best I know Tizen hasn't taken the position of doing > timed releases where "if a feature isn't ready yet, it doesn't go in that > release". It is doing feature releases. A Tizen version X has features A, B > and C. That means Tizen X waits for A, B and C. I don't remember any > discussion, communication etc. about Tizen switching release models. Again > - communicate, document etc. Understood, but whenever a feature is not present when a feature freeze deadline happens, we have a choice to make among two alternatives. One is what you said: delay the release until the feature is present. The other is to say "better luck next time" and get the feature in the next release. I don't know what Tizen is choosing here and it's not up to me to make the decision. On the specific case of kdbus: even if the decision is to wait, the contingency solution had better be available. We're asking for a mid-2015 release of the profiles, with all the testing that is required, to depend on a feature that hasn't been finished by upstream. Think about it: kdbus isn't in the kernel yet, so it will take time for the API/ABI to mature. Until there's a *released* version of the kernel, the ABI can still change and it would be irresponsible of Tizen to have released devices that don't conform to the kernel ABI. There are probably ways to mitigate this, by ensuring that any updates to the ABI are strictly backported to Tizen and we hold the release until the kernel gets released too. Think about it: one single feature might derail the entire Tizen schedule if kdbus slips to kernel 3.20. When I worked at Nokia, I was told that every month of delay cost the company $1 billion... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
