On Sat, Dec 10, 2016 at 9:12 AM, Marek Marczykowski-Górecki <[email protected]> wrote: >> The purpose of the github PRs here would be to improve the workflow of >> a maintainer telling the world "Hey, here's a set of complete and >> locally-tested changes, please review." with two goals: >> 1) Help ensure things get reviewed in a timely fashion and don't get >> forgotten about. >> 2) Provide a clear default way to provide feedback in the case of >> unacceptable changes. > > Indeed, especially the second point makes very much sense. I think we > should require such PR to be fast-forward, to avoid conflict resolution > (or unintended interactions of changes, even without conflicts).
Perhaps it goes without saying, but for me a main reason to require fast-forwards is it enforces your already-reviewed signed-tag to be an ancestor commit of the proposed changes, which means incremental reviewing is meaningful. Otherwise you would need to perform a larger audit each time, which wastes much time and effort. > Ok, I agree. But I still think another organisation makes sense. Mostly > for two reasons: > - badge for the author of such tool > - different (less strict) rules for repository naming scheme Makes sense. However, I still wonder about whether the maintainer having direct (not via PR) push access is a desired property. I can see no reason for it other than a "sense of ownership" over ones code, which does not really mean much since everything must be reviewed before packages are built/signed/uploaded anyway, so the maintainer does not have the final say regardless. > This is the workflow we started in this repository and probably will > implement in others too (especially using PR, then pushing to -staging to > always go through automated tests). Another practice used by many > open-source projects it to route all the patches through the mailing > list. But I find github more convenient, plus it preserve signed tags + > commits... I like this idea very much. Sometimes I find myself prematurely opening pull-requests just to trigger CI, then force-pushing several would-be-v1, -v2 patchsets to the comparing branch shortly after. This is non-ideal IMO. > Previous workflow was to push to personal repository first (in many > cases directly to master branch) and push to qubesos org after changes > being reviewed. This is why historically code in my github account was > fresher than in qubesos org. Works too, but minus CI. Local testing is great, but I'm not gonna kick off a full ISO build on my laptop for every trivial patch, and occasionally things have unforeseen impacts elsewhere in the tree. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_DNvd%2BxuM8zr0j5RXv2r_w2n0g7PZsp9VHmT30mYJJBCg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
