On 12/12/2014 11:08 AM, Thiago Macieira wrote: > 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.
As below. >> 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. The problem is that it's implicit. Nothing clear. You come from the view of IVI driving releases. Others come from the view of wearable, mobile and tv driving releases. Unless you are clear and explicit, this problem will continue. >> 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... So then someone has to make itcleane that timeline is more important than dbus as a feature. No one has mde that clear in any way or from. not on this list, or on a wiki page etc. Kdbus has been touted as a key feature of Tizen 3. By definition Tizen 3 waits for Kdbus, UNTIL the call is made to skip it. No such debate has even come up yet - not on these mailing lists. Tizen is not the open source project that all the governance model presentations talk about unless that happens. I think the whole model we have of feature based releases just doesn't fly given the landscape we have. We need to re-evaluate this quite seriously. As I said - I'd go for a short release cycle / rolling "common" distro with profiles stabilizing longer-term releases of profiles from that. This lets common march on and try new things as needed and then for profiles to have some sense of stability by not following as fast. -- The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law including the Unfair Competition Prevention and Trade Secret Protection Act. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify the sender by email and delete this communication immediately. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
