-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Dec 10, 2016 at 09:35:33AM -0500, Jean-Philippe Ouellet wrote: > 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.
A `git diff` could be used to avoid this, but still it makes much sense to have it always fast-forward. > > 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. Being member of the organization does not imply write access to the repository. I agree this somehow makes the separate organization a bit weird, but those two points above still holds. > > 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. You know, you can push a branch, wait for Travis and only then open PR ;) This require just signing up to Travis yourself (and enabling it for particular repository). > > 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. Actually not all tests can be run in Travis. There is no running Xen instance, so it does not replace local testing. In practice we call full test run from time to time (for example just before pushing packages to current-testing repository, or just after it). The full test run takes several hours, often more than 24... We have a partial infrastructure to plug the full test run into -staging workflow automatically, it is isn't finished yet. So for now, it is triggered manually. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYTBhIAAoJENuP0xzK19csjUYIAJfS1dvZDbtRFBGoCxNOiJUN EyHfGIDf64Dq7CVAYdl86USi/y4eEZL81/4WKlxjz6GEbQA1m8VhrBh+4lQI35ZK GDwSvT038V6N/7Nz4yJPn9X3He8XSxI4jvd92gFfZaQBTnQx3hQFl+Dfkt9eAT4N 3IHUFoqqQbcOndKa17WvfVDK0JdqxV/8v9JG6y/U4qZ8zR4hPKH+OsMOuakW91Jp JsU7w8iaP8X/QrY7UcMBykQbFzw/U+ZfU+AEdTMKDCP0ZXnr/pHRlkN0B7fdZOg5 S4dg4Ar3ApqCh9XDNEqXVuC6Xo/9mQixL0v00bQarl6YHKE/28wbSQRiaA4myuE= =DS6x -----END PGP SIGNATURE----- -- 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/20161210145920.GM16264%40mail-itl. For more options, visit https://groups.google.com/d/optout.
