This incubation is just the beginning of NetBeans under Apache. We don't have to reinvent ourselves at once.
> But, if we bring everything in, just as a dump, and then Oracle folks continue to work as they had previously, without the bigger context, and the community tries to work around that, then IMO it won't be as successful. You have a point here, but if NetBeans developers used team repositories / branches until now who are we to tell them to stop? It's not inherently a bad way to work. 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. 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. 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. --emi On Fri, Oct 14, 2016 at 3:28 PM, Wade Chandler <cons...@wadechandler.com> wrote: > On Oct 14, 2016 6:47 AM, "Emilian Bold" <emilian.b...@gmail.com> wrote: > > > > When we spoke about "teams" we spoke in the context of how NetBeans > > developer from Oracle have been working on NetBeans. > > > > If you look at http://hg.netbeans.org/ there are multiple repositories > with > > the title "xxx team repository". So the profiler guys would commit their > > (stil-not-finished) stuff in their own branch (which is similar in > concept > > to a feature branch) and only later on will their changes be pushed to > > everybody else. This reduces the chance of a random commit breaking a > build > > for everybody. > > > > So, by using the team branches it will be easier to continue development. > > > > What about integrating early and often? Especially in the context of a > single monolith repository such things are dangerous, and in the context of > a broader community. If a team is making changes to many modules, and some > other group from the community another, then that becomes problematic. Once > they are done, then integration is going to be a nightmare if there is more > isolation. If those things are for just the specifics of their modules, > then a feature branch works perfectly. Maybe someone is solidifying a > concept, OK, so a single new branch lives a little longer, but not a life > time. I definitely think the Oracle teams plus the community needs to give > this some thought. It is a different context, and external communications > with others is paramount, and how everyone views integration helps a lot > with that communication. > > > There is nothing stopping new or existing contributors to use feature > > branches. > > > > I think (IMO) everyone should per reasons stated above. Why not? It should > be rare, outside of development/main and master/main-golden, for there to > be long lived branches which will include changes which may break a lot of > people. That would be difficult to rectify without some extra thought to > how these problems arise ahead of time. > > > Do note that the purpose of this migration is just to be able to start > > working under Apache. It is not about imposing a technical way of doing > > software. Every community is allowed to develop software how they see > fit. > > > > Perhaps you'd have to be more clear on that. Apache is a community as well > as each sub-community inside of it. Then there is the bigger notion of all > us who contribute to one. > > Within this one which we are contributing, we have to be able to check out > code, and too, have some notions of how different companies and > organizations will tread and not step on each other's toes. I imagine if > the processes don't promote more positive ways to keep things smooth, the > community will get irritable. Even in smaller contexts that can be painful > without a plan, and this is the community where we are talking about > developing software, and where we should be choosing how we see fit to > develop software; this is the context unless I miss your point. > > Too, there is getting the code here and working on it, and then precedents > we set with how we will work. I think those things are good to talk about > ahead of time. > > If we bring in the whole repo as a single repo now, and have a plan to > split it, or at least talk through some of the issues many see with the way > things are done now, and how to address them, see Sven and Julien's > comments as others examples, then that sounds fine. But, if we bring > everything in, just as a dump, and then Oracle folks continue to work as > they had previously, without the bigger context, and the community tries to > work around that, then IMO it won't be as successful. This is a new > context. > > There were other issues with contributions in the old model, and I think we > have a good opportunity to look at those. One of them was the repo size IMO > which is over 1GB even without history. I think another is an over reliance > on friend dependencies which have made it harder to do more things with > plugins without modifying the core, or some other big central thing, which > inevitably meant fixing an issue, and getting to use the fix in the > released software took a long time in many cases. > > Wade >
