On Oct 12, 2016, at 15:23, Sven Reimers <sven.reim...@gmail.com> wrote:
> Hi all,
> what keeps me thinking is that there is actually always a difference
> between modules that are now part of the main repository and "other"
> modules (provided by the larger community), e.g. being a  friend to "core"
> modules if your are not part of the main tree always seemed very hard
> (resulting in a lot of implementation dependencies requiring re-releases
> for all major/minor NetBeans versions).
> How will we handle this in the new infrastructure at / in Apache? How would
> we decide which module ge's in a mega master repository?
> I have a gut feeling that we have the chance to / should fix this now.. but
> not yet sure how..
> Ideas? Comments?
> Sven

Yes, I think this is problematic, and plays with the below to some degree. I 
will explain below.

> On Oct 12, 2016, at 09:54, Vladimir Voskresensky <vladimi...@apache.org> 
> wrote:
> On 2016-10-12 15:30 (+0300), Emilian Bold <emilian.b...@gmail.com> wrote: 
>> As I mentioned before I don't see this an improvement of the status-quo,
>> technically. 
> I would agree with Emilian, that the current structure proved to work and it 
> works reliable.
> If the main advantage of split is "size", then we need to see new numbers 
> when history is moved as well. 
> Btw, sometimes Java introduces the new feature, then C++ introduces the same 
> functionality, so we agree to make refactorings by generalizing common parts 
> and moving them into platform/nb layer, while keeping 
> Java-specific/C++-specific code in corresponding places. History is easier 
> manageable when it happens in one repo.

Perhaps more manageable for the teams working in that single repo, but what 
about other community modules? Is this not perhaps why we end up with more 
friends and less open APIs, and then requests to get that support are not able 
to be handled because of time, and the thing not being easy to do after the 
fact? If those gates currently considered easy were not available, but perhaps 
replaced with a better distribution plan, then perhaps quick “friend” fixes 
would be done in a more modular manner from the beginning leading to better 
community module support and requiring less friend dependencies. I think this 
addresses Sven’s point by breaking things up, and personally, the more 
separation which can be worked in the more it causes APIs to be flushed out for 
the sake of the community plus those “core” modules.

Too, I think there is practicality in having smaller more modular repositories 
where some smarter system for producing the final artifacts exists. Smaller 
repositories makes it easier for folks  to contribute to specific problem sets 
by not having to clone some massive repository. If the successes hoped by the 
move to Apache prove out, then should we not see the repository grow 
significantly over time?

So, maybe there is something to be said for bringing things over as they are 
now, for the sake of incubation, progress, and the code grant, but I think 
there has to be a goal and a plan for something more nuanced than exists now.

> As another example: we implemented Terminal in C++, then 'contributed' into 
> Full IDE by simple re-regestring module in nbbuild/cluster.properties. One 
> repo fits better, than moving modules between different ones

I’m not sure that had as much to do with it being the single repository as the 
way the artifacts bundles (installs and archives) are produced. I think the 
notion of a core release could be baked into a separate repository allowing 
disjoint development with a unified release; a build problem versus a source 
repository problem. This could even allow Python to be more easily integrated 
into the community release of core again, or allow for more “out of the box” 
type installers. What if someone adds Kotlin support as an example? Would it 
then come into the core? What about Attila’s gradle support? Should gradle 
really continue as something only available by way of the plugin center yet not 
Maven and Ant? It is quite popular and important these days. Should that have 
to come to “core” or the main repository for that to happen?


Reply via email to