On Fri, 03 Jan 2014 12:00:57 -0200 Leandro Dorileo <[email protected]> said:
> Carsten Haitzler wrote: > > > > On 01/03/2014 03:53 PM, Ylinen, Mikko wrote: > >> > >> On Thu, Jan 2, 2014 at 4:31 PM, Daniel Juyung Seo > >> <[email protected] <mailto:[email protected]>> wrote: > >> > >> This sounds ok to me. > >> By the way, how about naming the branch "efl-1.8" or > >> "upstream-efl-1.8" as efl upstream uses "efl-1.8" as its stable > >> branch name? > >> > >> > >> We should follow the Tizen guidelines [1] here, i.e., pull EFL > >> 'efl-1.8' branch to platform/upstream/efl 'upstream' branch (v1.8.3 tag), > >> and git rebase upstream tizen. > >> > >> And is there any plan to sync tizen efl master with efl upstream > >> mater? > >> > >> > >> I don't think we should pull unnecessary branches. Ideally, patches > >> from master > >> are cherry-picked into 'tizen' if needed. > > > > 1) tizen 3 is unlikely to see the light of day until the end of 2014 > > (this is based on what i actually see of tizen 3 and > > development/activity in terms of actual work going on), master should be > > tracked because it provides you a smooth path until the release that > > will go into tizen 3. by the time tizen 3 ships efl will have released > > 1.9 (1.8 already out as of last month) and 1.10 too - maybe 1.11. so > > tizen has to re-sync then 3 times. (efl is now doing timed releases - 6 > > week cycles between releases). > > > > 2) reality is that developers developing apps can't "wait" for the next > > release. they insist on having their feature NOW because some manager is > > breathing down their neck to have it done and they can't until it's in. > > they end up having to keep making reports giving "status" as to why it's > > not done and they wavoid that like the plague... as they also get yelled at. > > > > what happens then is all the development goes on i tizen's fork of efl > > instead, so it cherry-picks random half-complete features from upstream > > git, and then out goes a tizen release WITH those things in it with a > > gold stamp of "quality" .. but upstream has since rejected those api's > > or features (or rejected them to begin with but due to the above to make > > someones reporting easier they were put in regardless of upstream > > approval or not), and you end up again in the situation we have now. > > > > i've advised against this method of working repeatedly, to no avail. my > > advice has been to add no new features and only ctricial bug fixes and > > nothing more to tizen git - but that has never happend and i doubt it > > ever will. the situation literally is that tizen efl is such a large > > fork, for tizen3 we have to throw it all out and start again from > > scratch (from upstream). that is exactly what is happening. > > > > if we are lucky people will find/cherry-pick some patches from tizen efl > > into upstream, but many will not as they have already been rejected for > > various reasons. it will happen AGAIN and AGAIN unless this way of > > development changes. as i see no way we can sensibly say "sorry app devs > > - you wait 1/2/3 months until a sync from an upstream release to get > > that feature", then it is a NECESSITY to track master. ESPECIALLY during > > such a brute-force "reset and start again" period that will effectively > > break many/most apps depending on efl due to them depending on a fork in > > tizen. > > > > policy simply fails given the development methods employed here in this > > situation. > > > > this is after 5+ years of experience on this and i see no sensible way > > other than to track master for the purpose of tracking features, and > > track upstream stable for the purpose of putting out "stable > > images/packages". both need to be tracked. it's the only thing that will > > work. > > Ideally use upstream efl and fix the apps, Is that your proposal? If so > I totally agree. Besides the nature of maintaining a fork like you yes. use upsteram . ro what i call "99.9% upstream". ie - it's upstream EXCEPT for a very very small set of patches. some of them may be emergency bugfixes that havent made their way into upstream yet (but we are pretty good about these - we normally review submitted patches relatively quickly - within a few days or week or 2 in most cases), or for the very few things tht really should be tizen specific patches - i actually know of little to nothing that should be in the latter category other than conflicts of policy. most things should be configurable at runtime thought instead of being patches. the question realy is more how to do the runtime config changes so everyone is happy. :) > described above we've seen many non-sense *tizen only* changes on > efl+elementary. I definitively support the idea of dropping the tizen > efl and using upstream. that's basically the plan - BUT as aboe - there is the need for the odd patch here or there and emergency fixes or workarounds that are getting a more thorough going over upstream still. what needs to happen is for this delta to remain manageable and small. not to grow into a beast like now. the result of keeping the delta small will be much more rapid upgrades, and that means really good thins like better wayland support faster and earlier. optimizations "by desgin changes" come in sooner. > Regards... > > -- > Dorileo > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
