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
