You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As promised in #13 I'd like to add a few comments and questions regarding the latest revision of the development process that could eventually lead to a more refined process description.
BOINC Flow
Feature or bugfix branches: why "majority" instead of "all"? What's the rest and why isn't it supposed to be contributed that way?
Bugfix branches: how do you apply such a bugfix to multiple release branches in a coherent way that avoids code creep? That of course assumes that there are multiple maintained release branches to begin with. Is that the case? Right now I can't find a definition of how we want to handle release branch maintenance. If there is only and exactly one maintained release branch at any given moment, then we should really simplify things and have bugfix branches based on the release branch to be fixed, not its master/releasemerge-base which calls for mistakes.
Bugfix example: (the previous bullet notwithstanding) it should be clarified here that the bugfix branch must be based on the merge-base of master and the release branch in question, not just "created off of master" as that might lead people to think to just branch off master's HEAD, which would be wrong.
Client release process
Bugs in release branch: are we willing to release known bugs? What kind of bugs are these? How is the process for determining whether to delay a release (fix the bug) or release with a known bug? Can there ever be any pressure (good reason) to release with known bugs? I presume that the known bug is part of a new feature, otherwise it would just be a bug fix. If that's the case, however, I'd argue that the feature should be reverted and moved to the next release, instead of releasing it with known bugs.
Tagging release builds: the documents lacks a description of how release builds get (git) tagged. Topic to cover should include when and how (signed or not?) to do that and how those tagged releases should be used (eg. binaries must always be built from tagged commits only).
Let's open the discussion...
The text was updated successfully, but these errors were encountered:
brevilo
changed the title
Refinement of development process
Refinement of development/release process
Sep 7, 2018
As promised in #13 I'd like to add a few comments and questions regarding the latest revision of the development process that could eventually lead to a more refined process description.
master
/release
merge-base
which calls for mistakes.merge-base
ofmaster
and therelease
branch in question, not just "created off ofmaster
" as that might lead people to think to just branch offmaster
'sHEAD
, which would be wrong.Let's open the discussion...
The text was updated successfully, but these errors were encountered: