I can't agree more with Antonio and Geertjan: as a community we need to
keep our eyes focussed on the goal: delivering a superior IDE to
developers. And doing so in a timely fashion.
My earlier suggestions about voting to move forward with a beta release
intended to support keeping that focus. From the many things that could
be improved in the code, and with such a large code base and extensive
functionality there alway will be a lot of these, we need to identify
which will be essential to realise before getting to the next stage of
release.
As an open source project we need to find a balance between on one side,
sustaining a vibrant community, where many are engaged and feel
appreciate for their various roles, and in efficiently making
decissions. To be specific, democracy is great for the former but may at
times be too slow and not explicit enough for the latter.
After a community decision to have a beta release we will need a small
committee to rank any changes to code and functions that should be
realised before the next stage. In my view Geertjan, possibly together
with a couple of others should have that task, the task of identifying
these essential additions to the beta code base. The input for the
decision on essential PRs should be, primarily, in my proposal, from the
issues provided accompanying the vote to go to beta. And, next to
setting the priorities that small group should set a date by which the
next release stage should ideally be ready.
With that date for a next release known, any PR that was not qualified
as a priority and for which some members in the community had the energy
to address the issue in time could still be considered for integration.
Such additional PRs could be required to be ready some time before the
times set for the essential ones to give time for deciding on them
without interfering with the main line of the delivery schedule.
A further thought on the small committee that takes those decisions
about timely moving from beta to the next stage in the release, in
addition to a small core of one or two people, members of the community
could self nominate for membership thereof. To that end the size of the
committee, let's call them the "release shepherds' has a maximum size,
7, or so, and self nomination happens in two stages: first, interest to
be involved as release shepherd is indicated on the ballot response,
secondly, if there are more candidates, those interested discuss amongst
themselves who of them will be a shepherd this time. As background, I
have very good experience with self nomination for the governance of a
very long-running (30+ years) of a no-conference i participate in
(Consultants' Camp <http://www.consultantscamp.org>).
In summary, the idea i developed here, is to structure a vote for beta
release to have three parts:
— up/down/don't care (=+1/-1/0), this is required to be a real vote
-—One or more PRs the voter considers essential to integrate before the
next stage. Optional with +1 vote, required with a -1 vote.
-—Self nomination as shepherd, optional.
The idea to require at least one PR with a negative vote is borrowed
from international standardisation with ISO. The idea is that addressing
these issues would change the vote to, at least, don't care (=0).
These rules should apply only to a vote for a beta release at that's
when we, as a community, decide it's really ready to release, so that
release should happen sooner rather than later.
I realise all this is getting a a bit more than 2¢. Sorry about that. At
this point in time, I don't have much time to contribute to the coding
effort, yet I like to support NB as it moves into open source, by
sharing some of my experiences with open organisations and democratic
decisions in standardisation and in (city) politics. These ideas may be
worth a dedicated thread of discussion. Anyway, there's no harm in
experimenting and adjusting based on what we learn.
Cheers
Eduard
Antonio 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
