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 nightl

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

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

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

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 infor

[E-devel] IRC+Phab Integration

Hi, I think it would be great if we could have some integration with phabricator on IRC, specifically things like: * resolving e.g., D1234 or T1234 to URLS with descriptions * optionally outputting some info when tickets/patches are opened/closed? The first item would be super convenient. I thi

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 CMa

Re: [E-devel] efl regressor

On Fri, 13 Jul 2018 09:41:06 -0400 Stefan Schmidt wrote: > Hello. > > On 09.07.2018 12:00, William L. Thomson Jr. wrote: > > > I feel like a docker image with a ready env for testing E > > applications would be beneficial not only to myself, but to others. > > Seems using Docker images is much f

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

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

Other phab items of interest: * https://phab.enlightenment.org/w/maintainers_reviewers/ is a table that can be used when trying to find people to review various parts of the codebase. A new herald rule will notify patches submitted without a reviewer in order to ensure that new contributors are abl

[E-devel] End of Week: Phab Report

Hi, I forgot to send this last week and people were feeling demotivated, so it's back again. TICKETS: *https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/ * * 10 regular tasks open with the 1.21 milestone Some work has already

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

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

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 >

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

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 wo

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 bui

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:

Re: [E-devel] Coverity on Terminology

Hello. On 13.07.2018 10:57, Boris Faure wrote: > On 18-07-13 10:42, Stefan Schmidt wrote: >> Hello. >> >> On 23.05.2018 12:24, Boris Faure wrote: >>> I was looking at coverity on Terminology and it is currently not >>> analyzing any build since 2018-04-15. The latest reason being: >>> The bu

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 te

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 issu

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 frequ

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 mec

Re: [E-devel] Coverity on Terminology

On 18-07-13 10:42, Stefan Schmidt wrote: > Hello. > > On 23.05.2018 12:24, Boris Faure wrote: > > I was looking at coverity on Terminology and it is currently not > > analyzing any build since 2018-04-15. The latest reason being: > > > >> The build uploaded has been only partially compiled. We r

Re: [E-devel] Coverity on Terminology

Hello. On 23.05.2018 12:24, Boris Faure wrote: > I was looking at coverity on Terminology and it is currently not > analyzing any build since 2018-04-15. The latest reason being: > >> The build uploaded has been only partially compiled. We recommend at >> least 85% capture success to avoid false

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

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

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

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

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

Re: [E-devel] New Phab Project

As a followup, any patch that this project is added to will also (using herald) remove the committers group, so this can be useful for any patch which is undergoing heavy changes if the author doesn't want to have it reviewed globally yet. On Tue, Jul 10, 2018 at 9:42 AM Mike Blumenkrantz < michae

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 sl

Re: [E-devel] efl regressor

Hello. On 09.07.2018 12:00, William L. Thomson Jr. wrote: > On Mon, 9 Jul 2018 16:56:30 +0200 > Marcel Hollerbach wrote: > >> Hallo, >> >> I tryed to investigate a regression between efl-1.19 and the current >> state in master. For that i have been putting together a docker image >> with prein

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

Re: [E-devel] EFL 1.21.0 alpha1 released

Hello. On 10.07.2018 10:43, Derek Foreman wrote: > I've created a phab ticket for this at T7120 and am testing a fix for it > now. This has landed and will be used for the next tarballs I generate which should get this fixed. Thanks for the reports. regards Stefan Schmidt --

Re: [E-devel] git-phab update

Ideally submitting patches should also (with --option) attempt to push to a /dev/ branch. The code I used to validate/verify adding and updating of projects/reviewers/subscribers is pretty hacky and could be cleaned up. Push to staging repo should be disabled using a --option or arcconfig variabl

Re: [E-devel] Managing the next release

Please dont stick unstable, untested, or unsure code in master and ifdef it. This is specifically what branches are for. They allow all of that without clouding up master with a bunch of junk. I would argue that for most of the people that you will want to test your new unstable code we would pre

Re: [E-devel] Managing the next release

Branch development is how sane collaborative software engineering is done when using git. Previously we, as a project, have not made effective use of them, but we must end the practice of merging features into master "for testing". Testing is not what the master branch is for. Writing effective t

Re: [E-devel] Managing the next release

This is a good point to raise, and I could probably have done a better job explaining in order to avoid confusion. The idea here is that during weeks 1+2, people could either begin work on a feature (the progress of which could then be used as evidence that the feature is feasible for this release

Re: [E-devel] Managing the next release

On Fri, 13 Jul 2018 08:16:11 +0200 Marcel Hollerbach said: > > > On 07/13/2018 07:20 AM, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach said: > > > >> Hello, > >> > >> As Mike & Stefan pointed out in the ML thread "Community Scheduling", > >>

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 sho

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 sc