I'm sure the physical machines themselves will not be donated. But the space on them might, i.e., we could decide that some of the artifacts should stay where they are. The source code, i.e., the active Mercurial repos, should move to Apache Git, mirrored on Apache GitHub, ideally. The process will be i imagine as described by Mark Struberg earlier in this thread, i.e., quoting him below:
1.) lots of legal questions, code provenance and CLA checks, IP reviews etc > 2.) Migrating hg to git. Not a big deal actually. Just add a github repo > for it and add the hg url. Github does it for you. Then git clone this and > move it to our canonical GIT repos. There was also a fast-export tool over > at Petrs git repo ages ago. > 3.) Identify and fix core parts which we cannot get re-licensed under ALv2 > but cannot be kept due to legal questions. > Raphael is most probably right that NetBeans and OpenOffice share similar > aspects when it comes to the setup. NetBeans is such a big project that we > probably should get in touch with them as well. > 4.) Migrate the community! THAT will be some serious effort I think. Many > people are not aware of the pros and cons of running inside a well > structured OSS foundation. Some people initially only see the positive > aspects, others only the negative ones. The truth is: there is no free > lunch. If you add structure you will loose flexibility. Without structure > otoh you will melt down quickly. > 5.) Build releases and distribute them. > 6.) Empower the community to be able to manage itself in the spirit of a > true ASF project. Gj On Fri, Sep 16, 2016 at 12:53 AM, John D. Ament <johndam...@apache.org> wrote: > Sorry for top posting (phone), but of the machines listed, are any > available to be migrated or donated to the ASF? Or expected to be? > > Mac builds is an interesting topic on this as well. > > On Sep 15, 2016 6:36 PM, "Geertjan Wielenga" < > geertjan.wiele...@googlemail.com> wrote: > > > Notes on the NetBeans infrastructure from the NetBeans build engineer. > Who > > from Apache infra is going to do 1:1 discovery? > > > > Public servers: > > - www.netbeans.org: The core of the netbeans.org project, as well as > user > > management, bugzilla, and mailing lists. > > - hg.netbeans.org: 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 www.netbeans.org. The special > > directory http://hg.netbeans.org/binaries/ on the server contains and > > provides 3rd party libraries. > > - deadlock.netbeans.org: 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. > > - bits.netbeans.org: 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. > > - downloads.oracle.com and updates.netbeans.org: 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. > > - statistics.netbeans.org: A machine providing statistics on NetBeans > > usage. > > - plugins.netbeans.org: The server for community plugins. > > - forums.netbenas.org: NetBeans forums. > > - services.netbeans.org: 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 <a...@shanecurcuru.org> > > 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: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > >
