Hi, There is a concerted effort now to try and fix up the documentation of EFL for devs / contributors and for users of our apps. The dev portion of this is obviously largely based around the interfaces work as everything will be "legacy" at some point in the near future. We only have a limited time available to get all this done and I think we should be able to publish the docs at completion if not before. Therefore it is becoming more important to figure out where we are going to get to, by when (or at least a target that we can all agree on).
Given that the parent ticket https://phab.enlightenment.org/T5301 was created in March and we're in October now with around 1/3 - 1/2 of the work done (guesstimating here as there is no obvious way to see how much progress we are making (only about 1/5 of tickets are closed off)) and even in the last month we are adding new sub-tasks twice as fast as we are closing tickets it seems like an impractical target to get any sort of stable interfaces API subset ready for the end of the year. I really think we need to get a handle on this - agree what *must* be done to even have a "ready to start being used" API so we can focus and finally get something out of the door to build on. My proposal is this: A new parent ticket is created for "Nice to have Interfaces" and another for "Not first release Interfaces" and we move everything off that main ticket that is non-essential. Only then will we get a feeling for what remains. Personally I find moving targets difficult to work to and very morale draining - I'd be very surprised if there are not others out there feeling the same way. Thanks, and as always please fire your thoughts back team :). Andrew On Tue, 12 Sep 2017 at 12:44 Carsten Haitzler <ras...@rasterman.com> wrote: > 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 > > -- 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
