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
