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).
and the other reason - the developers being the ones who work on tizen
apps - eg in samsung. i explained how things work above. policy just
doesn't work. oh sure. we can just fork an interal "inside samsung only"
efl git repo again like early on in tizen 1 days and just code dump it
all without warning. would that make you happier since it'd not violate
"policy". :)
aaah history repeats. how wonderful. :)
--
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
