On Tue, 12 Sep 2017 09:50:18 +0000 Andrew Williams <a...@andywilliams.me> said:
> Hi, > > This is good to hear. Reflecting on it I think what I missed was the > clarity that 1.21 would not be released until these interfaces are stable. Actually that's not set in stone. We may release a 1.21 and defer interfaces for 1.22. It depends on timing and where things get to by what time. The way we are doing things, interfaces is an OPTIONAL blocker for a release. It's not a technical one. The GOAL is to have 1.21 by end of year or so with interfaces "ready to begin to be used as a stable API". > Having been looking for this since 1.19 I'm thrilled but wonder if everyone > is on the same page (maybe it was only clear within Samsung crew?). Should > we be documenting somewhere like an upcoming releases page that, whilst > normally a timed cycle, for this release we have a specific goal in mind > rather than a date? > > Thanks, > Andy > On Mon, 21 Aug 2017 at 13:24, Carsten Haitzler <ras...@rasterman.com> wrote: > > > On Mon, 21 Aug 2017 12:08:46 +0000 Andrew Williams <a...@andywilliams.me> > > said: > > > > > Hi, > > > > > > In a word no. What that is is an ever growing list of work we would like > > to > > > get done. That's not really a planning tool it's a log. > > > Planning for what goes into a release is a different beast - we make a > > list > > > of what's required, agree on it and start working through. > > > > that actually is the list of things to go into 1.21 (efl interfaces "done" > > release)... :) > > > > > Surely in planning for a release you need either a) a delivery date and a > > > prioritised list or b) a requirements list and an agreed scope. > > > A list of things that gets added to as we work through is not either of > > > those - the list could grow forever and never get finished... > > > > things are discovered as the work is done. the goal is clear make eo/efl > > interfaces stable and ready to use for application devs". > > > > > Andy > > > On Mon, 21 Aug 2017 at 11:41, Carsten Haitzler <ras...@rasterman.com> > > wrote: > > > > > > > On Sat, 15 Jul 2017 20:12:34 +0000 Andrew Williams < > > a...@andywilliams.me> > > > > said: > > > > > > > > just saying... isn't > > > > > > > > https://phab.enlightenment.org/T5301 > > > > > > > > good enough? i mean it does what's needed. tacks a todo list and even > > > > dependencies... etc. > > > > > > > > > Hi team, > > > > > > > > > > As many would probably agree by now we have a very high ticket volume > > > > which > > > > > is rather hard to manage... Whilst folk are doing a great job of > > > > > marshalling the incoming tasks I think that some more structure would > > > > help > > > > > us to see what is needed in each area and for the next release etc... > > > > > > > > > > In preparation for 1.21 I would like to start working on this a > > little to > > > > > help us manage the work for our next release (especially as it will > > be > > > > the > > > > > eo interfaces release!) and propose to do the following in phab, as > > it is > > > > > otherwise managing to keep track well: > > > > > > > > > > * Add a milestone to efl phab project for the next release - this > > will be > > > > > used to mark the issues we have agreed must go into the next release > > > > > * Add sub projects for each area of EFL so we can better categorise > > the > > > > > tasks (we can either use EFL or a "common" subproject for those that > > > > apply > > > > > to all > > > > > * efl-eina > > > > > * efl-eolian > > > > > * efl-canvas > > > > > * efl-canvas-layout > > > > > * efl-ui > > > > > (etc etc) > > > > > > > > > > Notice the use of the new namespaces for everything in the > > interfaces - > > > > > this is surely how we should be thinking going forward :) > > > > > If we are able to split things out a bit more then we can have more > > > > people > > > > > assigned to projects with fewer issues per project. > > > > > Then the milestone for release can be the main point of concern for a > > > > > release manager :) > > > > > > > > > > I wanted to throw the concept out to the list before doing anything > > in > > > > case > > > > > there are any concerns with this approach that I may have missed? > > > > > > > > > > Thanks :) > > > > > Andy > > > > > -- > > > > > http://andywilliams.me > > > > > http://ajwillia.ms > > > > > > > > > > > ------------------------------------------------------------------------------ > > > > > 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 > > > > > > > > > > > > > > > > > -- > > > > ------------- Codito, ergo sum - "I code, therefore I am" > > -------------- > > > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > -- > http://andywilliams.me > http://ajwillia.ms -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- 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
