Hello.
I let this thread sit for a while to get some more insights.
On 07/02/17 03:56, Jean-Philippe André wrote:
> Hey,
>
> Sorry, it looks like I worded my questions badly :)
>
> On 6 February 2017 at 20:36, Gustavo Sverzut Barbieri <barbi...@gmail.com>
> wrote:
>
>> On Mon, Feb 6, 2017 at 8:31 AM, Stefan Schmidt <ste...@osg.samsung.com>
>> wrote:
>>> Hello.
>>>
>>> On 06/02/17 10:33, Jean-Philippe André wrote:
>>>> Hi,
>>>>
>>>> On 1 February 2017 at 23:46, Stefan Schmidt <ste...@osg.samsung.com>
>> wrote:
>>>>
>>>>> Hello.
>>>>>
>>>>> On 12/12/16 11:34, Stefan Schmidt wrote:
>>>>>> Hello.
>>>>>>
>>>>>> Next try. People started to ask me about 1.19 again more recently so
>>>>>> here is my new schedule proposal for 1.19.
>>>>>>
>>>>>> 2016-08-11 Merge window for 1.19 opens
>>>>>> 2017-02-07 Merge window is over.
>>>>>> * Only bug fixes from this point
>>>>>> * Alpha release tarball
>>>>>> * One month stabilization phase starts
>>>>>> 2017-02-13 Beta1 release tarball
>>>>>> * Only critical fixes from this point
>>>>>> 2017-02-20 Beta2 release tarball
>>>>>> 2017-02-27 Beta3 release tarball
>>>>>> 2017-03-06 EFL 1.19 is out (First Monday in March)
>>>>>>
>>>>>> Comments?
>>>>>
>>>>> I heard two people in favor and no complains. If you want to postpone
>>>>> this state this NOW or I will proceed as the above schedule.
>>>>>
>>>>
>>>> I'm currently working on improving the Gfx Filters (evas filters for
>> blur,
>>>> etc...), adding new features and moving to GL. I don't know exactly how
>>>> long I still need but I'm not ready right now to merge this work in
>>>> progress unless we disable the GL accel by default (fine by me).
>>>
>>> What is so important about it that is has to be in this release? Why is
>>> the next one not good enough for it?
>>
>
> Not much besides the personal burden of maintaining a branch and rebasing
> it. I can handle that :)
Great, thanks.
>
>
>>>> As for the EO interfaces we are obviously not ready to finalize now.
>>>
>>> And how making this a blocker for the release turned out you have seen
>>> last year already? Same mistakes all over again?
>>>
>>>> Cmake is also work in progress...
>>>
>>> I already stated before that I'm not going to wait for cmake to be
>>> default in 1.19. This effort needs a lot more time and I want at least
>>> one more release where autotools is the default. Its not even near
>>> completion of what we have with autotools right now.
>>
>> yes, don't wait on cmake as it won't happen soon. We're just starting
>> to convert, after everything is converted we'll need to check for
>> other platforms (BSD, MacOS and Windows), then check if the build is
>> the same (ie: compiler/linker flags are not there, and if they were,
>> are they producing the same effect? same for all the #ifdef's that
>> maybe silently hide behavior changes).
>>
>
> My only point with gl filters, eo intf and cmake is that we have those
> works in progress that need to be put on hold if we're intent on doing this
> release properly. In other words: stop developing in branches, except for
> the regular rebase on master, and focus on fixing existing issues.
Understood now. :)
That is basically the same feeling raster does express. Putting active
work aside to work on stabilization. Its about timing. The work on cmake
and eo/intf will keep us busy for a way longer time though. Which means
at some point we would have to stop the work anyway for another release.
My stanca here is that we might do a release now so we have a few months
of uninterrupted development work afterwards. :)
>>
>> Time-based releases keep the expectations if they are followed. Once
>> we miss the frame, we start to have this feature-based releases ("oh,
>> waited so long, can wait a bit more") and when people work
>> independently, they always have some in-flux work that could get in...
>> so at some point these guys will want to delay a bit more so their
>> work gets in as well... endless wait -- AKA e17/efl-1.0
>>
>> IOW: just do it, and let's not miss the 3 month schedule next time. ;-)
>>
>
> I agree. I didn't mean to disagree, I just wanted the question to be raised.
> And yes, we shouldn't have postponed this release so much once we realised
> that the EO APIs would not be ready so soon.
Agreed as well :)
> In fact it would probably be safer to strictly stick to the 3 months
> schedule and postpone features rather than postponing releases.
I would be fine with this. Its just that I don't wanted to step on other
peoples feet by demanding them to work on a release now. I'm ok with
smaller slips in the schedule and if things need to be discussed that is
also ok to hold of the schedule (like right now), but last year was a
real setback from what we had before and I wanted to address that.
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
