On Fri, Jan 3, 2014 at 2:24 PM, Carsten Haitzler <[email protected]>wrote:
> > On 01/03/2014 09:04 PM, Ylinen, Mikko wrote: > > > 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. > > > see above. they can't because everything will be broken for a long while > to come until it's fixed and FIXES have to be worked at upstream due to the > fact that tizen has decided to fork in a non-mergable way (what is a > released tizen efl release is incompatible with an upstream one). > > Oh, this wasn't clear in your proposal. Basically you're saying Tizen/Tizen IVI need to continue using platform/upstream/e* and platform/upstream/efl with upstream stable branche and Mobile needs to take upstream master in profile/mobile/e* until all EFL apps fixed. -- Mikko
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
