On Fri, 8 Jun 2018 13:35:56 -0400 Mike Blumenkrantz <[email protected]> said:
> I'm opposed to having a blanket policy that there can be no new features at > all added during a freeze. the policy has always been just this - but like everything there is some grey. if a new feature is needed to fix a bug then it's a bug fix, not a "new feature". > 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. actually the policy is good for the above. i was on holiday... and i disagree with adding such an api feature just in principal. every api you have is something that has to also be tested and ensured to work. then someone is going to use it in their apps and expect it to keep working. this should not be an api (public). it should be an internal. so no EAPI in the public header. it should be _eio ... to indicate it's internal and the tests should then declare the function prototype themselves. this way the control point exists without it having to become a public api, when all it exists for is so a test can do it's job. i think you chose a poor example. :) > 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. you are arguing for a change in current policy. that has always been the policy. see above. the point is to stop people from keeping on going in their feature development and have them come help get a release out. without having a very clear and strict policy, you don't send this message. of course like all things there is some flex. like above. if NECESSARY (e.g. a bug fix) a feature can come in. if it is NECESSARY for the release. if it's a "nice to have" then it can wait until after release. > On Fri, Jun 8, 2018 at 1:10 PM Felipe Magno de Almeida < > [email protected]> wrote: > > > On Fri, Jun 8, 2018 at 1:44 PM, Christopher Michael > > <[email protected]> wrote: > > > On 06/08/2018 11:17 AM, Mike Blumenkrantz wrote: > > >> > > >> Hello, > > >> > > >> Stefan is off for this entire month, so let's try organizing the > > release a > > >> bit while he's gone! > > > > [snip] > > > > >> * During the freeze period, all newly-submitted features (ie. anything > > >> submitted on or after the freeze start date) must go through patch > > review > > >> and receive 2+ approvals from core developers; if employed by Samsung, > > the > > >> developers must not work for the same office. > > > > > > I was under the impression that one of the points of a freeze is that no > > new > > > features could be added and we can focus on bug fixes. Your mention of > > > newly-submitted features "after the freeze start date" is a little > > > misleading.... > > > > Yes. I thought new features should land only after the release. I don't see > > why we should allow new features. > > > > [snip] > > > > > Cheers, > > > Chris > > >> > > >> regards, > > >> > > >> Mike > > > > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] ------------------------------------------------------------------------------ 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
