I don't think anyone is pretending anything. :-) The point is simply we can't do everything at the same time -- but since you care about these kinds of issues, you're very welcome to review them, there's nothing stopping you.
I agree we do need to document our desired coding style and need to set up guidelines -- would you like to work on that too? Here's the standard NetBeans code conventions as a starting point: https://netbeans.org/community/guidelines/code-conventions.html Gj On Sat, Jan 13, 2018 at 12:10 PM, Gili T. <[email protected]> wrote: > 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 >> >> >> >> --------------------------------------------------------------------- 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
