On Fri, Jan 3, 2014 at 11:05 AM, Carsten Haitzler <[email protected]>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]>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. > Who would be the users of upstream master? With the current infra, it'd require a separate OBS project and repo AFAICT. Both Tizen:Mobile and Tizen:IVI should use the same EFL stable branch version. -- Mikko
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
