It seems to me that maybe you need to document your desired coding style and perhaps ask people to break PRs into smaller pieces but beyond that I see nothing wrong with someone reducing the number of compiler warnings in a PR and nothing else.
Code hygine is a necessary part of software development. To pretend you can wish it away rarely leads to positive outcomes for end-users. Gili On Sat, Jan 13, 2018, 05:51 Geertjan Wielenga < [email protected]> wrote: > OK, here it is: https://github.com/apache/incubator-netbeans/pull/361 > > Looking forward to your review, > > Gj > > On Sat, Jan 13, 2018 at 11:47 AM, Gili T. <[email protected]> wrote: > > 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 > >> > >> > >> > >> > > --------------------------------------------------------------------- > 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 > > > >
