[prev in list] [next in list] [prev in thread] [next in thread] 

List:       enlightenment-devel
Subject:    Re: [E-devel] Phab EFL ticket management
From:       Carsten Haitzler <raster () rasterman ! com>
Date:       2017-09-12 11:44:02
Message-ID: 20170912204402.ca2b137d2c7e589de44c8915 () rasterman ! com
[Download RAW message or body]

On Tue, 12 Sep 2017 09:50:18 +0000 Andrew Williams <andy@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 <raster@rasterman.com> wrote:
> 
> > On Mon, 21 Aug 2017 12:08:46 +0000 Andrew Williams <andy@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 <raster@rasterman.com>
> > wrote:
> > >
> > > > On Sat, 15 Jul 2017 20:12:34 +0000 Andrew Williams <
> > andy@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)    raster@rasterman.com
> > > >
> > > > --
> > > http://andywilliams.me
> > > http://ajwillia.ms
> >
> >
> > --
> > ------------- Codito, ergo sum - "I code, therefore I am" --------------
> > The Rasterman (Carsten Haitzler)    raster@rasterman.com
> >
> > --
> http://andywilliams.me
> http://ajwillia.ms


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster@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
[prev in list] [next in list] [prev in thread] [next in thread]