On Wed, Nov 9, 2011 at 12:16 PM, Mike Blumenkrantz <m...@zentific.com> wrote:
>
> On Tue, 8 Nov 2011 16:33:42 +0900
> Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote:
>
> > On Tue, 8 Nov 2011 07:23:27 +0100 (CET) Vincent Torri <vto...@univ-evry.fr>
> > said:
> >
> > >
> > >
> > > On Mon, 7 Nov 2011, Carsten Haitzler (The Rasterman) wrote:
> > >
> > > > attached. this was a sample edc that would be able to play audio, not
> > > > just
> > > > single samples but whole sequences across multiple tracks as well as
> > > > control specific channels and tracks. it didn't specify looping params
> > > > yet or other additional stuff.
> > >
> > > i've never heard about that sound plan before the commit. The patch was
> > > not public and we could not have discussed about it before the commit. So
> > > I really don't like the way it came into edje.
> >
> > i'm not sure this is much different from anything else that goes on in efl.
> > i
> > have done work for a decade+ without discussing patches on the mailing list
> > first. so have most developers. as such this patch this time was going
> > through
> > me. the comments on the patch so far havent actually commented on the edc
> > api
> > it adds at all which everyone is up in arms about "for release". so since
> > everyone complaining isn't actually talking about that... i'll write it here
> > in short form. it adds:
> > sounds {
> > sample {
> > name: "<NAME>" <ENCODING>;
> > source: "<SAMPLE_FILE>";
> > }
> > ...
> > tone: "<NAME>" <FREQ>;
> > ...
> > }
> > and 2 more actions:
> > PLAY_SAMPLE "<NAME>" <SPEED>;
> > PLAY_TONE "<NAME>" <DURATION>;
> >
> > that's it. unfortunately to make this WORK u need a chunk of infra like
> > being
> > able to load and encode samples into edj files, decode them, play and mix
> > them, resample them, etc. all of which is opaque to the api.
> >
> >
> >
> I'm fairly certain that his objection is not to the API or features it
> introduces, but for the timetable and lack of PUBLIC review for such a huge
> patch. You continue to claim that "it's tiny" and "it only affects you if you
> are using the features it introduces". Both of these are false claims which
> have been disproved by me and others.
> We have less than two weeks until the 1.1 release. Prior to this addition, EFL
> and Edje were considered by everyone in the community be stable and in good
> shape. This is no longer the case, and I'm sure there are many others aside
> from Vincent who would agree with this sentiment.
>
> I vote that the sound API and all related commits be reverted immediately and
> pushed off until after 1.1. Regardless of your expertise on sound
> implementations and how solid you may claim it to be, this feature CANNOT be
> tested sufficiently to meet EFL quality standards before the release. That
> alone
> should be enough to have ensured that it was never committed in the first
> place, other breakages notwithstanding.
Agreed. And to be fair the argument "it was a feature, features were
not frozen, if there was bugs then they have to be fixed in the 2
weeks reserved for that" is not true.
First of all, the merged feature was not complete. It will break
things like edje_inspect, Edje_Edit users (ie: editje) and seems to
break more than that for couple of people.
This seems like: let's commit 'void foo_feature(void) {
puts("todo");}"' to introduce the feature, implementing it during the
feature freeze period reserved to bugfix.
Really, if the freeze is just 2 weeks, what's the point in committing
such a thing at the last minute? Just leave it out, iron the bugs for
1.1, release it ON TIME, then open the trunk and merge it. If there is
a need we can release Edje 1.2 with it in few weeks or months
afterwards.
Given the current approach what happens is that 2 weeks of bugfixing
will not be enough, then we'll extend it, delaying the whole thing for
everybody that depends on releases. People willing to merge features
will give a big "Let's do the same -- don't care" and will merge their
own stuff, calling it tested, trusted and small... that's the
never-ending story we all know :-(
I do support Mike on this topic.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
