zimoun writes: > On Thu, 24 Nov 2022 at 08:40, Christopher Baines wrote: > >>> On Wed, 23 Nov 2022 at 10:49, Christopher Baines wrote: >>> >>>> +For a minority of changes, it can be appropriate to push them directly >>>> +without sending them for review. This includes both trivial changes >>>> +(e.g. fixing typos) but also reverting problomatic changes and >>> -^ >>>> +addressing regressions. > > To be sure you have not missed the typo here. :-) > > s/problomatic/problematic Thanks, I've fixed that locally now. >> Also, this guidance is very general, and I think it should be applicable >> to all changes. We already trust people with commit access to know what >> needs doing, I see this documentation as more about how, so I'd prefer >> not to try and put a list here. > > Yes, we trust people. But a public and explicit policy reinforces the > trust, IMHO. It also documents what commit access means. It is not > because people with commit access already know what they need doing that > all people know, I guess. I don't disagree that we should make the expectations about functionality and testing explicit, but I want to see that separate from the commit policy. >>> and I would keep the «two weeks» instead of the «one week except». >> >> My reason for changing this is that I think waiting two weeks after >> sending a simple patch is unreasonable. The value from the automated >> testing will come after one to two days, I just put a week to avoid >> changing it too much, but maybe the lower bound should be two days. > > Who is verifying the impact of a change? :-) Just a recent example to > fix the ideas. The same situation is happening more than often but not > that often neither. :-) ... > My point is: Considering leaf packages, yeah once submitted, the review > can be fast (couple of days) especially with the new QA. Considering > all the other packages, who is checking the impact of a change? > > Otherwise, we have again and again some broken packages. For sure, the > QA is helping *a lot* for improving! Well, on one hand, I understand > the willing to merge faster and, even I am not convinced that from two > weeks to one week would be detrimental. On the other hand, using Guix, > I replaced the pressure when running “apt-get upgrade” by an eternal > annoyance of broken packages popping here or there. This is going a bit off topic I think. In general, the direction I'm trying to move the policy in here is one where more changes get sent to guix-patches rather than getting pushed straight to the repository. Checking the impact of changes is important, but you can't do that with a policy on committing. If however people send changes to guix-patches prior to pushing, then there's at least a chance that some automatic "verifying/checking" can take place.