Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refinement of development/release process #17

Open
brevilo opened this issue Sep 7, 2018 · 0 comments
Open

Refinement of development/release process #17

brevilo opened this issue Sep 7, 2018 · 0 comments

Comments

@brevilo
Copy link

brevilo commented 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.

  • 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/release merge-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...

@brevilo brevilo changed the title Refinement of development process Refinement of development/release process Sep 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant