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.
Difference between revisions of "Development Resources/Words of Wisdom and Bits of Advice"
(New page: These are things that Eclipse Project leads and committers need, and should, be doing on a regular basis (daily/weekly/weekly/quarterly/etc). ===Bugzilla=== A common question new projects...) |
(→Use The Correct Servers) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
===Bugzilla=== | ===Bugzilla=== | ||
| − | + | There are many schemes for using Bugzilla, but a common one is described on [[Development Resources/HOWTO/Bugzilla Use|Bugzilla Use]]. | |
===Heartbeat Builds=== | ===Heartbeat Builds=== | ||
| − | We have learned that projects cannot successfully build their [http://www.eclipse.org/projects/dev_process/development_process.php# | + | We have learned that projects cannot successfully build their [http://www.eclipse.org/projects/dev_process/development_process.php#2_3_Three_Communities three communities] without regular milestone releases (we recommend six to eight week periods), nor can it do so without regular, successful, heartbeat builds (we recommend at least nightly). Projects need regular milestones and builds so that their three communities can continuously pick up, integrate, test, use, and provide feedback on the latest features and improvements. Projects that do not provide frequent builds are effectively working in the closed rather than in the open. |
Projects often make use of the PDE project's PDE BUILD tools to help automate the builds. | Projects often make use of the PDE project's PDE BUILD tools to help automate the builds. | ||
| Line 21: | Line 21: | ||
===Release Reviews=== | ===Release Reviews=== | ||
| − | Each major release (where | + | Each major release (where ''major'' is defined as any release whose N or M version number changes in the N.M.P version number) must go through a [[Development Resources/HOWTO/Release Reviews|Release Review]]. Please schedule enough time to complete the Review and any potential remedial actions so as not to impact the project's release schedule. |
| − | === | + | ===Keep Source Repositories Clean=== |
| − | As the projects evolve, some | + | As the projects evolve, some components become stale and cause confusion to newcomers when they are browsing the repositories. Stale code should be removed from the working tree in your source code repositories (but remain in the repository's history). Stale code should--in general--never be completely removed. In some cases it may make sense to archive an entire stale repository. Ultimately, it's important to observe the principle of least surprise and do what's best for your communities. |
| − | + | ||
| − | In | + | |
===Status Reporting=== | ===Status Reporting=== | ||
| − | All projects are required to report their status using the [ | + | All projects are required to report their status using the [[Development Resources/HOWTO/Project Meta-Data|Project Status Reporting infrastructure]]. |
| − | + | ||
===Use The Correct Servers=== | ===Use The Correct Servers=== | ||
| − | The eclipse.org infrastructure is solid | + | The eclipse.org infrastructure is solid and capable, but it is also capable of being brought to its knees by poor file placement. Projects will follow these guidelines: |
| − | * | + | * Avoid links to [http://dev.eclipse.org/viewcvs/index.cgi/ viewcvs] pages that render web content on-the-fly from HEAD ([http://dev.eclipse.org/viewcvs/index.cgi/eclipse-project-home/plans/eclipse_after_2_1.html?view=co example]). Instead, commit the content to your project's website and use normal links. |
| − | * Do not place downloads or large files on the dev.eclipse.org | + | * Do not place downloads or large files on the dev.eclipse.org machine (the web pages or the source code repository). Use the download.eclipse.org machine for all downloads - these machines are load balanced, mirrored and have a separate bandwidth allotment. |
| − | ** Large files that change often should be placed on download | + | ** Large files that change often should be placed on download servers. |
** Files larger than 5Mbs should be placed on the download servers. | ** Files larger than 5Mbs should be placed on the download servers. | ||
** All zip and gzip files should be placed on the download servers. | ** All zip and gzip files should be placed on the download servers. | ||
| − | ''This page is moderated by | + | ''This page is moderated by the EMO'' |
[[Category:Development_Resources]] | [[Category:Development_Resources]] | ||
[[Category:How to Contribute]] | [[Category:How to Contribute]] | ||
Latest revision as of 13:40, 10 April 2012
These are things that Eclipse Project leads and committers need, and should, be doing on a regular basis (daily/weekly/weekly/quarterly/etc).
Contents
Bugzilla
There are many schemes for using Bugzilla, but a common one is described on Bugzilla Use.
Heartbeat Builds
We have learned that projects cannot successfully build their three communities without regular milestone releases (we recommend six to eight week periods), nor can it do so without regular, successful, heartbeat builds (we recommend at least nightly). Projects need regular milestones and builds so that their three communities can continuously pick up, integrate, test, use, and provide feedback on the latest features and improvements. Projects that do not provide frequent builds are effectively working in the closed rather than in the open.
Projects often make use of the PDE project's PDE BUILD tools to help automate the builds.
- We recommend that the automated build system use anonymous pserver CVS commands rather than extssh because it's faster, it's more secure (no developer password), and build system errors cannot accidentally modify any files.
Milestone Releases
Interim milestone and release candidate releases will be named n.nMn (e.g., 3.3M4) or n.nRCn (e.g., 4.1RC2). The n.n and n.n.n release numbering is reserved for the final Reviewed release. Additionally, all nightly, integration, milestone, release candidate, and final releases will be available via a download link found on the project's home page.
Main eclipse.org Web Pages
The eclipse.org site has various news and announcement pages, as well as pages that describe the projects and top-level PMCs. To request an announcement or news, send email to emo@eclipse.org. To change your project's pages, use the project's website CVS: /cvsroot/org.eclipse/www/[project]
Nuturing the Three Communities
Project teams will obviously be doing this, but we include it here for the sake of completeness and as a reminder that it is very important. Continue to use the public mailing lists, respond in the newsgroups, write articles, staff code camps, triage the bugzilla, attend the Eclipse community events (e.g. EclipseCon, Eclipse Summit Europe, Council meetings, ...) and so on.
Release Reviews
Each major release (where major is defined as any release whose N or M version number changes in the N.M.P version number) must go through a Release Review. Please schedule enough time to complete the Review and any potential remedial actions so as not to impact the project's release schedule.
Keep Source Repositories Clean
As the projects evolve, some components become stale and cause confusion to newcomers when they are browsing the repositories. Stale code should be removed from the working tree in your source code repositories (but remain in the repository's history). Stale code should--in general--never be completely removed. In some cases it may make sense to archive an entire stale repository. Ultimately, it's important to observe the principle of least surprise and do what's best for your communities.
Status Reporting
All projects are required to report their status using the Project Status Reporting infrastructure.
Use The Correct Servers
The eclipse.org infrastructure is solid and capable, but it is also capable of being brought to its knees by poor file placement. Projects will follow these guidelines:
- Avoid links to viewcvs pages that render web content on-the-fly from HEAD (example). Instead, commit the content to your project's website and use normal links.
- Do not place downloads or large files on the dev.eclipse.org machine (the web pages or the source code repository). Use the download.eclipse.org machine for all downloads - these machines are load balanced, mirrored and have a separate bandwidth allotment.
- Large files that change often should be placed on download servers.
- Files larger than 5Mbs should be placed on the download servers.
- All zip and gzip files should be placed on the download servers.
This page is moderated by the EMO