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. Regards, -- Julien Enselme http://www.jujens.eu/
signature.asc
Description: This is a digitally signed message part
