I'd like to provide some mentor guidance to this discussion.
As an Apache project we need to ensure collaboration and provenance are
served and supported properly.
With that in mind, new feature development, and for that matter *all*
development should allow and enable collaboration by the whole community
in a clearly recognizable and discoverable way.
Git and github are 'just' means to that end, and while git and github
makes it really easy to do some 'disjunct' work elsewhere (e.g. in a
private or otherwise shared repository), it doesn't reflect to, or even
is relevant to the Netbeans community, *until* it gets merged into
the Apache git repository (or repositories) of the project.
A *collaborative* effort done elsewhere IMO should be regarded as a bad,
worrisome practice from Apache POV as it may violate the fundamental
Apache principles for collaboration and provenance.
That doesn't mean community members (committers included) can't use
their own fork to (start) develop new features, or create a fix, to be
pulled into the project git repository (or repositories).
By all means that's perfectly fine, and for non-committers even the
(only) way to contribute!
But as soon as more than one developer gets involved (community or
committer) to collaborate, and it concerns a feature or fix the project
cares about, then the logical thing is to create a feature or fix branch
in the project repository for it, either to start with, or by doing an
initial pull/merge for that purpose.
That will ensure proper provenance and visibility on the effort and
allows everyone in the community to reflect and join the effort if desired.
Should this be done on branches in the 'main' repository, or if a
separate netbeans-prototypes repository to keep the main repository
'clean' ?
Should committers be allowed to directly push to such branches or also
should use their own (private) fork and then use pull requests to get
their changes in?
Those are policy decisions the PPMC as a whole needs to decide and
document.
My personal choice would be to just use the main repository and allow
committers to use and push directly to branches therein.
And IMO part of that policy should concern how to name(space) branches
properly, to distinguish (if needed) between for example prototypes,
features, bugfixes and possibly release targeting branches.
HTH,
Ate
On 2017-10-22 22:00, Neil C Smith wrote:
Hi,
On Sat, 21 Oct 2017, 15:41 Jan Lahoda, <lah...@gmail.com> wrote:
I guess I could live with this (although it leaves it unclear how new
feature branches would be created), but it feels cumbersome to me and the
advantages are not very clear to me. Why doing the pull request when there
would be no need to have a review from someone else? Overall, does not feel
like encouraging work inside the ASF repositories.
Sorry for the delay in responding to that question. To me, besides merging
being a somewhat "safer" way of working with lots of people, the other
thing for me would be the ability to hook in automatic reviews, such as
tests passing. Not necessarily all tests on branches but might be good that
things like RAT are confirmed to pass before anything hits the ASF repo?
For the record I'm +1 to making the feature branches in the main repo for
now and taking time to work out optimum workflow.
I believe new feature branches can be set up in the web UI by the way.
Best wishes,
Neil
--
Neil C Smith
Artist & Technologist
www.neilcsmith.net
Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org
