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
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.
Regards...
--
Dorileo
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
