Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Committer Contributor Hangouts/august 22"

(Discussion Script)
Line 20: Line 20:
  
 
== Discussion Script ==
 
== Discussion Script ==
<nowiki>
 
Changes your project may have to make to keep coding when it comes to the Eclipse Foundation as a project
 
  
speaker introduction
+
=== 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
 
Richard Burcher is the Community Manager at the Eclipse Foundation
  
structure of talk
+
=== structure of talk ===
  
summary
+
==== 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:)
 
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:)
Line 35: Line 35:
 
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.
 
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.
+
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 [mailto:**emo@eclipse.org** **emo@eclipse.org**].
  
discussion
+
==== discussion ====
  
basics
+
===== basics =====
  
 
broken this down by major development theme
 
broken this down by major development theme
  
repositories
+
* repositories<br />
Git
+
* Git<br />
you'll need to be using Git. lol just had to make that explicit.
+
* you'll need to be using Git. lol just had to make that explicit.<br />
GitHub
+
* GitHub<br />
we support that too:)
+
* we support that too:)<br />
if you're using GitHub currently, you'll need to transfer your code repository over to us.
+
* if you're using GitHub currently, you'll need to transfer your code repository over to us.<br />
you're project will be hosted on one of our GitHub organizations.
+
* you're project will be hosted on one of our GitHub organizations.<br />
bug/issues tracker
+
* bug/issues tracker<br />
we're Bugzilla based.
+
* we're Bugzilla based.<br />
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.
+
* 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.<br />
we don't currently support GitHub issues yet. we know folks want this and we are working on a solution.
+
* we don't currently support GitHub issues yet. we know folks want this and we are working on a solution.<br />
communicating with your community
+
* communicating with your community<br />
we're mailing list and forums oriented.
+
* we're mailing list and forums oriented.<br />
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 use the mailing list(s) we create for your project.<br />
you'll need to ask your community to subscribe to the new mailing list(s). we don't auto-subscribe folks.
+
* you'll need to ask your community to subscribe to the new mailing list(s). we don't auto-subscribe folks.<br />
build infrastructure
+
* build infrastructure<br />
we use Hudson for continuous integration.
+
* we use Hudson for continuous integration.<br />
developers
+
* developers<br />
we categorize developers into two distinct categories:
+
* we categorize developers into two distinct categories:<br />
committers
+
* committers
agree to abide by our Committer Due Diligence Guidelines.
+
** agree to abide by our Committer [https://www.eclipse.org/legal/committerguidelines.php Due Diligence Guidelines].<br />
they're elected to a specific project.
+
** they're elected to a specific project.<br />
have full access to commit bits to projects repositories.
+
** have full access to commit bits to projects repositories.<br />
have access to Eclipse Foundation resources (project website, download servers, build infrastructure).
+
** have access to Eclipse Foundation resources (project website, download servers, build infrastructure).<br />
contributors
+
* contributors
folks who contribute code to a project. think pull-requests.
+
** folks who contribute code to a project. think pull-requests.<br />
do not have commit access to a projects repositories.
+
** do not have commit access to a projects repositories.<br />
need to have agreed to our Committer License Agreement (CLA).
+
** need to have agreed to our [https://www.eclipse.org/legal/CLA.php Committer License Agreement (CLA)].<br />
contributors can become committers.
+
** contributors can become committers.<br />
general notes about access
+
** general notes about access<br />
everybody (with an Eclipse account) has read access to everything, with the exception of the build server and IPZilla.
+
** everybody (with an [https://dev.eclipse.org/site_login/createaccount.php Eclipse account]) has read access to everything, with the exception of the [https://wiki.eclipse.org/IT_Infrastructure_Doc#Builds build server] and [https://wiki.eclipse.org/IPzilla IPZilla].<br />
administrative
+
* administrative<br />
projects will need to be familiar and follow our processes/policies.
+
* projects will need to be familiar and follow our processes/policies.
Eclipse Development Process (EDP)
+
** [https://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process (EDP)]<br />
think of this as our overall guidelines for projects at the Foundation.
+
** think of this as our overall guidelines for projects at the Foundation.<br />
IP Due Diligence.
+
* [https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf 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.
+
** this defines how code contributions are handled, how code is tracked, how 3rd party libraries are handled, legal reviews, distribution of code/binaries etc.<br />
Contribution Questionnaires (CQ's)
+
** [https://wiki.eclipse.org/Development_Resources/Contribution_Questionnaire Contribution Questionnaires (CQ's)]<br />
these are the mechanism for managing/tracking the intellectual property that goes into your project.
+
** these are the mechanism for managing/tracking the intellectual property that goes into your project.<br />
they are the interface between your projects code and the Eclipse Foundation IP Team.
+
** they are the interface between your projects code and the Eclipse Foundation IP Team.<br />
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.
+
** 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.<br />
Release Reviews
+
** [https://wiki.eclipse.org/Development_Resources/HOWTO/Release_Cycle Release Reviews]<br />
this is how you make your project available to consumers for download.
+
** this is how you make your project available to consumers for download.<br />
required because:
+
** required because:<br />
they summarize what the project has added/fixed/removed for this release.
+
** they summarize what the project has added/fixed/removed for this release.<br />
verify that the IP Policy has been followed and all approvals have been received.
+
** verify that the IP Policy has been followed and all approvals have been received.<br />
verify that the project is continuing to operate according to the Principles and Purposes of the Eclipse Foundation.
+
** verify that the project is continuing to operate according to the Principles and Purposes of the Eclipse Foundation.<br />
only needed for major or minor changes to code base. bug fixes (service releases) do not require a review.
+
** only needed for major or minor changes to code base. bug fixes (service releases) do not require a review.<br />
there are two scheduled release slots per month.
+
** there are two scheduled release slots per month.<br />
we are very flexible and quite accommodating:)
+
** we are very flexible and quite accommodating:)
</nowiki>
+

Revision as of 07:47, 21 August 2014

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.
  • 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:)

Back to the top