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?
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>
> 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,
> 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?