I like the idea of having many repos in git (ex: platform, java, php, etc)
and a parent repo with references to other repos for building all together.
+1 to work with external feature branches.
My only concern is about code reviews and continuous integration, there's a
possibility to use GitHub for that?
On Tue, Oct 18, 2016 at 4:49 PM Mark Struberg <strub...@yahoo.de.invalid>
> 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 <nic...@hedhman.org>:
> > http://nvie.com/posts/a-successful-git-branching-model/
> > On Fri, Oct 14, 2016 at 10:46 PM, Wade Chandler <
> > wrote:
> >> On Oct 14, 2016, at 08:53, Emilian Bold <emilian.b...@gmail.com> wrote:
> >>> This incubation is just the beginning of NetBeans under Apache. We
> >>> 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
> >> will do it quickly, and we give it some thought ahead of time so it
> >> 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
> >>> it's a matter of API stability <http://wiki.netbeans.org/API_Stability
> >>> It's easy to mark an API as Stable/Official and then the plugins
> >> 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
> >> 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
> >> “get there” and stop without going further; resource contentions etc.
> >> 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
> >> 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
> >> 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
> >> suggest it happens because of the culture of way things are organized.
> >> is called Conway’s Law, and I have an intuition some of that may be at
> >> with this topic:
> >> https://en.wikipedia.org/wiki/Conway%27s_law <https://en.wikipedia.org/
> >> wiki/Conway's_law>
> >> Wade
> > --
> > Niclas Hedhman, Software Developer
> > http://zest.apache.org - New Energy for Java