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 :)
> >> 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.
>> So I'm just wondering: what are we trying to achieve by releasing now?
> >
> > Pretty simple. Getting all the code we did since August last year to our
> > actual users. I think there has been a lot of worthy changes for a
> release.
>
> also big YES :-)
>
> Like I'd love to see efl_net being tested in the field as it's what
> ecore_con uses internally to provide legacy, as well as people being
> able to use the Eo API directly.
>
People can't use the EO API directly. Or are we declaring EO stable now? If
so we need to properly separate which EO APIs are "final" and which are
still work in progress (all UI). So, efl_net will be tested only through
ecore_con.
efl_net itself will wait until the rest of EO is released. Or did I miss
something?
> >> I'm not saying we shouldn't release but I wonder if we should stop
> >> development and go on a bug hunt for the next month (ie. delay EO
> >> interfaces again a bit more).
> >
> > I really wonder what happened in the EFL community regarding releases
> > over the last 9 months or so. We had a pretty solid run with the 3
> > months release schedule. People did know what they could expect.
> > Developers when to get their code in and distributions and users when a
> > new release will come out.
> >
> > Every time a propose a release schedule now someone steps up and thinks
> > that we should wait for feature n and also feature n+1. Even if we do
> > not know how long this will take. Basically the feature based releases
> > mindset from efl before 1.0. :)
> I start to wonder if it is just total bias I have here when thinking
> > that the time based releases have been a big step forward. Maybe it the
> > rest of the community actually wants to have feature based releases and
> > is fine with waiting a year or two for such a release. I really do not
> > know anymore. :) If that turns out to be the case I would gladly hand
> > over (not bad blood involved at all).
>
> 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.
In fact it would probably be safer to strictly stick to the 3 months
schedule and postpone features rather than postponing releases.
--
Jean-Philippe André
------------------------------------------------------------------------------
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
