incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [DISCUSS] Apache NetBeans Incubator Proposal
Date Thu, 15 Sep 2016 23:22:07 GMT
On Thu, Sep 15, 2016 at 6:36 PM, Geertjan Wielenga
<> wrote:
> Notes on the NetBeans infrastructure from the NetBeans build engineer. Who
> from Apache infra is going to do 1:1 discovery?

Daniel Gruno will - feel free to reach out directly to him at

In the meantime, this is a good but of information, Thanks!

> Public servers:
> - The core of the project, as well as user
> management, bugzilla, and mailing lists.
> - 1 VM with 32 Mercurial repositories. The main
> repositories are main-golden, main-silver, releases, and all team
> repositories (core-main, cnd-main, jet-main, profiler-main, ergonomics),
> localization repository (releases/l10n). Several of the repos are inactive
> and don't need to be migrated. Repos are available via http/https. The
> server doesn’t have its own authentication mechanism. Authentication for
> pushes is realized via JSON request from The special
> directory on the server contains and
> provides 3rd party libraries.
> - 6 VMs, used mainly for propagation of changes
> between team repositories and to the releases repository, including jobs
> for building community plugins (releases*-au) and jobs for prototype
> projects.
> - 1 VM, which is the backup download server and is the
> server for Javahelp and JNLP. The Nexus server runs there and it provides
> NetBeans Maven artifacts.
> - and The main download server
> for installers and update centers. Bits are in fact published on Akami
> servers all over the world. The server is not under NetBeans team control.
> We only upload data to a specific place and they are processed somehow by
> Akami.
> - A machine providing statistics on NetBeans usage.
> - The server for community plugins.
> - NetBeans forums.
> - Services such as anti spam filters for bugzilla
> are here, as well as weekly NetBeans newsletter maintenance.
> Internal servers:
> - nbbuilder: 5 VMs. The Hudson server with its slaves, where nightly builds
> and release builds are run.
> - nbbuilder2: 5 VMs. The Hudson server with its slaves, where Maven
> repositories are generated.
> - big-mac: Physical machine used for Mac OS X installers.
> - nbstrorage: Internal storage for all NetBeans bits, access is allowed for
> internal users only via HTTP.
> - Oracle signing server: NetBeans build jobs using Oracle signing
> infrastructure for signing installers and NBMs.
> Comments or follow up to the above?
> Thanks,
> Gj
> On Thu, Sep 15, 2016 at 11:38 PM, Shane Curcuru <>
> wrote:
>> Mitch Claborn wrote on 9/15/16 11:07 AM:
>> > I'm very new in this type of thing. I have zero experience with ASF,
>> > etc, so if this is out of line, please forgive and I'll keep silent.
>> >
>> > I've seen a lot of discussion about the HOW in terms of moving NetBeans
>> > to the Apache project, but not much/any discussion about WHY. I'm not a
>> > NetBeans coder/contributor, but simply someone who uses it 8+ hours per
>> > day in my normal job.
>> >
>> > My main question is: will moving NetBeans to Apache result in a better
>> > product for people like me? If so, what particular aspects of moving
>> > will make that happen? Are there other projects that have made a similar
>> > move and experienced higher quality as a result?
>> As Bertrand noted else-thread: the move is because the actual people
>> planning to *work on the code* want to make the move (and obviously
>> Oracle is happy to help with the IP donations).
>> Apache is here to help communities of individual contributors build
>> software products for the public good.  We welcome any community that
>> wants to use the Apache Way of open, collaborative decision making, and
>> that will use our license and other structures.  The existing people
>> actually coding NetBeans are making the proposal, and the Apache
>> Incubator is happy to review it to see if it will fit here (seems like
>> it will, albeit with plenty of licensing and infrastructure changes).
>> Many people believe that in the long run it *will* make for a better
>> product for users, because becoming an independently governed project at
>> the ASF will draw in more code (and test, doc, plugin, etc.)
>> contributors from new places to help improve the product.
>> Does that make sense?
>> - Shane
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message