Hi, first, in my opinion each PR is welcome, why not cosmetic stuff too? There is always a need to refactor code to make it more readable, maintainable and sometimes or more often it makes stuff faster. So why not accepting everything?
Yes I think we need guidelines too. Like „when do we need Tests“, „how a commit should look like“, etc. and we need more branches. I mean atm we have develop, master and some feature branches? So develop should be the next release. Until a specific point, we need a relase branch like release/nb9 maybe for Alpha/beta and or rc state. So we have a fixed state where we can fix bugs and stuff but no new features. New features until beta or rc, should be done in feature branches and merged into develop, where this is NB9.1 or whatever. Than there will be no discussion about whether we can handle or we have time for „luxury“ stuff or not. Each PR, which is not a bug fix and important for the next release, is done inside the dev state when we have a release branch. Cheers Chris Von: Neil C Smith Gesendet: Freitag, 12. Januar 2018 10:02 An: dev@netbeans.incubator.apache.org Betreff: Re: Pull requests need to be reviewed On Fri, 12 Jan 2018 at 08:04 Geertjan Wielenga < geertjan.wiele...@googlemail.com> wrote: > I think we need to set up guidelines — e.g., a PR must be connected to an > issue; a PR must solve a problem and not be cosmetic only; etc. > > I’d advise looking at pull/3 by Chris instead. > I like Chris' PR, and see the benefit of it ... but, within those guidelines are we going to have the concept of feature freeze? In my opinion, if we're in beta vote phase, we should also only be accepting bug fixes. In which case, I'd be tempted to push that back to the next point release? Out of interest, what were the old NetBeans policies around feature freezing / release planning? Best wishes, Neil -- Neil C Smith Artist & Technologist www.neilcsmith.net Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
