On Oct 14, 2016 6:47 AM, "Emilian Bold" <[email protected]> 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
