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 <ras...@rasterman.com> wrote: > 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 > ------------------------------------------------------------------------------ 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
