On 07/13/2018 07:20 AM, Carsten Haitzler (The Rasterman) wrote:
On Thu, 12 Jul 2018 20:14:47 +0200 Marcel Hollerbach <m...@bu5hm4n.de> 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
