On Tue, 7 Feb 2017 11:56:38 +0900 Jean-Philippe André <j...@videolan.org> said:

> 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.

this is an issue. the cmake work has to stop then. well it can go off to a
branch... but it cant happen in master.

> >> 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 really don't see that there is *ANY* value in "releasing eo api" unless we
ALSO release interfaces that work on top of it. until then its academic and
pointless.

> > 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.

then we need to pause various work and stop doing any eo/interfaces work or
filters, cmake etc. and get down to bug fixing if we are to do a release...

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
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

Reply via email to