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. <cow...@bbs.darktech.org> 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 <anto...@vieiro.net> 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 <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 >> >> >> >> >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org >> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org >> >> For further information about the NetBeans mailing lists, visit: >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >> >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
