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
> 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
> 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.


Reply via email to