Yes, I too am wondering about PRs. Does the Apache git infra support pull requests? Is it a GitHub Enterprise install? Maybe a better question is: What is supported by the infrastructure? PRs are massively useful.
Wade On Oct 18, 2016 6:25 PM, "Leonardo Loch Zanivan" <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]>: > > > > > > http://nvie.com/posts/a-successful-git-branching-model/ > > > > > > On Fri, Oct 14, 2016 at 10:46 PM, Wade Chandler < > > [email protected]> > > > wrote: > > > > > >> On Oct 14, 2016, at 08:53, Emilian Bold <[email protected]> > 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 > > > > >
