Re: [E-devel] Community Scheduling

[Carsten Haitzler]

On Sat, 14 Jul 2018 12:01:34 +0300 Jonathan Aquilina 
said:

> Where can I begin?

first step is writing code that uses efl api's. then writing simple mini-apps.
they don't have to have a gui, but tbh to get better coverage at this point and
best "bang for your buck" or "more code paths covered per hour spent on tests"
would probably be exactness.

https://git.enlightenment.org/tools/exactness.git/
https://git.enlightenment.org/tools/exactness-elm-data.git/
https://git.enlightenment.org/tools/exactness-edje-data.git/

what exactness does is run an app and record its output at specific time points
(the pixels) as well as feed recorded input into it. if the output pixels don't
match some pre-recorded ones, then something possibly changed - a bug, or
maybe an incompatible change. this will cover a lot of code in such tests
because it drives efl at the higher api levels with a full working "mini app".
e.g. just pop up a window with a list, scroll down, select something, change
the state of a button from disabled to enabled, for example. you can record
multiple input + output sessions with the same mini-app.

the reason i suggest this to begin with is that it's going to not require
detailed knowledge of how an api must work (unit tests testing specific pre and
post conditions), and is useful in that the knowledge here can build actual
useful applications too pretty much in full, where writing tests for "ecore
ipc" really only exercises a small subset of useful api (but in gory detail).

of course there are the unit tests. they are in src/tests/ ... have a look at
them.  grep for main in each dir to find the file(s) that produce the
executables and note how they register each test function, then each test func
may in turn run more tests etc. etc. ... ... add more functions that are not
covered already. note that this is why i suggested the above first as it's
gentler to begin with IMHO.

> Sent from my iPhone
> 
> > On 14 Jul 2018, at 10:25, Carsten Haitzler  wrote:
> > 
> > On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina
> >  said:
> > 
> >> Hi Raster with what you said below and other threads I’ve seen with people
> >> complaining about lack of unit tests etc wouldn’t it be better to get
> >> nightly builds to those that like to be on bleeding edge and help us test
> >> and report bugs. Not to mention I think nightly builds are possible as I
> >> see a lot of things that get committed to the repos on a daily basis at
> >> times.
> > 
> > we already have that - jenkins and now travis builds every commit. there is
> > no point building daily if you are building every commit already.
> > 
> > the issue isn't the builds, it's the tests themselves. having them cover
> > everything in an efficient and sensible way. in fact lowering the barrier of
> > entry to making a test... that's the work needed. :)
> > 
> >> My take like this is engaging the community and user base more.
> >> 
> >> Let me ask you this and it’s more to ponder on. How much of the current
> >> user base is on the latest and greatest?
> >> 
> >> Sent from my iPhone
> >> 
> >>> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman)
> >>>  wrote:
> >>> 
> >>> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina
> >>>  said:
> >>> 
>  I think it was me not being clear I think what I’m thinking is nightly
>  tar balls and if need be I’m willing to work on pre packaged binaries for
>  nightly builds
> >>> 
> >>> TBH fixes don't move into a stable branch fast enough to justify
> >>> nightlies. they go in over time maybe every few days or weeks then every
> >>> now and again a point release goes out with them after a "does it compile
> >>> and pass tests" check. these releases are incredibly easy and simple and
> >>> can be automated, but no point having them nightly - just a "we have
> >>> enough fixes now - push one out" time point.
> >>> 
>  Sent from my iPhone
>  
> > On 13 Jul 2018, at 18:46, Stefan Schmidt 
> > wrote:
> > 
> > Hello.
> > 
> >> On 13.07.2018 11:27, Jonathan Aquilina wrote:
> >> I was even thinking weekly point releases to get any new code or bug
> >> fixes out for early testing.
> > 
> > Hmm, not sure I get you here. What I talk about are stable updates which
> > would only contain fixes. No new code and definitely not used for
> > testing at the users systems. These should only ship with verified
> > fixes.
> > 
> > regards
> > Stefan Schmidt
> > 
> > --
> > 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
>  
>  
>  

Re: [E-devel] Community Scheduling

[Mike Blumenkrantz]

Sure, have a great time!

On Sat, Jul 14, 2018 at 12:33 PM Jonathan Aquilina 
wrote:

> It would have to be after he 22nd as I am currently on honeymoon is that
> ok for you
>
> Sent from my iPhone
>
> > On 14 Jul 2018, at 19:20, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
> >
> > If you have interest in writing tests it's actually very simple, and I
> > would not expect a new unit test to take more than 1-2 minutes to write
> and
> > run. The biggest issue with it at present is that there are no docs for
> it.
> > I can try to work with you a bit on this (mentoring test writing and
> adding
> > some docs for it) next week if you can be around on IRC, just let me
> know.
> >
> > On Sat, Jul 14, 2018 at 5:02 AM Jonathan Aquilina <
> jaquil...@eagleeyet.net>
> > wrote:
> >
> >> Where can I begin?
> >>
> >> Sent from my iPhone
> >>
> >>> On 14 Jul 2018, at 10:25, Carsten Haitzler 
> wrote:
> >>>
> >>> On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina <
> >> jaquil...@eagleeyet.net>
> >>> said:
> >>>
>  Hi Raster with what you said below and other threads I’ve seen with
> >> people
>  complaining about lack of unit tests etc wouldn’t it be better to get
> >> nightly
>  builds to those that like to be on bleeding edge and help us test and
> >> report
>  bugs. Not to mention I think nightly builds are possible as I see a
> lot
> >> of
>  things that get committed to the repos on a daily basis at times.
> >>>
> >>> we already have that - jenkins and now travis builds every commit.
> there
> >> is no
> >>> point building daily if you are building every commit already.
> >>>
> >>> the issue isn't the builds, it's the tests themselves. having them
> cover
> >>> everything in an efficient and sensible way. in fact lowering the
> >> barrier of
> >>> entry to making a test... that's the work needed. :)
> >>>
>  My take like this is engaging the community and user base more.
> 
>  Let me ask you this and it’s more to ponder on. How much of the
> current
> >> user
>  base is on the latest and greatest?
> 
>  Sent from my iPhone
> 
> > On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman)
> >  wrote:
> >
> > On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina
> >  said:
> >
> >> I think it was me not being clear I think what I’m thinking is
> >> nightly tar
> >> balls and if need be I’m willing to work on pre packaged binaries
> for
> >> nightly builds
> >
> > TBH fixes don't move into a stable branch fast enough to justify
> >> nightlies.
> > they go in over time maybe every few days or weeks then every now and
> >> again
> > a point release goes out with them after a "does it compile and pass
> >> tests"
> > check. these releases are incredibly easy and simple and can be
> >> automated,
> > but no point having them nightly - just a "we have enough fixes now -
> >> push
> > one out" time point.
> >
> >> Sent from my iPhone
> >>
> >>> On 13 Jul 2018, at 18:46, Stefan Schmidt <
> ste...@datenfreihafen.org>
> >>> wrote:
> >>>
> >>> Hello.
> >>>
>  On 13.07.2018 11:27, Jonathan Aquilina wrote:
>  I was even thinking weekly point releases to get any new code or
> bug
>  fixes out for early testing.
> >>>
> >>> Hmm, not sure I get you here. What I talk about are stable updates
> >> which
> >>> would only contain fixes. No new code and definitely not used for
> >>> testing at the users systems. These should only ship with verified
> >> fixes.
> >>>
> >>> regards
> >>> Stefan Schmidt
> >>>
> >>>
> >>
> --
> >>> 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
> >>
> >>
> >>
> >>
> --
> >> 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"
> >> --
> > Carsten Haitzler - ras...@rasterman.com
> >
> 
> >>>
> >>>
> >>> --
> >>> - Codito, ergo sum - "I code, therefore I am"
> --
> >>> Carsten Haitzler - ras...@rasterman.com
> >>>
> >>
> >>
> >>
> >>
> 

Re: [E-devel] Community Scheduling

[Jonathan Aquilina]

It would have to be after he 22nd as I am currently on honeymoon is that ok for 
you

Sent from my iPhone

> On 14 Jul 2018, at 19:20, Mike Blumenkrantz  
> wrote:
> 
> If you have interest in writing tests it's actually very simple, and I
> would not expect a new unit test to take more than 1-2 minutes to write and
> run. The biggest issue with it at present is that there are no docs for it.
> I can try to work with you a bit on this (mentoring test writing and adding
> some docs for it) next week if you can be around on IRC, just let me know.
> 
> On Sat, Jul 14, 2018 at 5:02 AM Jonathan Aquilina 
> wrote:
> 
>> Where can I begin?
>> 
>> Sent from my iPhone
>> 
>>> On 14 Jul 2018, at 10:25, Carsten Haitzler  wrote:
>>> 
>>> On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina <
>> jaquil...@eagleeyet.net>
>>> said:
>>> 
 Hi Raster with what you said below and other threads I’ve seen with
>> people
 complaining about lack of unit tests etc wouldn’t it be better to get
>> nightly
 builds to those that like to be on bleeding edge and help us test and
>> report
 bugs. Not to mention I think nightly builds are possible as I see a lot
>> of
 things that get committed to the repos on a daily basis at times.
>>> 
>>> we already have that - jenkins and now travis builds every commit. there
>> is no
>>> point building daily if you are building every commit already.
>>> 
>>> the issue isn't the builds, it's the tests themselves. having them cover
>>> everything in an efficient and sensible way. in fact lowering the
>> barrier of
>>> entry to making a test... that's the work needed. :)
>>> 
 My take like this is engaging the community and user base more.
 
 Let me ask you this and it’s more to ponder on. How much of the current
>> user
 base is on the latest and greatest?
 
 Sent from my iPhone
 
> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman)
>  wrote:
> 
> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina
>  said:
> 
>> I think it was me not being clear I think what I’m thinking is
>> nightly tar
>> balls and if need be I’m willing to work on pre packaged binaries for
>> nightly builds
> 
> TBH fixes don't move into a stable branch fast enough to justify
>> nightlies.
> they go in over time maybe every few days or weeks then every now and
>> again
> a point release goes out with them after a "does it compile and pass
>> tests"
> check. these releases are incredibly easy and simple and can be
>> automated,
> but no point having them nightly - just a "we have enough fixes now -
>> push
> one out" time point.
> 
>> Sent from my iPhone
>> 
>>> On 13 Jul 2018, at 18:46, Stefan Schmidt 
>>> wrote:
>>> 
>>> Hello.
>>> 
 On 13.07.2018 11:27, Jonathan Aquilina wrote:
 I was even thinking weekly point releases to get any new code or bug
 fixes out for early testing.
>>> 
>>> Hmm, not sure I get you here. What I talk about are stable updates
>> which
>>> would only contain fixes. No new code and definitely not used for
>>> testing at the users systems. These should only ship with verified
>> fixes.
>>> 
>>> regards
>>> Stefan Schmidt
>>> 
>>> 
>> --
>>> 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
>> 
>> 
>> 
>> --
>> 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"
>> --
> Carsten Haitzler - ras...@rasterman.com
> 
 
>>> 
>>> 
>>> --
>>> - 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
>> 
> 

Re: [E-devel] End of Week: Phab Report

[Jonathan Aquilina]

Hi mike I can code in python and take it as a chance to brush up on my python 
scripting skills.

Any chance you can open a ticket and assign it to me please

Sent from my iPhone

> On 14 Jul 2018, at 19:25, Mike Blumenkrantz  
> wrote:
> 
> I suppose it's possible? Phabricator itself doesn't have any facilities for
> such a thing, but I think it should be doable to write a script to:
> 
> * scrape the ticket and patch review infrastructure and total the number of
> tickets in each query.
> * put the numbers into a mail template
> * send a mail to this list
> 
> Most likely the script would need to be python like git-phab or a shell
> script that uses 'arc call-conduit' to manually trigger phabricator methods.
> 
> On Sat, Jul 14, 2018 at 3:07 AM Jonathan Aquilina 
> wrote:
> 
>> Not to hijack this email but mike is this something which can be automated
>> and sent out weekly basis without any need for human intervention and just
>> use an email template that looks at the Phab tags for information?
>> 
>> Sent from my iPhone
>> 
>>> On 13 Jul 2018, at 21:18, Mike Blumenkrantz <
>> michael.blumenkra...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I forgot to send this last week and people were feeling demotivated, so
>>> it's back again.
>>> 
>>> TICKETS:
>>> *https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/
>>> *
>>> * 10 regular tasks open with the 1.21 milestone
>>> Some work has already been done on these, and the number has once again
>>> been cut in half since the last report.
>>> * 4 regression tickets open which must be resolved before the final 1.21
>>> release
>>> All of these already have patches in review, no further work beyond
>>> review/testing is required.
>>> * This search query is now available in the sidebar of the maniphest view
>>> for easier access.
>>> 
>>> PATCHES
>>> *https://phab.enlightenment.org/differential/query/38N2dAUrUZ7J/
>>> *
>>> * 13 patches awaiting review
>>> * This search query is now available in the sidebar of the differential
>>> view for easier access.
>>> 
>>> If you aren't submitting your patches for review yet, please consider
>> doing
>>> so using the documentation here:
>> https://phab.enlightenment.org/w/arcanist/
>>> 
>>> Build status is green at present, tests are all passing as well. Next
>> week
>>> is a big Samsung internal event, so some slowdown may occur.
>>> 
>>> Regards,
>>> Mike
>>> 
>> --
>>> 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
>> 
>> 
>> 
>> --
>> 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
>> 
> --
> 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


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

Re: [E-devel] End of Week: Phab Report

[Mike Blumenkrantz]

I suppose it's possible? Phabricator itself doesn't have any facilities for
such a thing, but I think it should be doable to write a script to:

* scrape the ticket and patch review infrastructure and total the number of
tickets in each query.
* put the numbers into a mail template
* send a mail to this list

Most likely the script would need to be python like git-phab or a shell
script that uses 'arc call-conduit' to manually trigger phabricator methods.

On Sat, Jul 14, 2018 at 3:07 AM Jonathan Aquilina 
wrote:

> Not to hijack this email but mike is this something which can be automated
> and sent out weekly basis without any need for human intervention and just
> use an email template that looks at the Phab tags for information?
>
> Sent from my iPhone
>
> > On 13 Jul 2018, at 21:18, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
> >
> > Hi,
> >
> > I forgot to send this last week and people were feeling demotivated, so
> > it's back again.
> >
> > TICKETS:
> > *https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/
> > *
> > * 10 regular tasks open with the 1.21 milestone
> > Some work has already been done on these, and the number has once again
> > been cut in half since the last report.
> > * 4 regression tickets open which must be resolved before the final 1.21
> > release
> > All of these already have patches in review, no further work beyond
> > review/testing is required.
> > * This search query is now available in the sidebar of the maniphest view
> > for easier access.
> >
> > PATCHES
> > *https://phab.enlightenment.org/differential/query/38N2dAUrUZ7J/
> > *
> > * 13 patches awaiting review
> > * This search query is now available in the sidebar of the differential
> > view for easier access.
> >
> > If you aren't submitting your patches for review yet, please consider
> doing
> > so using the documentation here:
> https://phab.enlightenment.org/w/arcanist/
> >
> > Build status is green at present, tests are all passing as well. Next
> week
> > is a big Samsung internal event, so some slowdown may occur.
> >
> > Regards,
> > Mike
> >
> --
> > 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
>
>
>
> --
> 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
>
--
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

Re: [E-devel] Community Scheduling

[Mike Blumenkrantz]

If you have interest in writing tests it's actually very simple, and I
would not expect a new unit test to take more than 1-2 minutes to write and
run. The biggest issue with it at present is that there are no docs for it.
I can try to work with you a bit on this (mentoring test writing and adding
some docs for it) next week if you can be around on IRC, just let me know.

On Sat, Jul 14, 2018 at 5:02 AM Jonathan Aquilina 
wrote:

> Where can I begin?
>
> Sent from my iPhone
>
> > On 14 Jul 2018, at 10:25, Carsten Haitzler  wrote:
> >
> > On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina <
> jaquil...@eagleeyet.net>
> > said:
> >
> >> Hi Raster with what you said below and other threads I’ve seen with
> people
> >> complaining about lack of unit tests etc wouldn’t it be better to get
> nightly
> >> builds to those that like to be on bleeding edge and help us test and
> report
> >> bugs. Not to mention I think nightly builds are possible as I see a lot
> of
> >> things that get committed to the repos on a daily basis at times.
> >
> > we already have that - jenkins and now travis builds every commit. there
> is no
> > point building daily if you are building every commit already.
> >
> > the issue isn't the builds, it's the tests themselves. having them cover
> > everything in an efficient and sensible way. in fact lowering the
> barrier of
> > entry to making a test... that's the work needed. :)
> >
> >> My take like this is engaging the community and user base more.
> >>
> >> Let me ask you this and it’s more to ponder on. How much of the current
> user
> >> base is on the latest and greatest?
> >>
> >> Sent from my iPhone
> >>
> >>> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman)
> >>>  wrote:
> >>>
> >>> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina
> >>>  said:
> >>>
>  I think it was me not being clear I think what I’m thinking is
> nightly tar
>  balls and if need be I’m willing to work on pre packaged binaries for
>  nightly builds
> >>>
> >>> TBH fixes don't move into a stable branch fast enough to justify
> nightlies.
> >>> they go in over time maybe every few days or weeks then every now and
> again
> >>> a point release goes out with them after a "does it compile and pass
> tests"
> >>> check. these releases are incredibly easy and simple and can be
> automated,
> >>> but no point having them nightly - just a "we have enough fixes now -
> push
> >>> one out" time point.
> >>>
>  Sent from my iPhone
> 
> > On 13 Jul 2018, at 18:46, Stefan Schmidt 
> > wrote:
> >
> > Hello.
> >
> >> On 13.07.2018 11:27, Jonathan Aquilina wrote:
> >> I was even thinking weekly point releases to get any new code or bug
> >> fixes out for early testing.
> >
> > Hmm, not sure I get you here. What I talk about are stable updates
> which
> > would only contain fixes. No new code and definitely not used for
> > testing at the users systems. These should only ship with verified
> fixes.
> >
> > regards
> > Stefan Schmidt
> >
> >
> --
> > 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
> 
> 
> 
> --
>  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"
> --
> >>> Carsten Haitzler - ras...@rasterman.com
> >>>
> >>
> >
> >
> > --
> > - 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
>
--
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

Re: [E-devel] eina_safety check ERRs

[Mike Blumenkrantz]

Thanks for bringing this up. In an attempt to discover and fix more bugs,
we've added some error messages to functions which should never be passed
null--such as the ones you've listed here. Any time null is passed to one
of these functions, it means that the author of the code was not aware of
an object's existence, and it's likely that a bug will result.

There's an overall tracking task for this here (
https://phab.enlightenment.org/T7030) with subtasks being created for each
area that the errors are found in.

This is a good place for new contributors to jump in, as the fixes for
these issues just involve reading the code a bit to see why the passed
object does not exist.

On Sat, Jul 14, 2018 at 9:06 AM Jean Rene Dawin <
jda...@math.uni-bielefeld.de> wrote:

> Hello,
>
> since about commit b0e0fcf3d60eac53229ce107b01c6d31ce8aa817
>
> elementary_test, elementary_config, terminology throw lots of verbose
> eina_safety ERR messages (see below).
> Just wanted to ask if these messages point to real errors (and how to fix
> them) or if they are maybe false positives.
>
> The tests below were done with efl from commit
> 6fa8c581b564cf85eba89cbb61ebaa067f7da051
> With earlier commit 3c8bc31e75478137c08ea9492c685cb4261a9499 the ERR
> messages were gone or less verbose.
>
> 1. Run elementary_test
> 2. Click "Lyayot2"
> 3. Close Layout2 window.
>
> Output:
>
> ERR<28170>:eina_safety lib/evas/canvas/evas_callbacks.c:539
> evas_object_event_callback_del_full() safety check failed: obj == NULL
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
>
>
> eina_btlog << EOF
> /usr/local/lib/libeina.so.1  0x7f1fb57c8462 0x7f1fb5795000
> ...
>
>
>
>
> 1. Run elementary_config
> 2. Close window
>
> Output:
>
> ERR<28279>:eina_safety lib/elementary/elm_main.c:1760
> elm_object_signal_emit() safety check failed: obj == NULL
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
>
>
> eina_btlog << EOF
> /usr/local/lib/libeina.so.1  0x7f7c7a8e8462 0x7f7c7a8b5000
> ...
>
>
>
>
> 1. Run terminology
> 2. Right Click
> 3. Click Settings
>
> Output:
>
> CRI<27896>:eina_log ../src/bin/win.c:1762 win_new() unknown log domain -1,
> original message level was: WRN
>
> ERR<27896>:eo lib/eo/eo.c:2113 efl_data_scope_get() Eo ID 0x55ddef262c10
> is not a valid object. Current thread: main. This ID has probably been
> deleted or this was never a valid object ID. (domain=2, current_do
> main=0, local_domain=0, available_domains=[0 1], generation=10,
> id=98b, ref=1)
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
>
> eina_btlog << EOF
> /usr/local/lib/libeina.so.1  0x7fb0e87f4462 0x7fb0e87c1000
> ...
>
> ERR<28445>:eina_safety lib/evas/canvas/evas_callbacks.c:539
> evas_object_event_callback_del_full() safety check failed: obj == NULL
> ## Copy & Paste the below (until EOF) into a terminal, then hit Enter
> ...
>
>
> Regards,
> Jean Rene
>
>
> --
> 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
>
--
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

[E-devel] eina_safety check ERRs

[Jean Rene Dawin]

Hello,

since about commit b0e0fcf3d60eac53229ce107b01c6d31ce8aa817

elementary_test, elementary_config, terminology throw lots of verbose 
eina_safety ERR messages (see below).
Just wanted to ask if these messages point to real errors (and how to fix them) 
or if they are maybe false positives.

The tests below were done with efl from commit 
6fa8c581b564cf85eba89cbb61ebaa067f7da051
With earlier commit 3c8bc31e75478137c08ea9492c685cb4261a9499 the ERR messages 
were gone or less verbose.

1. Run elementary_test
2. Click "Lyayot2"
3. Close Layout2 window.

Output:

ERR<28170>:eina_safety lib/evas/canvas/evas_callbacks.c:539 
evas_object_event_callback_del_full() safety check failed: obj == NULL
## Copy & Paste the below (until EOF) into a terminal, then hit Enter   
  

  
eina_btlog << EOF
/usr/local/lib/libeina.so.1  0x7f1fb57c8462 0x7f1fb5795000
...




1. Run elementary_config 
2. Close window

Output:
   
ERR<28279>:eina_safety lib/elementary/elm_main.c:1760 elm_object_signal_emit() 
safety check failed: obj == NULL
## Copy & Paste the below (until EOF) into a terminal, then hit Enter   
   

   
eina_btlog << EOF
/usr/local/lib/libeina.so.1  0x7f7c7a8e8462 0x7f7c7a8b5000
...




1. Run terminology
2. Right Click
3. Click Settings

Output:

CRI<27896>:eina_log ../src/bin/win.c:1762 win_new() unknown log domain -1, 
original message level was: WRN

ERR<27896>:eo lib/eo/eo.c:2113 efl_data_scope_get() Eo ID 0x55ddef262c10 is not 
a valid object. Current thread: main. This ID has probably been deleted or this 
was never a valid object ID. (domain=2, current_do
main=0, local_domain=0, available_domains=[0 1], generation=10, id=98b, 
ref=1)
## Copy & Paste the below (until EOF) into a terminal, then hit Enter

eina_btlog << EOF
/usr/local/lib/libeina.so.1  0x7fb0e87f4462 0x7fb0e87c1000
...

ERR<28445>:eina_safety lib/evas/canvas/evas_callbacks.c:539 
evas_object_event_callback_del_full() safety check failed: obj == NULL
## Copy & Paste the below (until EOF) into a terminal, then hit Enter
...


Regards,
Jean Rene

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

Re: [E-devel] Community Scheduling

[Jonathan Aquilina]

Where can I begin?

Sent from my iPhone

> On 14 Jul 2018, at 10:25, Carsten Haitzler  wrote:
> 
> On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina 
> said:
> 
>> Hi Raster with what you said below and other threads I’ve seen with people
>> complaining about lack of unit tests etc wouldn’t it be better to get nightly
>> builds to those that like to be on bleeding edge and help us test and report
>> bugs. Not to mention I think nightly builds are possible as I see a lot of
>> things that get committed to the repos on a daily basis at times.
> 
> we already have that - jenkins and now travis builds every commit. there is no
> point building daily if you are building every commit already.
> 
> the issue isn't the builds, it's the tests themselves. having them cover
> everything in an efficient and sensible way. in fact lowering the barrier of
> entry to making a test... that's the work needed. :)
> 
>> My take like this is engaging the community and user base more.
>> 
>> Let me ask you this and it’s more to ponder on. How much of the current user
>> base is on the latest and greatest?
>> 
>> Sent from my iPhone
>> 
>>> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman)
>>>  wrote:
>>> 
>>> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina
>>>  said:
>>> 
 I think it was me not being clear I think what I’m thinking is nightly tar
 balls and if need be I’m willing to work on pre packaged binaries for
 nightly builds
>>> 
>>> TBH fixes don't move into a stable branch fast enough to justify nightlies.
>>> they go in over time maybe every few days or weeks then every now and again
>>> a point release goes out with them after a "does it compile and pass tests"
>>> check. these releases are incredibly easy and simple and can be automated,
>>> but no point having them nightly - just a "we have enough fixes now - push
>>> one out" time point.
>>> 
 Sent from my iPhone
 
> On 13 Jul 2018, at 18:46, Stefan Schmidt 
> wrote:
> 
> Hello.
> 
>> On 13.07.2018 11:27, Jonathan Aquilina wrote:
>> I was even thinking weekly point releases to get any new code or bug
>> fixes out for early testing.
> 
> Hmm, not sure I get you here. What I talk about are stable updates which
> would only contain fixes. No new code and definitely not used for
> testing at the users systems. These should only ship with verified fixes.
> 
> regards
> Stefan Schmidt
> 
> --
> 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
 
 
 --
 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" --
>>> Carsten Haitzler - ras...@rasterman.com
>>> 
>> 
> 
> 
> -- 
> - 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

Re: [E-devel] Community Scheduling

[Carsten Haitzler]

On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina 
said:

> Hi Raster with what you said below and other threads I’ve seen with people
> complaining about lack of unit tests etc wouldn’t it be better to get nightly
> builds to those that like to be on bleeding edge and help us test and report
> bugs. Not to mention I think nightly builds are possible as I see a lot of
> things that get committed to the repos on a daily basis at times.

we already have that - jenkins and now travis builds every commit. there is no
point building daily if you are building every commit already.

the issue isn't the builds, it's the tests themselves. having them cover
everything in an efficient and sensible way. in fact lowering the barrier of
entry to making a test... that's the work needed. :)

> My take like this is engaging the community and user base more.
> 
> Let me ask you this and it’s more to ponder on. How much of the current user
> base is on the latest and greatest?
> 
> Sent from my iPhone
> 
> > On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina
> >  said:
> > 
> >> I think it was me not being clear I think what I’m thinking is nightly tar
> >> balls and if need be I’m willing to work on pre packaged binaries for
> >> nightly builds
> > 
> > TBH fixes don't move into a stable branch fast enough to justify nightlies.
> > they go in over time maybe every few days or weeks then every now and again
> > a point release goes out with them after a "does it compile and pass tests"
> > check. these releases are incredibly easy and simple and can be automated,
> > but no point having them nightly - just a "we have enough fixes now - push
> > one out" time point.
> > 
> >> Sent from my iPhone
> >> 
> >>> On 13 Jul 2018, at 18:46, Stefan Schmidt 
> >>> wrote:
> >>> 
> >>> Hello.
> >>> 
>  On 13.07.2018 11:27, Jonathan Aquilina wrote:
>  I was even thinking weekly point releases to get any new code or bug
>  fixes out for early testing.
> >>> 
> >>> Hmm, not sure I get you here. What I talk about are stable updates which
> >>> would only contain fixes. No new code and definitely not used for
> >>> testing at the users systems. These should only ship with verified fixes.
> >>> 
> >>> regards
> >>> Stefan Schmidt
> >>> 
> >>> --
> >>> 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
> >> 
> >> 
> >> --
> >> 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" --
> > Carsten Haitzler - ras...@rasterman.com
> > 
> 


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

Re: [E-devel] Community Scheduling

[The Rasterman]

On Sat, 14 Jul 2018 10:12:29 +0300 Jonathan Aquilina 
said:

> I can get a vps from Linode and sponsor it myself I can work on setting up
> docker containers for build systems if need be.

that's total overkill. just chroots will do fine. it's not the need for vm's -
its the heed to create and maintain every chroot, to maintain and make all the
packaging files etc. and often for distros people aren't familiar with.

> Also what is interesting is with Linode you can setup and use a GUI through
> what they call glish
> 
> https://www.linode.com/docs/platform/using-the-linode-graphical-shell-glish/
> 
> These vms might make for good little testing environments if anyone is
> interested.
> 
> Honestly though the two types of packages one needs to build binaries for are
> deb and rpm right?
> 
> Another question do we have any snaps for Ubuntu?

no.

> Sent from my iPhone
> 
> > On 14 Jul 2018, at 09:03, Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > On Fri, 13 Jul 2018 14:35:10 -0400 Stefan Schmidt
> >  said:
> > 
> >> Hello.
> >> 
> >>> On 13.07.2018 13:09, Jonathan Aquilina wrote:
> >>> I think my take is more from the end user base. Isn’t it worth the time
> >>> and effort to have binaries available for those non developers?
> >> 
> >> Every night? I would say no. For releases? Maybe.
> > 
> > setting up the infra (chroots etc.) for every distro and multiple versions
> > is going to be a LOT of work... the packaging needs to be properly done with
> > proper split between dev/devel and core, etc. ... I think the best bang for
> > buck would be to focus on 1 or 2 distros and do it right (make a proper
> > distro image/install that has everything set up right).
> > 
> >> regards
> >> Stefan Schmidt
> >> 
> >> --
> >> 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" --
> > 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
> --
> 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" --
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

Re: [E-devel] Community Scheduling

[Jonathan Aquilina]

I can get a vps from Linode and sponsor it myself I can work on setting up 
docker containers for build systems if need be.

Also what is interesting is with Linode you can setup and use a GUI through 
what they call glish

https://www.linode.com/docs/platform/using-the-linode-graphical-shell-glish/

These vms might make for good little testing environments if anyone is 
interested.

Honestly though the two types of packages one needs to build binaries for are 
deb and rpm right?

Another question do we have any snaps for Ubuntu?

Sent from my iPhone

> On 14 Jul 2018, at 09:03, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Fri, 13 Jul 2018 14:35:10 -0400 Stefan Schmidt 
> said:
> 
>> Hello.
>> 
>>> On 13.07.2018 13:09, Jonathan Aquilina wrote:
>>> I think my take is more from the end user base. Isn’t it worth the time and
>>> effort to have binaries available for those non developers?
>> 
>> Every night? I would say no. For releases? Maybe.
> 
> setting up the infra (chroots etc.) for every distro and multiple versions is
> going to be a LOT of work... the packaging needs to be properly done with
> proper split between dev/devel and core, etc. ... I think the best bang for
> buck would be to focus on 1 or 2 distros and do it right (make a proper distro
> image/install that has everything set up right).
> 
>> regards
>> Stefan Schmidt
>> 
>> --
>> 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" --
> 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
--
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

Re: [E-devel] End of Week: Phab Report

[Jonathan Aquilina]

Not to hijack this email but mike is this something which can be automated and 
sent out weekly basis without any need for human intervention and just use an 
email template that looks at the Phab tags for information?

Sent from my iPhone

> On 13 Jul 2018, at 21:18, Mike Blumenkrantz  
> wrote:
> 
> Hi,
> 
> I forgot to send this last week and people were feeling demotivated, so
> it's back again.
> 
> TICKETS:
> *https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/
> *
> * 10 regular tasks open with the 1.21 milestone
> Some work has already been done on these, and the number has once again
> been cut in half since the last report.
> * 4 regression tickets open which must be resolved before the final 1.21
> release
> All of these already have patches in review, no further work beyond
> review/testing is required.
> * This search query is now available in the sidebar of the maniphest view
> for easier access.
> 
> PATCHES
> *https://phab.enlightenment.org/differential/query/38N2dAUrUZ7J/
> *
> * 13 patches awaiting review
> * This search query is now available in the sidebar of the differential
> view for easier access.
> 
> If you aren't submitting your patches for review yet, please consider doing
> so using the documentation here: https://phab.enlightenment.org/w/arcanist/
> 
> Build status is green at present, tests are all passing as well. Next week
> is a big Samsung internal event, so some slowdown may occur.
> 
> Regards,
> Mike
> --
> 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


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

Re: [E-devel] Community Scheduling

[Jonathan Aquilina]

Hi Raster with what you said below and other threads I’ve seen with people 
complaining about lack of unit tests etc wouldn’t it be better to get nightly 
builds to those that like to be on bleeding edge and help us test and report 
bugs. Not to mention I think nightly builds are possible as I see a lot of 
things that get committed to the repos on a daily basis at times.

My take like this is engaging the community and user base more.

Let me ask you this and it’s more to ponder on. How much of the current user 
base is on the latest and greatest?

Sent from my iPhone

> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina 
> said:
> 
>> I think it was me not being clear I think what I’m thinking is nightly tar
>> balls and if need be I’m willing to work on pre packaged binaries for nightly
>> builds
> 
> TBH fixes don't move into a stable branch fast enough to justify nightlies.
> they go in over time maybe every few days or weeks then every now and again a
> point release goes out with them after a "does it compile and pass tests"
> check. these releases are incredibly easy and simple and can be automated, but
> no point having them nightly - just a "we have enough fixes now - push one 
> out"
> time point.
> 
>> Sent from my iPhone
>> 
>>> On 13 Jul 2018, at 18:46, Stefan Schmidt  wrote:
>>> 
>>> Hello.
>>> 
 On 13.07.2018 11:27, Jonathan Aquilina wrote:
 I was even thinking weekly point releases to get any new code or bug fixes
 out for early testing.
>>> 
>>> Hmm, not sure I get you here. What I talk about are stable updates which
>>> would only contain fixes. No new code and definitely not used for
>>> testing at the users systems. These should only ship with verified fixes.
>>> 
>>> regards
>>> Stefan Schmidt
>>> 
>>> --
>>> 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
>> 
>> 
>> --
>> 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" --
> 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

Re: [E-devel] Community Scheduling

[The Rasterman]

On Fri, 13 Jul 2018 10:36:53 -0400 Stefan Schmidt 
said:

> Hello.
> 
> On 12.07.2018 13:12, Mike Blumenkrantz wrote:
> > Now that we're interacting more as a community, I think there is the
> > general expectation that if you're a core developer then you should try to
> > notify the project if you'll be gone for an extended period of time.
> > 
> > I agree that there is a "deal with it" aspect to a community project, but I
> > think that if a core developer will be gone for longer than maybe a week,
> > then there should be some responsibility to at least alert everyone of that
> > unavailability. I don't think that's an unreasonable thing to ask?
> > 
> > To be clear, while this mail was not directed at you, certainly your
> > absence was a factor in my sending it--I didn't even know that you would be
> > gone until 1-2 weeks after you'd left. While I am not in any way blaming
> > you for taking a vacation, it would have been nice to be able to check the
> > calendar on the first week that you were out and seen that you were gone.
> 
> I honestly do not see how having a special calendar for this would
> really change anything for the community here. I started months before I
> my long absence to mention it in mails about the 1.21 schedule and also
> directly to people.
> 
> If there is a really big momentum where all the devs here would but
> their unavailability into the calendar I can try to do that as well, but
> I foresee that I will forget to update it on a regular basis.
> 
> > I can appreciate your concerns with community involvement in the release
> > process, but I don't think that "stepping down" from the position of
> > release manager will solve anything. Releases in EFL have historically been
> > handicapped by many issues, but most notably--as you mentioned--by lack of
> > community collaboration. This is not specific to releases however; it's
> > only recently that we've begun to come together and make a concerted effort
> > to act and behave as a real community instead of simply bickering endlessly
> > about every trivial item.
> 
> I have a different opinion on if we only recently started to try to
> behave like a community, but that is off topic for this thread.

Indeed. I am with you on that.

> The time you, Marcel and others have been spending on improving the bug
> tracking tagging, projects, etc is definitively helping to get the load
> of release handling (as long as this is kept up for the future as well)
> 
> > Going forward, I would really appreciate it if you could give managing
> > releases one more try for the 1.22 cycle,
> 
> Sorry, but I already got weak and handle 1.21 now (not doing the best
> job either) and I swore myself to not handle 1.22.
> 
> There is no bad blood from my side on this. I simply think that I should
> stop doing it and someone else (or a group) needs to form to bring new
> energy into the way we handle releases.
> 
>  and send some mails to the list
> > (or create tickets) regarding things that the community can do to help with
> > releases. Everyone knows in some sense that you need help, but I think
> > maybe we're all a bit unsure what we can do to contribute.
> 
> Asking me how to help was to complicated? :-)
> 
> > It would also be great if we could also do a bit more automation with
> > releases, to reduce the active work burden on whoever is executing the
> > release. I'm certainly willing to pitch in and help see if we can further
> > streamline the release process, as well as discussing any changes which
> > could simplify the process and avoid future cases where the release gets
> > blocked for a long period of time.
> 
> That could help. Also splitting the role of into different tasks. Not
> all of them have to be done by one person. There could be a bug
> wrangler, a person how runs abi-checker and analysis the report, a
> person how handles release notes, etc. Lost of jobs not needed to be
> done by one person alone.
> 
> > Regardless of whether you follow through with your plan to step down from
> > managing releases, I just want to say thanks for all the time and effort
> > you've put into managing releases over the years. I know it wasn't easy,
> > but you kept everyone (mostly) on schedule for many years, and I can't
> > think of anyone who could have done it better.
> 
> Appreciated.
> 
> regards
> Stefan Schmidt
> 
> --
> 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" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the 

Re: [E-devel] Community Scheduling

[The Rasterman]

On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina 
said:

> I think it was me not being clear I think what I’m thinking is nightly tar
> balls and if need be I’m willing to work on pre packaged binaries for nightly
> builds

TBH fixes don't move into a stable branch fast enough to justify nightlies.
they go in over time maybe every few days or weeks then every now and again a
point release goes out with them after a "does it compile and pass tests"
check. these releases are incredibly easy and simple and can be automated, but
no point having them nightly - just a "we have enough fixes now - push one out"
time point.

> Sent from my iPhone
> 
> > On 13 Jul 2018, at 18:46, Stefan Schmidt  wrote:
> > 
> > Hello.
> > 
> >> On 13.07.2018 11:27, Jonathan Aquilina wrote:
> >> I was even thinking weekly point releases to get any new code or bug fixes
> >> out for early testing.
> > 
> > Hmm, not sure I get you here. What I talk about are stable updates which
> > would only contain fixes. No new code and definitely not used for
> > testing at the users systems. These should only ship with verified fixes.
> > 
> > regards
> > Stefan Schmidt
> > 
> > --
> > 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
> 
> 
> --
> 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" --
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

Re: [E-devel] Community Scheduling

[The Rasterman]

On Fri, 13 Jul 2018 09:46:14 -0400 Stefan Schmidt 
said:

> Hello.
> 
> On 13.07.2018 03:20, Jonathan Aquilina wrote:
> > Some food for thought wouldn’t it be better to do more frequent point
> > releases?
> 
> If you look at the releases before 1.20 you will see that we did quite a
> few. I aimed for a one stable update per months schedule. Sometimes
> being faster or slower depending on how critical the backports have been.
> 
> With 1.20 and now 1.21 the schedules are all messed up. I would agree
> that coming back to more frequent stable updates make sense.

doing less in a release will help. Less in terms of amount of new/changed code
going in per release, and even streamlining the process. TBH the right thing
would be for it to be scripts that are in the efl repo itself like:

./rel/alpha.sh
./rel/beta.sh
./rel/final.sh

and alpha.beta take a parameter (2, 3, 4, 5) if multiple are needed. scripts
do a make distcheck and makes sure things pass. It generates all needed files
(changelog etc.), appropriately update README and any other files so correct
versions are there, upload tarball, add a news article to the www content git
repo, spew out the content of a mail to copy & paste into a mail client(that
could be automated too ...) etc. ...

Not everything can be automated - like manual addition of docs like new
configure options or deprecated ones, new dependencies etc. ... these should
have been fixed already at the time they were changed, but double-checking here
is manual. Perhaps the scripts can echo out a list of files to review the
content of?

But in the end there should be a simple "press this button" to release. The
rest is simply QA - nuking bugs, testing, etc. which can't be really automated.

> regards
> Stefan Schmidt
> 
> --
> 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" --
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

Re: [E-devel] Community Scheduling

[The Rasterman]

On Fri, 13 Jul 2018 14:35:10 -0400 Stefan Schmidt 
said:

> Hello.
> 
> On 13.07.2018 13:09, Jonathan Aquilina wrote:
> > I think my take is more from the end user base. Isn’t it worth the time and
> > effort to have binaries available for those non developers?
> 
> Every night? I would say no. For releases? Maybe.

setting up the infra (chroots etc.) for every distro and multiple versions is
going to be a LOT of work... the packaging needs to be properly done with
proper split between dev/devel and core, etc. ... I think the best bang for
buck would be to focus on 1 or 2 distros and do it right (make a proper distro
image/install that has everything set up right).

> regards
> Stefan Schmidt
> 
> --
> 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" --
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

Re: [E-devel] Community Scheduling

[The Rasterman]

On Fri, 13 Jul 2018 18:30:13 +0300 Jonathan Aquilina 
said:

> Could we enhance the scripts to make things easier to do this?
> 
> If that is a yes then I’m more than willing to work on enhancing the scripts

Yes - we could. Though it would be a combination of workflow + scripts. You
want the information to already exist in a form that a script can find/digest.
i.e. in the git commit log. Then a Script can hint and extract it and format
things appropriately. To some extent the info exists like @fix tags in a commit
log identifying that commit as a fix to a problem that existed in prior efl
releases. @feat / @feature for new features and @opt for optimizations too...

The problem is making a 1 line summary that makes sense to people out of all of
that. Does the shortlog do that? It should... but sometimes it just is too
short to do it. Having an "expanded" sub-header section might be needed like:


evas - shortlog goes here

+extra information on lines beginning with a plus signe
+like this

rest of the extended body here


At least I've often found it impossible to give a decent description just in a
shortlog and had to expand in the first few lines of the log body.

> Sent from my iPhone
> 
> > On 13 Jul 2018, at 16:36, Mike Blumenkrantz
> >  wrote:
> > 
> > Yes, I think bugfix releases should be done much more frequently. The issue
> > here is that doing releases in EFL is still very cumbersome; we need to
> > greatly reduce the amount of active work that it takes to execute and ship
> > a release.
> > 
> > On Fri, Jul 13, 2018 at 3:21 AM Jonathan Aquilina 
> > wrote:
> > 
> >> Some food for thought wouldn’t it be better to do more frequent point
> >> releases?
> >> 
> >> Sent from my iPhone
> >> 
> >>> On 12 Jul 2018, at 20:12, Mike Blumenkrantz <
> >> michael.blumenkra...@gmail.com> wrote:
> >>> 
> >>> Now that we're interacting more as a community, I think there is the
> >>> general expectation that if you're a core developer then you should try
> >> to
> >>> notify the project if you'll be gone for an extended period of time.
> >>> 
> >>> I agree that there is a "deal with it" aspect to a community project,
> >> but I
> >>> think that if a core developer will be gone for longer than maybe a week,
> >>> then there should be some responsibility to at least alert everyone of
> >> that
> >>> unavailability. I don't think that's an unreasonable thing to ask?
> >>> 
> >>> To be clear, while this mail was not directed at you, certainly your
> >>> absence was a factor in my sending it--I didn't even know that you would
> >> be
> >>> gone until 1-2 weeks after you'd left. While I am not in any way blaming
> >>> you for taking a vacation, it would have been nice to be able to check
> >> the
> >>> calendar on the first week that you were out and seen that you were gone.
> >>> 
> >>> I would disagree with your assessment that you are the single point of
> >>> failure in releases. The 1.21 release has had a lot of issues, more than
> >>> any release since the 1.8 cycle in 2013. When a release fails to happen
> >> on
> >>> schedule as a result of community/project issues, I don't think the
> >> release
> >>> manager can be blamed in any way.
> >>> 
> >>> I can appreciate your concerns with community involvement in the release
> >>> process, but I don't think that "stepping down" from the position of
> >>> release manager will solve anything. Releases in EFL have historically
> >> been
> >>> handicapped by many issues, but most notably--as you mentioned--by lack
> >> of
> >>> community collaboration. This is not specific to releases however; it's
> >>> only recently that we've begun to come together and make a concerted
> >> effort
> >>> to act and behave as a real community instead of simply bickering
> >> endlessly
> >>> about every trivial item.
> >>> 
> >>> Going forward, I would really appreciate it if you could give managing
> >>> releases one more try for the 1.22 cycle, and send some mails to the list
> >>> (or create tickets) regarding things that the community can do to help
> >> with
> >>> releases. Everyone knows in some sense that you need help, but I think
> >>> maybe we're all a bit unsure what we can do to contribute.
> >>> It would also be great if we could also do a bit more automation with
> >>> releases, to reduce the active work burden on whoever is executing the
> >>> release. I'm certainly willing to pitch in and help see if we can further
> >>> streamline the release process, as well as discussing any changes which
> >>> could simplify the process and avoid future cases where the release gets
> >>> blocked for a long period of time.
> >>> 
> >>> Regardless of whether you follow through with your plan to step down from
> >>> managing releases, I just want to say thanks for all the time and effort
> >>> you've put into managing releases over the years. I know it wasn't easy,
> >>> but you kept everyone (mostly) on schedule for many years, and I can't
> >>> think of anyone who could