+1, btw, I didn't catch the freeze period. What is the next release date we are expecting to ? it just depends on all fixes bugs listed up?
On Sat, Jun 9, 2018 at 3:40 AM, Mike Blumenkrantz < [email protected]> wrote: > Sure, I agree with what you are saying but this is still a bit subjective > and so I don't think there is a need to attempt to codify that in the form > of a policy. Even if a major feature is merged during a freeze which seems > unnecessary (e.g., adding some giant new widget) then it's quite easy for > the community to come together and vote to remove it until after the > release occurs. All features added during freeze must go through patch > review based on this proposal, and all core developers are automatically > assigned to all efl patch submissions so it is impossible to be unaware of > things like this going forward. > > I think everyone in non-western countries is likely asleep now, but if > there is no strong dissent by end of day Monday then we can continue with > this course of action and begin preparing the release in earnest. > > On Fri, Jun 8, 2018 at 2:24 PM Felipe Magno de Almeida < > [email protected]> wrote: > > > On Fri, Jun 8, 2018 at 2:35 PM, Mike Blumenkrantz > > <[email protected]> wrote: > > > I'm opposed to having a blanket policy that there can be no new > features > > at > > > all added during a freeze. > > > > > > As an example, https://phab.enlightenment.org/D6247 is a feature which > > is > > > required in order to improve test reliability--something which should > be > > at > > > the top of the list when working on a release. A strict "no features at > > > all" policy would prevent this from being merged until after the > release, > > > leading to unreliable testing during the release cycle. This level of > > > pedantry is not beneficial to the project. > > > > I agree. > > > > > A freeze should mean that features are not likely to be added. It > should > > > not, however, mean that features cannot be added. Having a strict > policy > > > for this case does nothing more than establish such a policy for the > sake > > > of having a strict policy instead of having a policy which benefits the > > > project. Anyone electing to merge features during the freeze should be > > > cognizant of this, and should also be aware that the rest of the > > community > > > may disagree and overrule the decision. > > > > I think I expressed myself stricter than necessary. I think new > > features that aren't going to improve *correctness* should not be > > considered. A feature that helps fix bugs could be considered > > if it delivers a release with less bugs. > > > > Regards, > > -- > > Felipe Magno de Almeida > > > > > > ------------------------------------------------------------ > ------------------ > > 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 > > [email protected] > > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Regards, Hermet ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
