The gitflow model is imo only worth it if you have dedicated build masters who 
really are the ‚masters‘ of what goes into a release or not.

This works fine for company projects where you have seniors waving through the 
work of juniors. But at the end those build-masters need to have a good 
knowledge about the single features. 
It’s kind of the Linux model, but all in the same repo instead of pulling from 
other repos and applying patches.
Do we have such a build-master at the ASF? Usually we do not! All committers 
usually know the code very well. Of course NetBeans is a bit different and of 
course a few people like Geertjan and Jan do know MUCH more about what is good 
for a stable code base and what rather needs some more tinkering.
In a long term I guess it is one of the goals to broaden the pool of people who 
have a good overlook over the project.
For contributors who are  rather new to such a huge code base, I think it might 
be good to work with external feature branches and rebase instead.

just my .02


> Am 15.10.2016 um 01:05 schrieb Niclas Hedhman <>:
> On Fri, Oct 14, 2016 at 10:46 PM, Wade Chandler <>
> wrote:
>> On Oct 14, 2016, at 08:53, Emilian Bold <> wrote:
>>> This incubation is just the beginning of NetBeans under Apache. We don't
>>> have to reinvent ourselves at once.
>> I agree with that.
>>> Let's first see how people start contributing and if there is friction
>> due
>>> to different work approaches, I'm sure some new consensus will be
>> reached.
>> I think that is feasible as long as everyone agrees if we need to shift we
>> will do it quickly, and we give it some thought ahead of time so it isn’t
>> such a big deal if/when it happens.
>>> Like I've mentioned before, I don't believe the repository size is an
>>> issue. It's a big project with a big history. Even if I could checkout
>> just
>>> the file I want to patch, in order to build and test that I would still
>>> have to download the NetBeans binaries and the smallest download is
>> 110MB.
>> But not exactly apples to apples…even without history you are talking
>> about 110MB to 1GB which is nearly a 1000% difference.
>>> Friend dependencies are also not a problem of the source code structure,
>>> it's a matter of API stability <>.
>>> It's easy to mark an API as Stable/Official and then the plugins problem
>> is
>>> solved. But then somebody has to respect this contract and support that
>> API
>>> throughout releases, which is not an easy task.
>> To me we are talking 2 different contexts though; supporting the framework
>> for the larger community versus a narrowed scope of who has to manage
>> something once it goes into the wild. Too, I think there are plenty of
>> examples of folks not being able to do something because of friend deps
>> without becoming a friend, and that seems to suggest it was easier to just
>> “get there” and stop without going further; resource contentions etc. Sure,
>> that same thing could happen even across repositories, and would need to be
>> left that way for some time, but I think definitely needs to be part of the
>> process to address, and to me is some times related to separation of
>> development; monolith mindset versus modular even if modular the mindset
>> can set in with a gigantic blob of code all bound by the build system and
>> repository. I’m not saying it is directly related, but I think there is
>> good correlation as it tends to happen in systems, and the trends seem to
>> suggest it happens because of the culture of way things are organized. This
>> is called Conway’s Law, and I have an intuition some of that may be at play
>> with this topic:
>> <
>> wiki/Conway's_law>
>> Wade
> -- 
> Niclas Hedhman, Software Developer
> - New Energy for Java

Reply via email to