NetBeansDreamTeam/Proposals/Infrastructure/Java.net

Revision as of 18:09, 5 April 2011 by Wadechandler (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

Contents

Java.net Infrastructure for Supporting the NB Community

We have talked about having an infrastructure much like that of the Eclipse community. We came up with the set of information detailed below which we can start to improve here as it specifically relates to Java.net and more specifically The NetBeans Project on Java.net.

We need to work out any other issues needed for the community within the Java.net infrastructure in this page. Perhaps we request something special out of Java.net. Perhaps for those items we come up with other inventive solutions using what we have available now or other free services provided to open source on the internet. Either way, we need to discuss further.

Top Level and Sub-Project Support

Problem:

Currently there is no ability for someone to bring logic or create it as a full sub-project within the NetBeans infrastructure and community. This limits the types of contributions which can take place out of the box. By out of the box I mean a top level or sub-project is created within the infrastructure, code is built, possible contributors are solicited, mailing lists, forums, source control, etc are setup and a sub-project, as a contribution to the NetBeans community, begins.

To me, this is where Eclipse is beating NetBeans as a community. Such a system allows for companies and individuals to come into an area within the community and establish a foot print and bind resources to the project. It is more of a stake of ownership. But too, this helps bring other contributions to the areas which those sub-projects depend upon such as the base platform.

It also gives people a place to house and build those things while also branding them within the NetBeans community as a whole. This gives a presence. As more do this, it not only gives them presence, but grows NetBeans, the project, the community, the support, user levels, resources, and gives NetBeans more presence as well.

Imagine this as top level projects with the possibility for sub-projects. Thus, there may be a top level project called PlatformX located at platformx.netbeans.org and then there may be platformx.netbeans.org/projects/centrallookup. Granted Central Lookup is probably to small to be in its own project, it is a stand alone idea, and serves at least as an example. It would probably be even nicer if projects could be accessed as sub-domains such as centrallookup.platformx.netbeans.org.


Proposed Solutions:

  • Can NetBeans.org (Kenai) support such features for a domain name or group of projects already? --Wade Chandler
  • If we do not know, then who do we need to be talking with regard to Kenai/Java.net? --Wade Chandler
  • How do Oracle folks feel about this in general? --Wade Chandler
  • Too, just like Apache, we need some concept of incubating. --Wade Chandler
  • Project leads need to be able to manage their own project or sub-domain and sub-projects. --Wade Chandler
+1, I like the idea with a kenai support for projects. --Arittner 06:36, 29 March 2011 (UTC)
+1, I like the idea with --Sreimers 15:39, 29 March 2011 (UTC)
  • Projects need
    • Sub-Domains (see the points on top-level vs sub projects in this section)
    • Ability to create sub-projects
      • How would that work with repositories?
      • Would a sub-project of a project use the same repository or a different one?
    • User and Permission Management Facilities
    • Mailing Lists
    • Forums
      • Integration with mailing lists would be nice
    • Web page management
      • Instead of large caching delays, it would be nice if there was some staging environment content developers could login to and see changes immediately. Then, the things everyone else sees could be accessed through the caches and a time delay for something to go live. Would make working on site pages easier to see them in action immediately.
    • Source Repositories
      • One for project web site
        • That or instead us a pattern such as X folder in your repository is your web site
      • One for actual source code
      • These need to be their own repositories separate from the giant single repository currently holding NetBeans
      • It would be nice if like the Eclipse projects, these would support multiple technologies such as SVN and Mercurial at the same time; perhaps git as well
    • CI environment
    • Ability to get built modules and clusters/suites into the correct AU centers
      • Please see the information on incubation for more info

Incubation

I currently propose we have a way to designate projects as incubating or not, and this determines how those projects show up in AU centers which people can register in their IDEs. For instance, there could be an incubator.dev, incubator.beta, and incubator.release set of AUs and then production.dev, production.beta, and production.release. Naming can be worked out later, but that is the general idea for how to manage what is incubating or not.

Projects, while incubating, will still show up as top level projects, but will be marked as such in the header for a warning for anyone viewing them. This should allow for a smoother transition for projects, and less for mentors and Oracle folks to do when something graduates from incubator to production.

Having some property which designates them as incubating allows for them to be able to be located in different search results or link sets. This means if one goes to some link, "Incubating Projects", they will possibly see categories and then projects in those categories and be able to click on them and go to their project pages and sub-domains. --Wade Chandler

Continous Integration

At the moment http://deadlock.netbeans.org is the server where CI is done for NetBeans IDE. Is it possible to find an "official" way to open this up (apply for being on CI), so that an important contribution can be build against trunk/releases automatically? --Sreimers 15:39, 29 March 2011 (UTC)

Yes, CI would be great. This is something Apache does for its projects, and it is good. It allows for building, testing, etc. Something different in NB land compared to most of Apache land is automated user testing. Are there any resources for shared visual VMs where AUT could be setup for NB sub-projects? If more clarity is needed on what that means, please let me know. --Wade Chandler

Project Leads and Management

I don't know how user management would work for the sub-projects of a top level project. Perhaps if you are a member of the top-level project, you have direct access to all sub-projects. That sounds reasonable to me. Thus, if you have administrator rights to the top-level project, you then have administrative rights to any sub-projects. --Wade Chandler

Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo