On Thu, 2016-10-13 at 08:14 -0400, Wade Chandler wrote:
> 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 <vladimirvv@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?
> Wade

I tend to agree with you Wade.

Both solutions have their pros and cons. But as a contributor NBPython,
I'd prefer not to have the big main repository on my machine. I don't
need most of it and it takes a lot of space. From a private discussion
I had with a user of NBPython in an RCP app, having the whole main repo
is problematic (space, compilation time) So I think that we are more
likely to get external contributors with small repositories.

I like your point about integrating modules currently developed outside
the core (Python, Gradle). Even if by importing the repos in git we
manage to filter stuff and make it a reasonable size, it will be much
easier to integrate these modules from outside in the infrastructure
without loosing any history in a modular approach.

Julien Enselme

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to