Rooba
/
boinc
mirror of https://github.com/BOINC/boinc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Page: Development_Workflow
Pages
API Implementation ATI Radeon Account managers AccountControl AccountManagement AccountManagers Adaptive Replication AdminAlphaTest AdminApprovedProjects AdminDepLibs AdminDepLibsCurl AdminDepLibsOpenSSL AdminDepLibsSqlite AdminDepLibsZlib AdminInstallerMac AdminInstallerUnix AdminInstallerWin AdminLocalize AdminReleaseAndroid AdminReleaseManagement AdminRoles AdminTasks AdminWrappers Advanced view AlphaInstructions AndroidBoinc AndroidBoincImpl AndroidBoincTesting AndroidBoincTodo AndroidBuildApp AndroidBuildClient AndroidBuildStatus AndroidGuiDiscuss Anonymous platform AppCoprocessor AppDebug AppDebugAndroid AppDebugWin AppDev AppFiltering AppIntro AppLibraries AppMultiThread AppPlan AppPlanSpec AppVersion AppVersionNew Apple Metal Support AssignedWork Assimilation introduction Assimilators in C Assimilators in scripting languages AutoFlops AutoUpdate BOINC Client BOINC Data directory BOINC Help BOINC Manager BOINC Security BOINC screensaver BOINC apps (introduction) BOINC community BOINC events BOINC overview BOINC projects BOINC software development BOINConPhones BUDA implementation BUDA job submission BUDA overview BUDA setup BackendLogic BackendPrograms BackendState BackendUtilities BadgeDoc BadgesOld BashCommandCompletion BasicApi BasicConcepts BerkeleyTasks BetaTest BlackList BoincBasics BoincContributersCall BoincDocker BoincFiles BoincGovernanceWorkingGroups BoincIntro BoincLite BoincPapers BoincPlatforms BoincPmcPage BoincPr BoincProjectsCall BoincSecurity Boinccmd tool BuildClientProcedure BuildMacApp Building BOINC on Unix Building BOINC software CamelCase CancelJobs CertSig Changes to this Wiki Choosing and joining projects Client configuration Client release notes ClientAppConfig ClientDataModel ClientFiles ClientFsm ClientLogic ClientOpaque ClientSched ClientSchedOctTen ClientSchedOld ClientSchedVersionFour ClientSetupLogicWin ClientSetupLogicWinFileLayout ClientSetupLogicWinSix ClientSetupLogicWinSixCleanup ClientSetupWinSix ClientSim CloudServer CodeSigning CodingStyle CommIntro Command line job submission CompileApp CompileAppLinux CompileAppWin CompileClient CompileWithWxWidgets CompoundApps Computation credit Computing with BOINC CondorBoinc ConferenceList Contact BOINC ContributePage Controlling BOINC remotely CoreClient CpuSched Create a BOINC server (cookbook) CreateProjectCookbook Creating a skin for the BOINC Manager Creating custom installers CreditAlt CreditGeneralized CreditNew CreditNotes CreditOptions CreditProposal CreditStats CrossProjectUserId CudaApps DataBase DataFlow DbDump DbIds DbPurge DebugClientWin DeleteFile Deploy Linux apps using VirtualBox (cookbook) DesignKeywords DesktopGrid DevMethodologies DevProcess DevProjects DevProjects_New DevQualityAssurance Development_Workflow DiagnosticsApi DirHierarchy DiskManagement Docker and WSL Docker app cookbook Docker app implementation Docker apps Docker design alternatives DownloadInfo DownloadOther DrupalConversion DrupalIntegration EastCoast08 Editing computing preferences with the BOINC Manager EmBoinc EmailChangeNotification EmailLists Error handling (cookbook) Error handling (introduction) ErrorReference Error_Abortingtask_Exceededdisklimit Error_Cantdeletepreviousstatefile Error_Givinguponupload Error_Schedulerrequestfailed ExampleApps FileCompression FileDeleter FileList FileUpload FortranApps Fossils GPU computing GPUApp GSoC_13 GdprCompliance GetFile GetFileList GitMigration Global prefs override.xml Going public GpuSched GpuSync GpuWorkFetch GraphicsApi GraphicsApiOld GraphicsApps GraphicsHtml GridIntegration GuiRpc GuiRpcProtocol GuiUrls HTMLGfx HarzPics Heat and energy considerations Home Homogeneous App Version Homogeneous Redundancy Host identification and merging HostId HostMeasurement How BOINC works HtmlOps Initialization files InstallDrupal Installing BOINC on Debian or Ubuntu Installing BOINC on EC2 Installing BOINC on Fedora Installing BOINC on Gentoo Installing BOINC on Ubuntu Installing BOINC Installing on Android Installing on FreeBSD Installing on Linux Installing on MacOS Installing on Windows IntermediateUpload JavaApps Job processing (cookbook) Job processing (introduction) Job replication JobEst JobIn JobIntro JobKeywords JobPinning JobPrioritization JobReplication JobSched JobSizeMatching JobStage JobStatus JobSubmission JobTemplates KeySetup LammpsRemote LdapSupport Linux file permissions Linux DEB and RPM support Linux installer LocalityNew LocalityScheduling Locating stolen computers LogExtension LogRotate LowLatency MacBacktrace MacBuild MacDeveloper MacDeveloperProjects Maintain your BOINC project MakeProject ManagerImpl ManagerMenus MasterUrl MediaWiki MemoryManagement Missing Linux shared libraries MpiApps MultiHost MultiSize MultiUser MultiUserPriority MysqlConfig Network related problems NetworkApps NonCpuIntensive Notifications OpenCL Applications OpenCL CPU applications OpenId OpenclCpu OptionsApi OrgGrid OtherProjectDocs PMC_Minutes PMC_Minutes_2017_12_15 PMC_Minutes_2018_01_10 PageTemplates PasswordHash PayPalDonations Per user file sandbox PerAppCredit PersFileXfer PhpDb PhysicalFileManagement PlanClassFunc PortalFeatures PowerManagement Preferences PreferencesXml Prefs2 PrefsImpl PrefsOverride PrefsPresets PrefsReference PrefsReference_Time PrefsRemodel PrefsUnification PrepareLinuxBuildMachine Process_proposals ProfileScreen ProjectConfigFile ProjectDaemons ProjectDefaults ProjectGovernance ProjectLaunch ProjectMain ProjectNews ProjectNotices ProjectOptions ProjectPapers ProjectPlan ProjectSecurity ProjectSelect ProjectSkin ProjectSpecificPrefs ProjectSponsors ProjectTasks ProofOfOwnership Proposal_ProjectSimpleAccountCreation ProtectionFromSpam Proxy servers ProxyServer PyMw PythonAppDev PythonApps PythonFramework PythonMw PythonMysql QuickStart RecentChanges Reduce_usage_of_authenticator Reduce_usage_of_authenticator_implementation ReleaseNotes RemoteInputFiles RemoteJob RemoteJobs RemoteLogs RemoteOutputFiles RemoteOverview Reporting client bugs ResearchProjects RightToErasure RpcAuth RpcPolicy RpcProtocol RpmSpec Running Linux apps on BOINC RuntimeEstimation SandBox SandboxUser SchedMatch Scientist interface ScreensaverEnhancements ScreensaverLogic SecureHttp SecurityIssues SendFile Server release notes Server trouble‐shooting ServerComponents ServerDirs ServerIntro ServerSecurity ServerStatus ServerTestInstructions ServerUpdates Simple view Simple attach usage SimpleAttach SingleJob SingleJobImpl SkinExamples SoftwareAddon SoftwareDevelopment SoftwarePrereqsUnix SoftwareTesting SolarisClient SolrIntegration Source code map SourceCode SourceCodeGit SourceCodeGit_Commands SourceCodeGit_Windows SourceCodeGit_WindowsKeygen SourceCodeGit_WorkFlow SourceCodeSvn Sporadic Applications Standard assimilators Standard validators StartTool Starting BOINC on boot (Unix) StatsXml StatusApi StolenComputers Stop or start BOINC daemon after boot StripChart StyleSheets SuperHost TeamDiscussion TeamImport Teams TemplateImages TermsOfUse The BOINC out of box experience The BOINC test drive ToolUpgrade Tools for MacOS TranslateIntro TranslateProject Translate_Coordination TranslationSystem TreeThreader TrickleApi TrickleImpl TrickleMessages TroubleshootClient TroubleshootClient_New Troubleshooting Tutorial_BOINCApplicationDevelopmentLifecycle Tutorial_DeployingVMApplications UnixClientPackage UnixProjectPackage UpdateVersions UploadStatistics Usage rules User manual UserJobs UserOptInConsent Using BOINC with modem, ISDN and VPN connections UsingSvn ValidationLowLevel Validators in C Validators in scripting languages Validators VboxApps Vboxwrapper release notes VersionDiff VersionHistory VersionPathSorter VirtualBox Plan VirtualBox VirtualCampusSupercomputerCenter VirtualMachines Virtualbox Shared Directories VmApps VmCompatibility VmServer Volunteer VolunteerComputing VolunteerDataArchival VolunteerRecruit VolunteerStorage WSL apps WatchDog Weak account key WebCache WebConfig WebForum WebResources WebRpc WebSubmit WebTemplateProposal WhyUseBoinc WikiTodo WinMulticore WindowsIssues WordPressInt WorkDistribution WorkFetchMaxConcurrent WorkGeneration WorkShop07 WorkShop07_BoincGrid WorkShop07_BoincSched WorkShop07_InterpretedApps WorkShop07_PubBoincOne WorkShop07_PubBoincTwo WorkShop07_SecurityGroup WorkShop07_SimplifyApp WorkShop07_Summary WorkShop07_VirtualMachines WorkShop07_WebCode WorkShop08 WorkShop08_WorkshopProceedings WorkShop09 WorkShop09_BatchSched WorkShop09_InterprocComm WorkShop09_ScientistUsability WorkShop09_UserIssues WorkShop09_VmApps WorkShop10 WorkShop10_VmApps WorkShop10_VolunteerIssues WorkShop11 WorkShop11_HackFest WorkShop11_HackFest_Android WorkShop11_MultiUser WorkShop12 WorkShop12_WorkshopSummary WorkShop13 WorkShop13_HackfestNotes WorkShop14 WorkShop18 WorkShop19 Worker release notes WorldWideLexicon Wrapper release notes WrapperApp XaddTool XmlFormat XmlNotes XmlStats test_RunningBoinc
1 Development_Workflow
Vitalii Koshura edited this page 2023-04-11 02:47:32 +02:00
Table of Contents

Development Workflow

The purpose of a development workflow is to make sure that the BOINC platform produces high quality code that solves the problems of its users. As such, the development workflow needs to have checkpoints to allow for the review and discussion of the following questions:

  • Should this item be implemented?
  • How should this item be implemented?
  • Has this item been implemented correctly and is it ready for release?

It is important to note that for the purposes of this workflow, anyone who is submitting a proposal for a change or contributing code is considered a 'contributor'. Even if that person is on the PMC or is a committer, they cannot take the actions of a committer with respect to their own proposals or code changes. This ensures that every feature and piece of code contributed to the project has a least two people who have looked at it. This is a standard practice which improves design and code quality and reduces the chances of bugs and significant flaws making it into the software.

Code produced via this process is expected to be largely free of defects and should be available as a nightly build.

1. Proposed Changes

Code changes are made because somebody has a problem that cannot be solved with the current version of this software. This could be because the software is doing something wrong (a bug report) or this could be because the software does not yet do something that somebody needs it to do (feature request).

These changes are documented using issues on github. A good issue will clearly define the problem that needs to be solved and how the software is not currently solving that problem. In the case of a bug report, this will include instructions on how to reproduce the issue. In the case of a feature request, it will detail the capabilities that are required in order to solve the stated problem.

A design may or may not be needed for the proposed change. If you are not sure of your approach, or if the change is medium to large sized, especially if it changes the behavior of the application, then you should do a design so that it can be reviewed when it is still easy to make changes. If you proceed without doing a design, you run the risk of having to re-do significant portions of your change should your approach or design be rejected during code review.

Key elements of a design are:

  • Details about changes in how users interact with the application
  • Details about changes in the behavior of the application and if any defaults will change
  • Description of the application changes (this can consist of anything from interaction and class diagrams to pseudocode )
  • Database changes
  • Steps that users of the software need to do in order to use or tune a new feature

1.1 Change Review

Once an issue is defined and created, anyone can review and comment on the issue. In particular, committers are expected to review the issue and make sure that the problem statement is clear. Committers also need to follow the consensus voting process and determine if the issue should be implemented or not. In the event that no voting is done on an issue, the issue remains open until a committer either votes yes or vetoes the issue.

Reviews are expected to examine two things:

  • Is the problem that requires a change clearly explained?
  • Is the bug reported or change requested something that should be implemented?
  • If this change does not have a design, is that a reasonable decision?
  • If provided, does the proposed design implement the change effectively and in an easily maintainable way?
  • If provided, does the proposed design describe the impacts to existing users of the software (server or client)?

1.2 Prioritization

If a change is approved, the issue should be "ready to implement" and should be added to the project board for its respective area (https://github.com/BOINC/boinc/projects). Committers are expected to also prioritize issues and have a small collection of the highest priority issues in the To-Do column of the different project boards. This makes it easy for developers to find work that needs to be done and also helps with facilitation of the overall development process.

2. Implementation

All development is done using feature branches as defined in GitHub Flow. BOINC uses the Fork and Pull Model for development (background on this approach can be read here). Once you have created your fork, set it up locally, and created a feature branch, then you can begin coding. When you are finished with development you can create a pull request for review.

Make sure to review the Definition_of_Done_for_Feature_Branches before starting work so that you are familiar with the expectations of your work.

If you wish to get some early feedback on your changes, then you can create a pull request with the text WIP at the start of the title. This indicates to reviewers that you are inviting others to look at your code, but that it should not be merged. Once you are ready for final review and merge into master, then you can remove the WIP prefix.

Once the code has been approved it is merged into the master branch.

2.1 Code Review

Once a pull request has been created for the implementation of an issue, anyone can review and comment on the changes. Committers need to follow consensus voting and determine if the code change is accepted. Committers should use the Expectations_of_Code_Review** **as a guide to conducting the review.

Home