Hi, On 30/03/2020 07:55, Gert Doering wrote: >> Not sure now what would be the best approach forward. Picking the commit >> contents from a rebased icsopenvpn branch would be one way (I can provide >> commitish references I reviewed, if needed). Another approach is for Arne to >> resend rebased patches to ML. > > Well, our current defined process is "we review, test and merge *exactly* > what is on the list". > > So, ACKing list patches based on "some other tree" is doubtful at best > (for initial review and discussion, fine, but for the final ACK?), and > "have something on the list and then merge something else" is also > clearly violating the "everything must be transparent, and no code changes > compared to what is archived in a public archive". >
I totally agree with Gert here. > > We can change this, of course, but even then it needs to be fairly > transparent what was exactly was ACKed and merged (and what, if anything, > was changed between ACK and merge). > IMHO we should not change the process - git repos can go, while emails remains in archives so it's possible to see the whole flow later in the future. IMHO the best course of action would be: 1. David reviewing the git branch 2. David privatelly talking to Arne and eventually saying "all patches look good! I consider them ready for merging" 3. Arne sends the rebased patches to the mailing list 4. David checks that the patches are still the same he reviewed 5. David ACKs the patches on the mailing list in a public way. I think this process would allow us to be super transparent and would allow everybody to chime in until the very last minute. The other upside is that point 1 and 2 can be repeated as much as needed until David is satisfied, without spamming the ml. my 2 cents. Cheers, -- Antonio Quartulli _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
