I guess I'll be the odd man out: the bigger the project the more relevant cosmetic fixes are in my opinion. Why? Because in the 10+ years I've used NetBean, bug fixes were more important to me than new features. Cosmetic fixes tend to reduce the bug count at the cost of new features and I'm certainly in favor of that at the moment.
Gili On Sat, Jan 13, 2018, 02:35 Antonio <[email protected]> wrote: > Hi, > > My 2 cents: I agree with Geertjan: I think we should concentrate our > efforts in the best NetBeans 9 we can build for users. There're many > important things to do, ranging from the website to the jdk-javac > branch. And many new tools to control, ranging from the wiki to the very > slow JIRA issue tracker. > > I think we should stay focused in those things that worry users, for the > benefit of the users, and leave those code-cosmetic, internal changes > for later on. After all NetBeans users deserve the best IDE we can > build, and it does not really matter to them if we're improving the > readability of ternary operators or if we're replacing for loops with > the Streaming API. > > NetBeans is the second Apache project by size (as per [1]), with more > than 5.5M lines of code. Making those millions of lines of code more > readable & pretty may be a perfect academic case study, but spending our > efforts on those areas won't make our users more happy. > > Cheers, > Antonio > > [1] > Apache in 2017 - By The Digits > https://blogs.apache.org/foundation/entry/apache-in-2017-by-the > > On 12/01/18 11:54, Geertjan Wielenga wrote: > > On Friday, January 12, 2018, Christian Lenz <[email protected]> > 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: [email protected] > >> Betreff: Re: Pull requests need to be reviewed > >> > >> On Fri, 12 Jan 2018 at 08:04 Geertjan Wielenga < > >> [email protected]> 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 > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
