On Fri, 13 Jul 2018 08:16:11 +0200 Marcel Hollerbach <m...@bu5hm4n.de> said:
> > > 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. 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 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 > -- ------------- 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
