Hello.
On 05/31/2017 04:12 PM, Simon Lees wrote:
On 31/05/17 22:42, Stefan Schmidt wrote:
Hello.
On 05/31/2017 02:36 PM, Simon Lees wrote:
On 31/05/17 19:07, Stefan Schmidt wrote:
Hello.
No idea when Mike is planning a new E release where all this drm and
wayland patches and APIs would be needed. Have to check back with him.
There are other parts of e including but not limited to bryce that still
need more work. Either way e will have a stability phase / freeze anyway
so if that did become ready to happen we could also start the efl one
and do the two releases at a similar time.
If that happens to be at the same time by chance I see no problem, but I
will not adapt the efl release schedule to the E one. They have been
driven quite differently and that worked well for both sides. At least I
can say that from my side.
And lets be frank here (not pissed but simply frank). I think the last
two releases have been very bad.
o You and other wanted to wait longer and longer before a release should
happen to reduce pain with app using the EO API
o Other asked me when there finally will be a new release so they do not
have to depend on and use HEAD
o The long development phase resulted in a _very_ long stabilization
phase due to the many changes coming in.
o So long that many developers did not look at bug fixing anymore and
started to develop new stuff in branches.
o Nobody could tell when a release will be done. It the Debian way "its
done when its done" allover again.
I'm doing the efl releases since 1.9 (3.5 years by now) and I invested a
huge amount of time and energy to fine tune the process and finding ways
to make it work for as many parties as possible. Personally I'm proud of
what we achieved in that regard.
If we are now going to change this all back to how efl was released
before I will not stand in the way, but I will also not handle the
releases anymore. No bad feelings, no tears, no blood. :) I will simply
step down as release manager and let someone else take over. Maybe some
fresh vibes could help, who knows? :)
regards
Stefan Schmidt
I agree the 3 month cycle works much better and I really want to go back
to it but right now it creates effort and I don't want that effort for
no reason,
It just moves the effort. We had to spent way more time on the 1.19
stabilization then we had spent on two stabilization phases with the 3
months schedule. It delayed and delayed and delayed. And it took of
resources from the interfaces work as well. Delaying that one as well.
the minute people start asking "hen there finally will be a
new release so they do not have to depend on and use HEAD" is the time
when we should start the stabilization phase but if knowone needs the
release and especially if eo people feel they don't need huge amounts of
time to finish I don't think we should release.
What makes make you think they feel that way? Did they tell you? Because
JP actually told me that we should definitely not wait on the eo
interfaces work for the release.
Interfaces is a _huge_ task. And even when the work being under way
right now is done it need to be tested, used, changed and tested again
before we can go ahead and mark it as our new stable API for the years
to come. This is nothing that just happens within the next two months.
We are writing in circles here anyway. You have written what you have
written here at least two times before and I have done the same (and
interfaces is still not marked as stable ;))
Based on the same discussions the last two rounds I changed the schedule
the with no benefit, but more work from my point of view. I will not do
this for 1.20 again. If a longer schedule for 1.20 is wanted that is
fair enough but someone else would need to handle the release in that
case. I'm not willing to do this. And it would make my life way simpler
if someone steps up to handle the releases. :)
regards
Stefan Schmidt
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
