[E-devel] IRC+Phab Integration

[Mike Blumenkrantz]

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 think this is the bot that the phabricator irc channel used before they
stopped using irc:
https://phabricator.wikimedia.org/project/profile/36/

If anyone wants to check it out feel free, I don't have anywhere reliable
to host such a bot.

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

Re: [E-devel] Community Scheduling

[William L. Thomson Jr.]

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] efl regressor

[William L. Thomson Jr.]

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 faster in Travis than replicating
> > an env over and over again for each build.  
> 
> We already do this. Docker images are based on various distros, efl
> dependencies added and then used for CI on Travis.

I should have checked out the travis.yml for efl. Thanks for pointing
it out. I will see if I can use it for my needs. Think I may need to
make others that have E, not just EFL. Either way thanks for mentioning!

> https://github.com/Enlightenment/ci-support-files
> https://hub.docker.com/r/stefanschmidt1/ci-support-files/
> 
> https://git.enlightenment.org/core/efl.git/tree/.travis.yml#n62
> 
> docker run -v `pwd`:/src -w /src
> stefanschmidt1/ci-support-files:$DISTRO /src/.ci/ci-linux-build.sh
> $CI_BUILD_TYPE

-- 
William L. Thomson Jr.


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

[Stefan Schmidt]

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] End of Week: Phab Report

[Mike Blumenkrantz]

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 able to find a
reviewer. Add yourself here if you haven't already!
* https://phab.enlightenment.org/T7142 is a master ticket to track all
kinds of issues and items of discussion related to the eventual 2.0
release. If you have something you think is fundamentally wrong in EFL or a
topic you think needs concrete, focused discussion, create a subtask here.

CI progress:
* Current build: https://travis-ci.org/Enlightenment/efl/builds/403595182
 - ~25 mins per build
 - release-ready build gets killed for taking too long
* CI development builds:
 - ccache enabled sub-15 minute builds:
https://travis-ci.org/Enlightenment/efl/builds/402876909
 - refactored scripts, first ever all-green build:
https://travis-ci.org/Enlightenment/efl/builds/403656270

On Fri, Jul 13, 2018 at 2:18 PM Mike Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> Hi,
>
> I forgot to send this last week and people were feeling demotivated, so
> it's back again.
>
> TICKETS:
> *https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/
> *
> * 10 regular tasks open with the 1.21 milestone
> Some work has already been done on these, and the number has once again
> been cut in half since the last report.
> * 4 regression tickets open which must be resolved before the final 1.21
> release
> All of these already have patches in review, no further work beyond
> review/testing is required.
> * This search query is now available in the sidebar of the maniphest view
> for easier access.
>
> PATCHES
> *https://phab.enlightenment.org/differential/query/38N2dAUrUZ7J/
> *
> * 13 patches awaiting review
> * This search query is now available in the sidebar of the differential
> view for easier access.
>
> If you aren't submitting your patches for review yet, please consider
> doing so using the documentation here:
> https://phab.enlightenment.org/w/arcanist/
>
> Build status is green at present, tests are all passing as well. Next week
> is a big Samsung internal event, so some slowdown may occur.
>
> Regards,
> Mike
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] End of Week: Phab Report

[Mike Blumenkrantz]

Hi,

I forgot to send this last week and people were feeling demotivated, so
it's back again.

TICKETS:
*https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/
*
* 10 regular tasks open with the 1.21 milestone
Some work has already been done on these, and the number has once again
been cut in half since the last report.
* 4 regression tickets open which must be resolved before the final 1.21
release
All of these already have patches in review, no further work beyond
review/testing is required.
* This search query is now available in the sidebar of the maniphest view
for easier access.

PATCHES
*https://phab.enlightenment.org/differential/query/38N2dAUrUZ7J/
*
* 13 patches awaiting review
* This search query is now available in the sidebar of the differential
view for easier access.

If you aren't submitting your patches for review yet, please consider doing
so using the documentation here: https://phab.enlightenment.org/w/arcanist/

Build status is green at present, tests are all passing as well. Next week
is a big Samsung internal event, so some slowdown may occur.

Regards,
Mike
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Community Scheduling

[Jonathan Aquilina]

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

[Jonathan Aquilina]

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

[Mike Blumenkrantz]

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

[Mike Blumenkrantz]

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

[Stephen Houston]

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

[Stefan Schmidt]

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

[Jonathan Aquilina]

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] Coverity on Terminology

[Stefan Schmidt]

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 build uploaded has been only partially compiled. We recommend at
 least 85% capture success to avoid false-positives during analysis. As
 per last few lines of cov-int/build-log.txt, the percentage of
 compilation units ready for analysis is 84% which is less than the
 expected 85%
>>>
>>> I've compiled it myself and got 89%.  I've uploaded a tarball to
>>> coverity with that.
>>>   However, I wonder this is not the case with our automated upload of
>>> those results.  Could someone help with that investigation?
>>
>> Its been a while you sent this. I still have seeing this problem on
>> coverity builds from Jenkins but sadly also on a manual build I did.
>>
>> Anything special you did to get this working locally for you? What is
>> your coverity tools version?
>>
>> regards
>> Stefan Schmidt
> 
> 
> I'm written a small cron script that runs coverity on terminology on my
> server every hour if needed, and then upload to coverity.  It runs
> coverity 2017.07.  It might be related to the compiler / headers found
> on the system.  I added this stupid patch just for coverity:
> https://git.enlightenment.org/apps/terminology.git/commit/?id=75689087ae680808cf006f83a2c4dfdc432602d7
> Might be useful elsewhere.

Thanks. I will give it another try next week. Maybe something similar to
your patch above is needed for efl as well. Will need to have a look.

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

[Stefan Schmidt]

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

[Jonathan Aquilina]

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

[Jonathan Aquilina]

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

[Jonathan Aquilina]

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] Coverity on Terminology

[Boris Faure]

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 recommend at
> >> least 85% capture success to avoid false-positives during analysis. As
> >> per last few lines of cov-int/build-log.txt, the percentage of
> >> compilation units ready for analysis is 84% which is less than the
> >> expected 85%
> > 
> > I've compiled it myself and got 89%.  I've uploaded a tarball to
> > coverity with that.
> >   However, I wonder this is not the case with our automated upload of
> > those results.  Could someone help with that investigation?
> 
> Its been a while you sent this. I still have seeing this problem on
> coverity builds from Jenkins but sadly also on a manual build I did.
> 
> Anything special you did to get this working locally for you? What is
> your coverity tools version?
> 
> regards
> Stefan Schmidt


I'm written a small cron script that runs coverity on terminology on my
server every hour if needed, and then upload to coverity.  It runs
coverity 2017.07.  It might be related to the compiler / headers found
on the system.  I added this stupid patch just for coverity:
https://git.enlightenment.org/apps/terminology.git/commit/?id=75689087ae680808cf006f83a2c4dfdc432602d7
Might be useful elsewhere.

Regards,
-- 
Boris Faure
Pointer Arithmetician


signature.asc
Description: 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] Coverity on Terminology

[Stefan Schmidt]

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-positives during analysis. As
>> per last few lines of cov-int/build-log.txt, the percentage of
>> compilation units ready for analysis is 84% which is less than the
>> expected 85%
> 
> I've compiled it myself and got 89%.  I've uploaded a tarball to
> coverity with that.
>   However, I wonder this is not the case with our automated upload of
> those results.  Could someone help with that investigation?

Its been a while you sent this. I still have seeing this problem on
coverity builds from Jenkins but sadly also on a manual build I did.

Anything special you did to get this working locally for you? What is
your coverity tools version?

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

[Stefan Schmidt]

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

[Stefan Schmidt]

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

[Mike Blumenkrantz]

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

[Stefan Schmidt]

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

[Stefan Schmidt]

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] New Phab Project

[Mike Blumenkrantz]

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 <
michael.blumenkra...@gmail.com> wrote:

> Hello,
>
> I have created the project 'DO NOT MERGE' in phabricator. This is the
> project which should be tagged to all "work in progress" patches, or any
> patch which should not be merged. Any patch containing this tag should not
> be merged to master under any circumstances and can be ignored in the
> review queue. This should help to avoid confusion in the future when people
> are working on test patches which do not need active review.
>
> 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

Re: [E-devel] Community Scheduling

[Stefan Schmidt]

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] efl regressor

[Stefan Schmidt]

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 preinstalled efl-1.19.
>>
>> You can pull it from https://hub.docker.com/r/bu5hm4n/eflregressor/.
> 
> I was checking out some of your docker images. I was looking into
> possibly making one myself to help speed up my E application CI
> testing. I tend to lose a fair amount of time fetching efl and e from
> third party Ubuntu PPA.
> 
> 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 faster in Travis than replicating an env over and
> over again for each build.

We already do this. Docker images are based on various distros, efl
dependencies added and then used for CI on Travis.

https://github.com/Enlightenment/ci-support-files
https://hub.docker.com/r/stefanschmidt1/ci-support-files/

https://git.enlightenment.org/core/efl.git/tree/.travis.yml#n62

docker run -v `pwd`:/src -w /src stefanschmidt1/ci-support-files:$DISTRO
/src/.ci/ci-linux-build.sh $CI_BUILD_TYPE

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Community Scheduling

[Mike Blumenkrantz]

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] EFL 1.21.0 alpha1 released

[Stefan Schmidt]

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

--
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] git-phab update

[Mike Blumenkrantz]

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
variable (you'd have to diff vs upstream git-phab to see the staging repo
thing).

On Fri, Jul 13, 2018 at 2:10 AM Jonathan Aquilina 
wrote:

> Hi mike,
>
> I have a bit of experience with python just rusty with it.
>
> What are you trying to achieve in a non hackish way?
>
> Sent from my iPhone
>
> > On 13 Jul 2018, at 02:17, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
> >
> > Hello,
> >
> > I've done more gross hacks to the git-phab script since no real python
> > developers have shown up:
> >
> > https://phab.enlightenment.org/P227
> >
> > This fixes adding project tags (-p option) as well as adding
> > reviewers/subscribers when updating patches.
> >
> > Still hoping someone better at python than me steps in to help out!
> >
> > Regards,
> > Mike
> >
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Managing the next release

[Stephen Houston]

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 prefer to do it by checking out a branch anyway than some ifdef.
Further, just use arc and/or git-phab and create a review revision and it
will definitely get looked at if you dont want to branch.  But actually
throwing it into master and using code to enable it or disable it is
completely defeating the purpose of the tools git, phab, arc offer us as
well as completely defeats the purpose of a release cycle.

On Fri, Jul 13, 2018, 3:28 AM Carsten Haitzler  wrote:

> 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",
> > >> doing EFL releases is quite a pain from time to time, we have a
> constant
> > >> "last minute" discussion about what is going to be merged, and what is
> > >> not. I feel like this is stretching nerves of everyone.
> > >>
> > >> However, the freeze period of efl-1.21 showed quite good that we can
> > >> actually coordinate ourself quite good via phabricator, we had a good
> > >> patch burn rate in that time. For me it felt like everyone knew where
> > >> are the current blockers, and where to put his/her effort to give the
> > >> whole project momentum towards the release.
> > >>
> > >> My idea is that i would like to test this also for the beginning of
> the
> > >> next release cycle, this means:
> > >> - When efl-1.21 is out of the door, I will immanently create
> another
> > >>   milestone efl-1.22.
> > >> - Over the first few weeks everyone can add feature/TODO/wishlist
> > >>   tickets, to this milestone.
> > >
> > > How about we just set a date. The feature makes it, or it doesn't.
> When the
> > > date comes near, if the feature hasn't landed already it can be
> deferred
> > > until after release in a branch or in an ifdef or a if () etc. etc.
> > >
> > > What you describe is a feature based release cycle, not a timed one,
> and
> > > that is what ended up delaying efl's releases for a long time
> recently. If
> > > releases happen regularly and things "make it or not" it'll be simple
> and
> > > smooth IMHO. I suspect Stefan would think this is the right way to go
> too.
> > > It's less complex than this as well and doesn't put pressure on
> features to
> > > take shortuts to make a date. There is always another release in 3-4
> months
> > > or so.
> >
> > Okay this might be formulated a bit weird, but i want to stay with time
> > based releases. This is just in addition to the schedule of time based
> > releases.
>
> OH  OK. what you wrote SOUNDED like feature based releases with a way of
> determining the features in it (tickets)...
>
> > As mike already added in his reply, there should also be a point in time
> > where we drop some features again. If they don't make it.
>
> Indeed that was my point. work on features. hope to get them in. if they
> don't
> make it - they don't go in the release (in branch, kept local to dev,
> ifdefs,
> if()'s etc.).
>
> > On your "ifdef or a if ()":
> > Maybe we should establish something that we dont merge features until
> > they are ready, or work in feature branches if things are not ready for
> > primetime. Then we are never getting into this situation.
>
> sometimes it's hard. you want people to test it without having to follow a
> branch and then have to keep merging master into the branch... inf act in
> most
> cases i find it simpler to not use a branch. branches i'd use only  for
> things
> that can't be sensibly done with if/ifdef etc. - you want to trial a new
> widget
> for example - it won't work unless you export ELM_NEWIDGET_X as a way of
> keeping it "alpha". perhaps you are trialling usability ideas. maybe it's
> an
> optimization of some code that's really tricky with lots of threads.
> you're not
> sure it's stable yet, so you can enable the optimized paths with an env var
> etc. ... things in branches get minimal testing, exposure etc. and keeping
> a
> branch up to date requires constant work.
>
> > Greetings,
> > bu5hm4n
> >
> >
> > >
> > >> - At some point few say thats enough and continue to work on those
> > >>   TODOs
> > >> - Over the time of the development period the TODO items are done,
> > >>   and new bugs / regressions are added back.
> > >> - The release can happen when we are safe to say that the amount
> of
> > >>   bugs has lowered
> > >>
> > >> This will give everyone a good overview of where the project is
> heading,
> > >> what is happening, who is working on what, and feels (at least to me)
> > >> that the 

Re: [E-devel] Managing the next release

[Mike Blumenkrantz]

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 tests, having code reviewed, [and optionally asking app
developers for feedback if relevant]--these are things that should be done
before code is merged to master. If code is being merged to master "for
exposure" or "for testing" then this is just another step towards the
endless number of regressions and technical debt that EFL has been
accumulating for years.

It's worth noting that keeping a feature branch rebased against the master
branch is also significantly less work when everyone is not immediately
pushing everything to master.

On Fri, Jul 13, 2018 at 4:28 AM Carsten Haitzler 
wrote:

> 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",
> > >> doing EFL releases is quite a pain from time to time, we have a
> constant
> > >> "last minute" discussion about what is going to be merged, and what is
> > >> not. I feel like this is stretching nerves of everyone.
> > >>
> > >> However, the freeze period of efl-1.21 showed quite good that we can
> > >> actually coordinate ourself quite good via phabricator, we had a good
> > >> patch burn rate in that time. For me it felt like everyone knew where
> > >> are the current blockers, and where to put his/her effort to give the
> > >> whole project momentum towards the release.
> > >>
> > >> My idea is that i would like to test this also for the beginning of
> the
> > >> next release cycle, this means:
> > >> - When efl-1.21 is out of the door, I will immanently create
> another
> > >>   milestone efl-1.22.
> > >> - Over the first few weeks everyone can add feature/TODO/wishlist
> > >>   tickets, to this milestone.
> > >
> > > How about we just set a date. The feature makes it, or it doesn't.
> When the
> > > date comes near, if the feature hasn't landed already it can be
> deferred
> > > until after release in a branch or in an ifdef or a if () etc. etc.
> > >
> > > What you describe is a feature based release cycle, not a timed one,
> and
> > > that is what ended up delaying efl's releases for a long time
> recently. If
> > > releases happen regularly and things "make it or not" it'll be simple
> and
> > > smooth IMHO. I suspect Stefan would think this is the right way to go
> too.
> > > It's less complex than this as well and doesn't put pressure on
> features to
> > > take shortuts to make a date. There is always another release in 3-4
> months
> > > or so.
> >
> > Okay this might be formulated a bit weird, but i want to stay with time
> > based releases. This is just in addition to the schedule of time based
> > releases.
>
> OH  OK. what you wrote SOUNDED like feature based releases with a way of
> determining the features in it (tickets)...
>
> > As mike already added in his reply, there should also be a point in time
> > where we drop some features again. If they don't make it.
>
> Indeed that was my point. work on features. hope to get them in. if they
> don't
> make it - they don't go in the release (in branch, kept local to dev,
> ifdefs,
> if()'s etc.).
>
> > On your "ifdef or a if ()":
> > Maybe we should establish something that we dont merge features until
> > they are ready, or work in feature branches if things are not ready for
> > primetime. Then we are never getting into this situation.
>
> sometimes it's hard. you want people to test it without having to follow a
> branch and then have to keep merging master into the branch... inf act in
> most
> cases i find it simpler to not use a branch. branches i'd use only  for
> things
> that can't be sensibly done with if/ifdef etc. - you want to trial a new
> widget
> for example - it won't work unless you export ELM_NEWIDGET_X as a way of
> keeping it "alpha". perhaps you are trialling usability ideas. maybe it's
> an
> optimization of some code that's really tricky with lots of threads.
> you're not
> sure it's stable yet, so you can enable the optimized paths with an env var
> etc. ... things in branches get minimal testing, exposure etc. and keeping
> a
> branch up to date requires constant work.
>
> > Greetings,
> > bu5hm4n
> >
> >
> > >
> > >> - At some point few say thats enough and continue to work on those
> > >>   TODOs
> > >> - Over the time of the development period the TODO items are done,
> > >>   and new bugs / regressions are added back.
> > >> - The release can happen when we are safe to say that the amount
> of
> > >>   bugs has lowered
> > >>
> > >> This will give everyone a good overview 

Re: [E-devel] Managing the next release

[Mike Blumenkrantz]

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 cycle), continue working on a deferred
feature from a previous cycle, start a large refactoring project, or fix
bugs.

Just because a feature doesn't make it into a release doesn't mean it can't
be worked on; if a feature will take 6 months to complete then it will need
to be worked on continually across more than one release cycle.

Alternatively, it may be more worthwhile to shift this initial 3 week
discussion+review period to overlap with the end of the previous release
cycle (i.e., now) to get people looking forward while release bug fixing is
going on. This would yield another 3 weeks of development time to be
allocated somewhere, assuming we decide to stick to a 12 week cycle.

On Thu, Jul 12, 2018 at 3:56 PM Marcel Hollerbach  wrote:

> Hello,
>
> Mhmm in week 1&2 no real work can be done, as the merging could be
> canceled due to 2, feels like progress is on hold there a bit. I would
> prefer to just "do" development there, and cleanup unfinished TODOs in 5.
>
> Otherwise this looks good to me.
>
> On 07/12/2018 09:02 PM, Mike Blumenkrantz wrote:
> > I think this is a good approach for managing releases going forward. If
> we
> > have a clear idea of what large features will be added to each release
> > around the onset of the development window then we can more easily work
> > towards those goals over a given time period. I propose the following
> > step-by-step process for all future releases, which should provide better
> > visibility for work items as well s greatly reduce the active work burden
> > of the release team:
> >
> > 1. during the first 2 weeks of the development cycle, tickets with TODO
> > priority are created (or re-tagged) with the 1.22 tag for "major"
> features
> > [weeks 1-2]
> >   - everyone works on proposed TODO items as interest/time allows
> > 2. after this period, a 1 week multi-vote is created on phabricator, and
> > core developers vote to defer any TODO ticket for a release past 1.22
> [week
> > 3]
> >   - this will promote discussion about work items, and allow review of
> > anything which might be too radical to accomplish within 3 months
> > 3. any TODO item which receives 5 or more votes from #committers is
> > deferred*
> >   - this means the work may not be merged into master at this time
> > 4. development progresses for 2 weeks [weeks 4-5]
> > 5. 2x 1 week multi-votes are created: [week 6]
> >   - feature development halts for 1 week, bug tickets on the "urgent"
> > workboard are handled as time allows
> > 5a. a vote to review existing "accepted" TODO items
> >   - it may be the case that unforeseen difficulties arise in
> development, so
> > this creates a process by which a work item can be officially deferred
> > 5b. a vote to review other TODO items which are not yet accepted
> >   - if some items are deferred then there may be extra time available, or
> > perhaps a proposal for implementing a feature has been reworked to make
> it
> > fit into the release better
> > 6. development progresses for 3 weeks [weeks 7-9]
> > 7. feature freeze begins [week 10]
> >   - any "major" feature patches submitted before the freeze begins can
> still
> > be reviewed and landed
> >   - any "major" feature patches submitted after the freeze are
> > unconditionally deferred until the next release
> >   - any "small" feature patches can be landed (with 3+ reviews and no
> > rejects after being on phab for 48+ hours)
> >   - alpha release at end of week 10
> > 8. bug fixing [week 11]
> >   - no features of any kind may be landed unless they are "small" and are
> > required in order to fix an urgent (high/showstopper priority) bug
> >   - beta release at end of week 11
> > 9. bug fixing [week 12]
> >   - no features of any kind may be landed unless they are "small" and are
> > required in order to fix an urgent (high/showstopper priority) bug
> > 10. release evaluation [end of week 12]
> >   - if release can be executed, release ships
> >   - otherwise, perform pre-release and repeat steps 9-10 until release
> ships
> >
> > Additionally, I think this is a good time to review our usage of '@' tags
> > in commit logs. For a long time we've done this, even though it doesn't
> > really do much; consider the "@fix" tag, which is applied to basically
> > every commit since it's impossible to keep track of when a bug
> originated.
> > Now that patches are going through review, it seems like generating
> release
> > notes based on the phabricator-applied tags when landing a patch should
> be
> > much more reliable. This also greatly reduces the burden on the release
> > manager and allows for increased automation when generating release
> notes.
> >
> > On Thu, Jul 12, 2018 at 2:15 PM 

Re: [E-devel] Managing the next release

[Carsten Haitzler]

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",
> >> doing EFL releases is quite a pain from time to time, we have a constant
> >> "last minute" discussion about what is going to be merged, and what is
> >> not. I feel like this is stretching nerves of everyone.
> >>
> >> However, the freeze period of efl-1.21 showed quite good that we can
> >> actually coordinate ourself quite good via phabricator, we had a good
> >> patch burn rate in that time. For me it felt like everyone knew where
> >> are the current blockers, and where to put his/her effort to give the
> >> whole project momentum towards the release.
> >>
> >> My idea is that i would like to test this also for the beginning of the
> >> next release cycle, this means:
> >> - When efl-1.21 is out of the door, I will immanently create another
> >>   milestone efl-1.22.
> >> - Over the first few weeks everyone can add feature/TODO/wishlist
> >>   tickets, to this milestone.
> > 
> > How about we just set a date. The feature makes it, or it doesn't. When the
> > date comes near, if the feature hasn't landed already it can be deferred
> > until after release in a branch or in an ifdef or a if () etc. etc.
> > 
> > What you describe is a feature based release cycle, not a timed one, and
> > that is what ended up delaying efl's releases for a long time recently. If
> > releases happen regularly and things "make it or not" it'll be simple and
> > smooth IMHO. I suspect Stefan would think this is the right way to go too.
> > It's less complex than this as well and doesn't put pressure on features to
> > take shortuts to make a date. There is always another release in 3-4 months
> > or so.
> 
> Okay this might be formulated a bit weird, but i want to stay with time 
> based releases. This is just in addition to the schedule of time based 
> releases.

OH  OK. what you wrote SOUNDED like feature based releases with a way of
determining the features in it (tickets)...

> As mike already added in his reply, there should also be a point in time 
> where we drop some features again. If they don't make it.

Indeed that was my point. work on features. hope to get them in. if they don't
make it - they don't go in the release (in branch, kept local to dev, ifdefs,
if()'s etc.).

> On your "ifdef or a if ()":
> Maybe we should establish something that we dont merge features until 
> they are ready, or work in feature branches if things are not ready for 
> primetime. Then we are never getting into this situation.

sometimes it's hard. you want people to test it without having to follow a
branch and then have to keep merging master into the branch... inf act in most
cases i find it simpler to not use a branch. branches i'd use only  for things
that can't be sensibly done with if/ifdef etc. - you want to trial a new widget
for example - it won't work unless you export ELM_NEWIDGET_X as a way of
keeping it "alpha". perhaps you are trialling usability ideas. maybe it's an
optimization of some code that's really tricky with lots of threads. you're not
sure it's stable yet, so you can enable the optimized paths with an env var
etc. ... things in branches get minimal testing, exposure etc. and keeping a
branch up to date requires constant work.

> Greetings,
> bu5hm4n
> 
> 
> > 
> >> - At some point few say thats enough and continue to work on those
> >>   TODOs
> >> - Over the time of the development period the TODO items are done,
> >>   and new bugs / regressions are added back.
> >> - The release can happen when we are safe to say that the amount of
> >>   bugs has lowered
> >>
> >> This will give everyone a good overview of where the project is heading,
> >> what is happening, who is working on what, and feels (at least to me)
> >> that the project has a visible and messurable "speed" of development,
> >> which is always nice from a motivation POV. Additionally we can see what
> >> blocks specific tasks.
> >>
> >> A additional plus point of this is, that we can finally tag Easy / Hard
> >> / Impossible to those TODO tickets. I feel like adding them to TODOs is
> >> a lot easier than adding them to real bugs. As saying a bug is hard or
> >> easy, can just be right if you have either found the cause, (then you
> >> can fix it yourself), or it was that hard that you did not find it, and
> >> you tag impossible (which will then definitly not get new devs motivated).
> >>
> >> And ideas on that ? Happy with it ?
> >>
> >> This is such a heavy thing that we might want to call out a irc meeting
> >> at some point.
> > 
> > I think so. I am in favour of timed releases (with a bit of slack like a
> > week or 2 here or there). They are simple. They de-complicate things. The
> > decouple features 

Re: [E-devel] Community Scheduling

[Jonathan Aquilina]

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

[Jonathan Aquilina]

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] Managing the next release

[Marcel Hollerbach]

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",
doing EFL releases is quite a pain from time to time, we have a constant
"last minute" discussion about what is going to be merged, and what is
not. I feel like this is stretching nerves of everyone.

However, the freeze period of efl-1.21 showed quite good that we can
actually coordinate ourself quite good via phabricator, we had a good
patch burn rate in that time. For me it felt like everyone knew where
are the current blockers, and where to put his/her effort to give the
whole project momentum towards the release.

My idea is that i would like to test this also for the beginning of the
next release cycle, this means:
- When efl-1.21 is out of the door, I will immanently create another
  milestone efl-1.22.
- Over the first few weeks everyone can add feature/TODO/wishlist
  tickets, to this milestone.


How about we just set a date. The feature makes it, or it doesn't. When the
date comes near, if the feature hasn't landed already it can be deferred until
after release in a branch or in an ifdef or a if () etc. etc.

What you describe is a feature based release cycle, not a timed one, and that is
what ended up delaying efl's releases for a long time recently. If releases
happen regularly and things "make it or not" it'll be simple and smooth IMHO.
I suspect Stefan would think this is the right way to go too. It's less complex
than this as well and doesn't put pressure on features to take shortuts to make
a date. There is always another release in 3-4 months or so.


Okay this might be formulated a bit weird, but i want to stay with time 
based releases. This is just in addition to the schedule of time based 
releases.


As mike already added in his reply, there should also be a point in time 
where we drop some features again. If they don't make it.


On your "ifdef or a if ()":
Maybe we should establish something that we dont merge features until 
they are ready, or work in feature branches if things are not ready for 
primetime. Then we are never getting into this situation.


Greetings,
   bu5hm4n





- At some point few say thats enough and continue to work on those
  TODOs
- Over the time of the development period the TODO items are done,
  and new bugs / regressions are added back.
- The release can happen when we are safe to say that the amount of
  bugs has lowered

This will give everyone a good overview of where the project is heading,
what is happening, who is working on what, and feels (at least to me)
that the project has a visible and messurable "speed" of development,
which is always nice from a motivation POV. Additionally we can see what
blocks specific tasks.

A additional plus point of this is, that we can finally tag Easy / Hard
/ Impossible to those TODO tickets. I feel like adding them to TODOs is
a lot easier than adding them to real bugs. As saying a bug is hard or
easy, can just be right if you have either found the cause, (then you
can fix it yourself), or it was that hard that you did not find it, and
you tag impossible (which will then definitly not get new devs motivated).

And ideas on that ? Happy with it ?

This is such a heavy thing that we might want to call out a irc meeting
at some point.


I think so. I am in favour of timed releases (with a bit of slack like a week or
2 here or there). They are simple. They de-complicate things. The decouple
features and releases really.


Greetings,
 bu5hm4n

--
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] git-phab update

[Jonathan Aquilina]

Hi mike,

I have a bit of experience with python just rusty with it.

What are you trying to achieve in a non hackish way?

Sent from my iPhone

> On 13 Jul 2018, at 02:17, Mike Blumenkrantz  
> wrote:
> 
> Hello,
> 
> I've done more gross hacks to the git-phab script since no real python
> developers have shown up:
> 
> https://phab.enlightenment.org/P227
> 
> This fixes adding project tags (-p option) as well as adding
> reviewers/subscribers when updating patches.
> 
> Still hoping someone better at python than me steps in to help out!
> 
> Regards,
> Mike
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel