Requirements, workflow and governance guidelines and definitions #56
Conversation
|
Given the lack of comprehensive regression testing, should we create a nightly branch where new features go first and then merge nightly to community on a monthly basis? This would give an opportunity for early adopters to help find bugs and leave the community branch as something which should be useable |
I agree on the sentiment that we need a quality control mechanism between Pull requests and releases. My suggestion would be to make a Discussion item we can vote on to switch from "community" to "develop" branch we (CI in the future) generate beta builds from after every merge. After the beta has been tested for some time and deemed stable we make a community release. Once we agreed on the switch we can update the contributors guide to reflect the new branch name. |
I know I said "yet" but I do wonder if we could ever hope to achieve a full regression test given how much interoperability is at play in how the deluge is used. Maybe what's needed for now is some common use scenario UAT rather than regression testing. Just thinking aloud here. |
|
@FWIW - I just ran into some of these concerns with the simplest of changes - see #53. I suggest that we come up with some high-level classifiers so it's easier to see how/where the impacts might be for devs, tester, users, feature merges etc So start by flagging PRs (and eventually feature branches) by their impacts on each of: |
|
Regarding regression testing I also don't believe we will ever get to that point but we should strive for it. Everytime somone touches the code it should get better in that area, optimally including test facilities. Once we have clear expectations we can put it in the requirements. Regarding flagging I will draft another paragraph where we describe things we would like to see done as well but can not mandate such as:
At the same time we can also work a little bit on a PR template, seems like a good idea |
…nce. Ownership is not complete yet.
…geFirmware into feature/communityWorkflow
PaulFreund
changed the title
|
Ready to merge :) |
As a foreword, please read this (draft) PR as being written with the best intentions. I don't want to overreach any boundarys or step on anyones toes, I want to give a starting point for discussion that is free to change in any dimension according to our needs.
Target is to give the greatest amount of people possible the chance to contribute to the project while knowing how their contributions will be handled while making sure we give the users of the community firmware a great experience with new features and stable performance.
Regarding governance the idea is to define the rules and workflow on how it can be handled in this PR and let our project management write down the actual governance and persons in the CODEOWNERS file so it is automatically taken into account in GitHubs PR system.
EDIT: I decided to remove the Ownership section from GOVERNANCE.md for now and leave it for someone else to add it.
Pull request #59 should follow this Pull request as it implements a mechanism fore the proposed requirement of runtime feature settings