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?

Regards,
Leonardo

On Tue, Oct 18, 2016 at 4:49 PM Mark Struberg <strub...@yahoo.de.invalid>
wrote:

> 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
>
> LieGrue,
> strub
>
> > 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 <
> cons...@wadechandler.com>
> > 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
> 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 <http://wiki.netbeans.org/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:
> >> 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
>
>

Reply via email to