On Friday, January 12, 2018, Christian Lenz <christian.l...@gmx.net> wrote:
> 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? The concern is that we could end up with hundreds of PRs that are nothing more than small tweaks for no clear reason, drowning out PRs such as yours that provide new meaningful features. We do need to discuss this, probably in a new thread, but I’d suggest each PR needs to start off with a new issue describing exactly what the problem is, with the proposed solution, followed by some discussion, after which a PR is made. Refactoring for the sake of refactoring, without any planning or motivation, could lead to chaos. Gj > > 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 > >
