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. > - 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
