On 01/03/2014 09:58 PM, Ylinen, Mikko wrote:
On Fri, Jan 3, 2014 at 2:24 PM, Carsten Haitzler <[email protected] <mailto:[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] <mailto:[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] <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. 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.
yes - why thus we need to track BOTH master AND stable. there is a need for both. in fact mobile likely needs to track both indefinitely too as per above explanation. due to the way developers work they MUSt have their lates features NOW and can't/won't wait for a version upgrade. in the past this has led to development being done *IN* tizen git repositories with no upstream reviews or approval and thus api's being baked into tizen releases that have since been rejected by upstream. that has caused a fork. so no matter what, tizen git repositories have acted as "master git development" repos just as a distant fork of upstream and then the big merge pain as we have now. it'll happen again and again unless we address the issue. the need is to be able to build packages and images with both "latest and greates unstable development features" AND "stable and released only api's and features". thus both need tracking. IVI may choose never to use the "latest and greatest" packages/branches/repos, but mobile has to due to the nature of the development teams and their workflow.
efl 1.8 already is a new git repo vs tizen 2 anyway since upstream re-organized to have a single src tree for efl (elementary is separate still).
-- 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
