Re: [E-devel] Community Scheduling
On Sun, 15 Jul 2018 12:35:13 +0900 Carsten Haitzler said: > 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. also an interesting article that nicely describes some of the reasons why i favour integration tests first, and why i suggest it as a priority: https://blog.usejournal.com/lean-testing-or-why-unit-tests-are-worse-than-you-think-b6500139a009 > > 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 > >
Re: [E-devel] Community Scheduling
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
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
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] Community Scheduling
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] Community Scheduling
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
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
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
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] Community Scheduling
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
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
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
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
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
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
Re: [E-devel] Community Scheduling
On Fri, 13 Jul 2018 20:14:31 +0300 Jonathan Aquilina wrote: > Can Travis build rpm and deb binaries? Of course, but I find it easier to do such via CMake's cpack. With autotools and meson. You must make your own spec file for rpm, and similar for deb. Plus targets for such. Why IMHO I prefer CMake + CPack. It makes releases much better!!! Example deb and rpm of ecrire anytime I do a tag via Travis. https://github.com/Obsidian-StudiosInc/ecrire/releases https://github.com/Obsidian-StudiosInc/jem/releases https://github.com/Obsidian-StudiosInc/asspr/releases Trying to help with the same for libcheck/check. https://github.com/libcheck/check/issues/154 https://github.com/libcheck/check/pull/163 No deb or rpm for entrance or clipboard as I am using meson vs cmake for now. Rather than integrate rpm/deb into meson. Likely just go with cmake. Jumped on the meson bandwagon as part of the fad. https://github.com/Obsidian-StudiosInc/entrance/releases https://github.com/Obsidian-StudiosInc/clipboard/releases IMHO major omission of Meson, and something I feel they should revisit and have, but not sure they will. Seems to be some reason why its not done now. http://mesonbuild.com/RPM-module.html#rpm-module Nada for deb... At least I haven't found anything, and deb under their search returns no results. Only 1 reference to deb. http://mesonbuild.com/Installing.html#destdir-support -- William L. Thomson Jr. pgpe_6L9WCmUv.pgp Description: OpenPGP digital signature -- 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
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. 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
Can Travis build rpm and deb binaries? Sent from my iPhone > On 13 Jul 2018, at 19:41, Mike Blumenkrantz > wrote: > > I think it should be possible to just upload a travis build somewhere > periodically if we want to do this? > > On Fri, Jul 13, 2018 at 11:56 AM Stefan Schmidt > wrote: > >> Hello. >> >>> On 13.07.2018 11:51, Jonathan Aquilina wrote: >>> 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 >> >> OK, very different from what I understood under a point release. Nightly >> builds make it clear. >> >> I really see no need for this. People that update often will use git >> imho and not use nighlies for this. I am pretty much biased here as I am >> a developer using git anyway and not a user, though. >> >> 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 -- 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
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? Sent from my iPhone > On 13 Jul 2018, at 18:55, Stefan Schmidt wrote: > > Hello. > >> On 13.07.2018 11:51, Jonathan Aquilina wrote: >> 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 > > OK, very different from what I understood under a point release. Nightly > builds make it clear. > > I really see no need for this. People that update often will use git > imho and not use nighlies for this. I am pretty much biased here as I am > a developer using git anyway and not a user, though. > > 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
Re: [E-devel] Community Scheduling
I think it should be possible to just upload a travis build somewhere periodically if we want to do this? On Fri, Jul 13, 2018 at 11:56 AM Stefan Schmidt wrote: > Hello. > > On 13.07.2018 11:51, Jonathan Aquilina wrote: > > 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 > > OK, very different from what I understood under a point release. Nightly > builds make it clear. > > I really see no need for this. People that update often will use git > imho and not use nighlies for this. I am pretty much biased here as I am > a developer using git anyway and not a user, though. > > 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
Re: [E-devel] Community Scheduling
I think your reply is exactly why we should use the calendar; you say you were sending mails about it and telling people for months before, and yet I was still unaware. Or maybe I forgot. Either way, if there had been a calendar entry then I would have known immediately. Are you really taking that many week+ vacations that you would need to be constantly updating a calendar like this? Maybe I should be talking to my employer about doubling or tripling my PTO... I understand fully your decision to not manage 1.22, and I support you in this. We'll do our best to figure it out! On Fri, Jul 13, 2018 at 10:37 AM Stefan Schmidt wrote: > 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. > > 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 > > >
Re: [E-devel] Community Scheduling
Just use git if you are interested in getting updates that fast. On Fri, Jul 13, 2018, 10:56 AM Stefan Schmidt wrote: > Hello. > > On 13.07.2018 11:51, Jonathan Aquilina wrote: > > 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 > > OK, very different from what I understood under a point release. Nightly > builds make it clear. > > I really see no need for this. People that update often will use git > imho and not use nighlies for this. I am pretty much biased here as I am > a developer using git anyway and not a user, though. > > 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
Re: [E-devel] Community Scheduling
Hello. On 13.07.2018 11:51, Jonathan Aquilina wrote: > 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 OK, very different from what I understood under a point release. Nightly builds make it clear. I really see no need for this. People that update often will use git imho and not use nighlies for this. I am pretty much biased here as I am a developer using git anyway and not a user, though. 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
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 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
Re: [E-devel] Community Scheduling
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
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 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 have done it better. >>> >>> On Thu, Jul 12, 2018 at 10:33 AM Stefan Schmidt < >> ste...@datenfreihafen.org> >>> wrote: >>> Hello. > On 10.07.2018 07:42, Mike Blumenkrantz wrote: > Hello, > > It seems that we have some issues lately regarding scheduling, specifically > personal schedules. We (as a project) have expectations of developer > availability, and when these expectations are changed or not met then > things can get a bit messy. Do we (as a project) really have this expectations? For me a community project has to deal with the coming and going of developer resources. I tried many times to get a 1.21 release schedule set that would have avoided my unavailability in June. All of these attempts failed and we ended in this situation. > Fortunately, we have tools to avoid issues with this. > > https://phab.enlightenment.org/calendar/ > > If anyone is planning to be unavailable for a length of time which >> could > impact the project (e.g., going on vacation/holiday for a week, going >> on a > business trip for several days when a release is pending, ...), please >
Re: [E-devel] Community Scheduling
I was even thinking weekly point releases to get any new code or bug fixes out for early testing. Sent from my iPhone > On 13 Jul 2018, at 16:46, Stefan Schmidt wrote: > > 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. > > 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
Re: [E-devel] Community Scheduling
Count me in to start a team for this Sent from my iPhone > On 13 Jul 2018, at 17:02, Stefan Schmidt wrote: > > Hello. > >> On 13.07.2018 03:10, Jonathan Aquilina wrote: >> Hi Stefan, >> >> What know how does one need for this role? > > Well, there are many different parts to it. > > The mechanical part of doing the tarballs is not that hard (parts are > even scripted). > > The other part is to keep an eye on the bug reports, monitoring critical > ones, pitching in with comments, testing etc. > > Running things like abi-checker and reviewing the reports to see how we > do regarding API breaks. > > The more complicated part is that you would need to understand enough of > the code base to follow up with the latest issues that block a release. > It does not mean you have to fix them yourself but you would need to > understand the severity and impact the issue would have. > > In general I would recommend to have developer with longer efl > experience to handle the release. There are tasks that can be split of > and helped with by all kind of folks though. If one takes the releases > notes as an example. This have been taking a lot of my extra time on the > release. If someone would got around look through the git log, pick > bigger features, ask the authors to write up a short piece on it and > massages it all into release notes this could be split of to people > without a core developer background easily. > > 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
Re: [E-devel] Community Scheduling
Hello. On 13.07.2018 10:23, Mike Blumenkrantz wrote: > Sure, I think the obvious area for automation would be in the release > notes. Moving this to use the Enlightenment release method seems like it > would save a huge amount of time here (ie. just running a script for ticket > refs and using git shortlog). If we start using the right project tags for > 'feature' patches then these can easily be found for release highlight > items, meaning that this part of doing a release is effectively removed > from the 'active' time requirement. Besides a list generated phab or git log (which I think is fine for point releases) for major ones we should release notes which explain concepts and changes on a higher level with context added the basic commits to not offer. This is why I often poked folks to give me a short blurb of text on a feature they worked on during a given release. 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
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. 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
Re: [E-devel] Community Scheduling
Sure, I think the obvious area for automation would be in the release notes. Moving this to use the Enlightenment release method seems like it would save a huge amount of time here (ie. just running a script for ticket refs and using git shortlog). If we start using the right project tags for 'feature' patches then these can easily be found for release highlight items, meaning that this part of doing a release is effectively removed from the 'active' time requirement. Backporting is a bit trickier, and I think we should probably have some more focused discussion on it at some point. On Fri, Jul 13, 2018 at 10:05 AM Stefan Schmidt wrote: > Hello. > > On 13.07.2018 09: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. > > Feel free to automate more if you want. I stopped at the scripts we have > right now because it automated enough for me and the rest of time is > mostly spent on herding cats to get people backport, bug reporter verify > that its resolved, etc. > > I am definitely not standing in the way for more automation on this. > > 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
Re: [E-devel] Community Scheduling
Hello. On 13.07.2018 09: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. Feel free to automate more if you want. I stopped at the scripts we have right now because it automated enough for me and the rest of time is mostly spent on herding cats to get people backport, bug reporter verify that its resolved, etc. I am definitely not standing in the way for more automation on this. 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
Hello. On 13.07.2018 03:10, Jonathan Aquilina wrote: > Hi Stefan, > > What know how does one need for this role? Well, there are many different parts to it. The mechanical part of doing the tarballs is not that hard (parts are even scripted). The other part is to keep an eye on the bug reports, monitoring critical ones, pitching in with comments, testing etc. Running things like abi-checker and reviewing the reports to see how we do regarding API breaks. The more complicated part is that you would need to understand enough of the code base to follow up with the latest issues that block a release. It does not mean you have to fix them yourself but you would need to understand the severity and impact the issue would have. In general I would recommend to have developer with longer efl experience to handle the release. There are tasks that can be split of and helped with by all kind of folks though. If one takes the releases notes as an example. This have been taking a lot of my extra time on the release. If someone would got around look through the git log, pick bigger features, ask the authors to write up a short piece on it and massages it all into release notes this could be split of to people without a core developer background easily. 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
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. 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
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 have done it better. > > > > On Thu, Jul 12, 2018 at 10:33 AM Stefan Schmidt < > ste...@datenfreihafen.org> > > wrote: > > > >> Hello. > >> > >>> On 10.07.2018 07:42, Mike Blumenkrantz wrote: > >>> Hello, > >>> > >>> It seems that we have some issues lately regarding scheduling, > >> specifically > >>> personal schedules. We (as a project) have expectations of developer > >>> availability, and when these expectations are changed or not met then > >>> things can get a bit messy. > >> > >> Do we (as a project) really have this expectations? For me a community > >> project has to deal with the coming and going of developer resources. > >> > >> I tried many times to get a 1.21 release schedule set that would have > >> avoided my unavailability in June. All of these attempts failed and we > >> ended in this situation. > >> > >>> Fortunately, we have tools to avoid issues with this. > >>> > >>> https://phab.enlightenment.org/calendar/ > >>> > >>> If anyone is planning to be unavailable for a length of time which > could > >>> impact the project (e.g., going on vacation/holiday for a week, going > on > >> a > >>> business trip for several days when a release is pending, ...), please > >>> create an event on the calendar for it. The visibility for events can > be > >>> set to "committers" if anyone is concerned about privacy, and I would > not > >>> recommend providing excessive detail in the event description; a simple > >>> "unavailable" is enough. > >> > >> I
Re: [E-devel] Community Scheduling
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 > 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 have done it better. > > On Thu, Jul 12, 2018 at 10:33 AM Stefan Schmidt > wrote: > >> Hello. >> >>> On 10.07.2018 07:42, Mike Blumenkrantz wrote: >>> Hello, >>> >>> It seems that we have some issues lately regarding scheduling, >> specifically >>> personal schedules. We (as a project) have expectations of developer >>> availability, and when these expectations are changed or not met then >>> things can get a bit messy. >> >> Do we (as a project) really have this expectations? For me a community >> project has to deal with the coming and going of developer resources. >> >> I tried many times to get a 1.21 release schedule set that would have >> avoided my unavailability in June. All of these attempts failed and we >> ended in this situation. >> >>> Fortunately, we have tools to avoid issues with this. >>> >>> https://phab.enlightenment.org/calendar/ >>> >>> If anyone is planning to be unavailable for a length of time which could >>> impact the project (e.g., going on vacation/holiday for a week, going on >> a >>> business trip for several days when a release is pending, ...), please >>> create an event on the calendar for it. The visibility for events can be >>> set to "committers" if anyone is concerned about privacy, and I would not >>> recommend providing excessive detail in the event description; a simple >>> "unavailable" is enough. >> >> I already have a private and a business calendar I need to keep updated. >> I am not keen to have another one I need to update. My work scope >> changed, my travels have increased and my private time I put into this >> project has also reduced due to personal changes. Even if I would say >> yes here to update such a schedule this with lag behind in just a few >> weeks time from now due to me not updating it. >> >> On the bright side though I should no longer be the single point failure >> for release stuff after 1.21 is out as I will step down
Re: [E-devel] Community Scheduling
Hi Stefan, What know how does one need for this role? Sent from my iPhone > On 12 Jul 2018, at 17:32, Stefan Schmidt wrote: > > Hello. > >> On 10.07.2018 07:42, Mike Blumenkrantz wrote: >> Hello, >> >> It seems that we have some issues lately regarding scheduling, specifically >> personal schedules. We (as a project) have expectations of developer >> availability, and when these expectations are changed or not met then >> things can get a bit messy. > > Do we (as a project) really have this expectations? For me a community > project has to deal with the coming and going of developer resources. > > I tried many times to get a 1.21 release schedule set that would have > avoided my unavailability in June. All of these attempts failed and we > ended in this situation. > >> Fortunately, we have tools to avoid issues with this. >> >> https://phab.enlightenment.org/calendar/ >> >> If anyone is planning to be unavailable for a length of time which could >> impact the project (e.g., going on vacation/holiday for a week, going on a >> business trip for several days when a release is pending, ...), please >> create an event on the calendar for it. The visibility for events can be >> set to "committers" if anyone is concerned about privacy, and I would not >> recommend providing excessive detail in the event description; a simple >> "unavailable" is enough. > > I already have a private and a business calendar I need to keep updated. > I am not keen to have another one I need to update. My work scope > changed, my travels have increased and my private time I put into this > project has also reduced due to personal changes. Even if I would say > yes here to update such a schedule this with lag behind in just a few > weeks time from now due to me not updating it. > > On the bright side though I should no longer be the single point failure > for release stuff after 1.21 is out as I will step down from the release > manager role. I tried to form a release team for many years so far but > failed in getting anyone interested. By stepping down I kind of forcing > this change, hopefully for the better. > > 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
Re: [E-devel] Community Scheduling
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 have done it better. On Thu, Jul 12, 2018 at 10:33 AM Stefan Schmidt wrote: > Hello. > > On 10.07.2018 07:42, Mike Blumenkrantz wrote: > > Hello, > > > > It seems that we have some issues lately regarding scheduling, > specifically > > personal schedules. We (as a project) have expectations of developer > > availability, and when these expectations are changed or not met then > > things can get a bit messy. > > Do we (as a project) really have this expectations? For me a community > project has to deal with the coming and going of developer resources. > > I tried many times to get a 1.21 release schedule set that would have > avoided my unavailability in June. All of these attempts failed and we > ended in this situation. > > > Fortunately, we have tools to avoid issues with this. > > > > https://phab.enlightenment.org/calendar/ > > > > If anyone is planning to be unavailable for a length of time which could > > impact the project (e.g., going on vacation/holiday for a week, going on > a > > business trip for several days when a release is pending, ...), please > > create an event on the calendar for it. The visibility for events can be > > set to "committers" if anyone is concerned about privacy, and I would not > > recommend providing excessive detail in the event description; a simple > > "unavailable" is enough. > > I already have a private and a business calendar I need to keep updated. > I am not keen to have another one I need to update. My work scope > changed, my travels have increased and my private time I put into this > project has also reduced due to personal changes. Even if I would say > yes here to update such a schedule this with lag behind in just a few > weeks time from now due to me not updating it. > > On the bright side though I should no longer be the single point failure > for release stuff after 1.21 is out as I will step down from the release > manager role. I tried to form a release team for many years so far but > failed in getting anyone interested. By stepping down I kind of forcing > this change, hopefully for the better. > > regards > Stefan Schmidt > > >
Re: [E-devel] Community Scheduling
Hello. On 10.07.2018 07:42, Mike Blumenkrantz wrote: > Hello, > > It seems that we have some issues lately regarding scheduling, specifically > personal schedules. We (as a project) have expectations of developer > availability, and when these expectations are changed or not met then > things can get a bit messy. Do we (as a project) really have this expectations? For me a community project has to deal with the coming and going of developer resources. I tried many times to get a 1.21 release schedule set that would have avoided my unavailability in June. All of these attempts failed and we ended in this situation. > Fortunately, we have tools to avoid issues with this. > > https://phab.enlightenment.org/calendar/ > > If anyone is planning to be unavailable for a length of time which could > impact the project (e.g., going on vacation/holiday for a week, going on a > business trip for several days when a release is pending, ...), please > create an event on the calendar for it. The visibility for events can be > set to "committers" if anyone is concerned about privacy, and I would not > recommend providing excessive detail in the event description; a simple > "unavailable" is enough. I already have a private and a business calendar I need to keep updated. I am not keen to have another one I need to update. My work scope changed, my travels have increased and my private time I put into this project has also reduced due to personal changes. Even if I would say yes here to update such a schedule this with lag behind in just a few weeks time from now due to me not updating it. On the bright side though I should no longer be the single point failure for release stuff after 1.21 is out as I will step down from the release manager role. I tried to form a release team for many years so far but failed in getting anyone interested. By stepping down I kind of forcing this change, hopefully for the better. 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
[E-devel] Community Scheduling
Hello, It seems that we have some issues lately regarding scheduling, specifically personal schedules. We (as a project) have expectations of developer availability, and when these expectations are changed or not met then things can get a bit messy. Fortunately, we have tools to avoid issues with this. https://phab.enlightenment.org/calendar/ If anyone is planning to be unavailable for a length of time which could impact the project (e.g., going on vacation/holiday for a week, going on a business trip for several days when a release is pending, ...), please create an event on the calendar for it. The visibility for events can be set to "committers" if anyone is concerned about privacy, and I would not recommend providing excessive detail in the event description; a simple "unavailable" is enough. 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
