Committer Contributor Hangouts/august 22

Time

10:30hr EST

Presentation

Richard Burcher from the Eclipse Foundation will talking about Changes your project may have to make to keep developing when it comes to the Eclipse Foundation as a project.

Hangout Link

Watch Event.

Participating in Q/A

• Email questions to emo@eclipse.org.
• Ask questions inside Hangout using chat function.

Hangout Video

• Video will be uploaded to the Eclipse YouTube channel after the Hangout here.

Discussion Script

Changes your project may have to make to keep coding when it comes to the Eclipse Foundation as a project

speaker introduction

Richard Burcher is the Community Manager at the Eclipse Foundation

structure of talk

summary

new projects coming to the Eclipse Foundation may have to make a few adjustments to how they develop and release code. for the most part, they're pretty easy adjustments to implement and in many cases you may be following some or all of them already:)

one item that bears discuss that influences many of the technical decisions here at the Foundation is, freedom of action. we need to ensure that anything we provide to folks via an external service (ie GitHub) will not affect a project if that service was to no longer be available or change its business model. we need to ensure we have all the information mirrored and/or hosted on our infrastructure.

at the end of the day, there's a lot here to know and understand. we acknowledge that and we're here to help you in any way we can. get in touch with us (EMO) at **emo@eclipse.org**.

discussion

basics

broken this down by major development theme

• repositories
  
  • Git
    
    • you'll need to be using Git. lol just had to make that explicit.
      
  • GitHub
    
    • we support that too:)
      
    • if you're using GitHub currently, you'll need to transfer your code repository over to us.
      
    • you're project will be hosted on one of our GitHub organizations.
      
• bug/issues tracker
  
  • we're Bugzilla based.
    
    • if you're using something other than Bugzilla, you'll need to switch and use our Bugzilla instances. it's up to you how you want to deal with the project bugs on the other tracker. we just ask that ongoing work happens in our Bugzilla instances.
      
    • we don't currently support GitHub issues yet. we know folks want this and we are working on a solution.
      
• communicating with your community
  
  • we're mailing list and forums oriented.
    
    • you'll need to ask your community to use the mailing list(s) we create for your project.
      
    • you'll need to ask your community to subscribe to the new mailing list(s). we don't auto-subscribe folks.
      
• build infrastructure
  
  • we use Hudson for continuous integration.
    
• developers
  
  • we categorize developers into two distinct categories:
    
    • committers
      • agree to abide by our Committer Due Diligence Guidelines.
        
      • they're elected to a specific project.
        
      • have full access to commit bits to projects repositories.
        
      • have access to Eclipse Foundation resources (project website, download servers, build infrastructure).
        
    • contributors
      • folks who contribute code to a project. think pull-requests.
        
      • do not have commit access to a projects repositories.
        
      • need to have agreed to our Committer License Agreement (CLA).
        
      • contributors can become committers.
        
  • general notes about access
    
    • everybody (with an Eclipse account) has read access to everything, with the exception of the build server and IPZilla.
      
• administrative
  
  • projects will need to be familiar and follow our processes/policies.
    • Eclipse Development Process (EDP)
      
      • think of this as our overall guidelines for projects at the Foundation.
        
    • IP Due Diligence.
  • this defines how code contributions are handled, how code is tracked, how 3rd party libraries are handled, legal reviews, distribution of code/binaries etc.
    
  • Contribution Questionnaires (CQ's)
    
  • these are the mechanism for managing/tracking the intellectual property that goes into your project.
    
  • they are the interface between your projects code and the Eclipse Foundation IP Team.
    
  • you'll be submitting these tickets for your projects initial code contribution, requests to use 3rd party libraries and for significant code contributions from contributors.
    
  • Release Reviews
    
  • this is how you make your project available to consumers for download.
    
  • required because:
    
  • they summarize what the project has added/fixed/removed for this release.
    
  • verify that the IP Policy has been followed and all approvals have been received.
    
  • verify that the project is continuing to operate according to the Principles and Purposes of the Eclipse Foundation.
    
  • only needed for major or minor changes to code base. bug fixes (service releases) do not require a review.
    
  • there are two scheduled release slots per month.
    
  • we are very flexible and quite accommodating:)