Commit Before Review - unless the change is an API change - then we use review before integration and the review is done in bugzilla.
Committers never directly push to the cannonical repo master branch. That branch is closed for integration. In Git terminology, each team (jet-main, web-main, core-main, ergonomics) has it's own branch and only if all checks pass is the branch merged into the master branch automatically. Yes, before a doing a release there is a manual stabilisation phase. Gerrit has never been used by the NetBeans team. Thanks, Geertjan On Fri, Sep 16, 2016 at 8:51 AM, Mark Struberg <strub...@yahoo.de.invalid> wrote: > That goes into a direction I was about to ask anyway, the development > model: > > Is it CTR (commit-then-review) or RTC (review-then-commit). > > Means do committers directly push to the cannonical repo master branch and > before doing a release there is a manual stabilisation phase? Or do you > only apply finished features? > > Question is whether we need Gerrit or something similar. Or is plain GIT > enough? > > LieGrue, > strub > > > > > > On Friday, 16 September 2016, 7:01, Geertjan Wielenga < > geertjan.wiele...@googlemail.com> wrote: > > > > > > > >Of the 32 repos in Mercurial, not all are active. We assume we'll have > >Git-style development under Apache, with pull requests. That is, however, > a > >different working/infrastructure style than we have had in Oracle, with > >parallel integration (http://wiki.netbeans.org/ > HgParallelProjectIntegration). > >Thus, many of the repos are only there to participate in the parallel > >integration (core-main, jet-main, web-main, etc.) We don't believe it is a > >requirement to migrate all of those repos, probably we won't even need > >them, when we analyze the infrastructure migration in detail during > >incubation. However, the #1 requirement is for Apache NetBeans to be able > >to produce daily/release builds and to upload them to netbeans.org or > >another download area under Apache. We believe > >http://hg.netbeans.org/releases/ should be enough for that. > > > >Thanks, > > > >Geertjan > > > > > >On Fri, Sep 16, 2016 at 5:33 AM, Geertjan Wielenga < > >geertjan.wiele...@googlemail.com> wrote: > > > >> Thanks. Contacting him. > >> > >> More info, this time statistics: > >> > >> Total Physical Source Lines of Code = 8,281,256 > >> Total Number of Files = 64927 > >> > >> Thanks, > >> > >> Geertjan: > >> > >> > >> > >> On Fri, Sep 16, 2016 at 1:22 AM, David Nalley <da...@gnsa.us> wrote: > >> > >>> On Thu, Sep 15, 2016 at 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? > >>> > >>> Daniel Gruno will - feel free to reach out directly to him at > >>> humbed...@apache.org > >>> > >>> In the meantime, this is a good but of information, Thanks! > >>> > >>> --David > >>> > > >>> > 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 > >>> >> > >>> >> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > >>> For additional commands, e-mail: general-h...@incubator.apache.org > >>> > >>> > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
