@ntrel et al,

Well in the past I would have loudly complained about things being merged without testing by someone other than the author because I used Geany most of the day most days, and simply couldn't afford instability.

But my day to day needs have changed and I have had to move away from Geany as it simply does not provide the functionality I need any more. So I am no longer regularly testing anything without specifically starting Geany and that may cause delays in doing so, as I posted on a @kugel- PR.

So that means I am also less concerned if Geany breaks, but, as I said somewhere, all of us miss stuff when testing our own because we know how its meant to work, other people try silly things and break it, and so its important that things get third party testing, especially as the project has no effort or process available for verifying stability at release time. So I am still concerned about everybody merging their own without checking and testing.

On the other hand, you are right that currently non-controversial PRs do tend to sit for a long time because nobody other than the author is interested in them, and so nobody tests them.

So the project needs to come to some solution.

To get the ball rolling I suggest that if, within a reasonable period, say two weeks, nobody objects or says to wait, and none of the usual contributors explicitly suggests third party testing or changes are needed, then PRs that don't make big changes should be allowed to be merged by their authors (or if they are external PRs by a sponsor with merge rights).

As you suggested, for bigger PRs, in particular that change behaviour without any option to turn them off, two explicit approvals are needed (and silence isn't approval) and third party testing is also needed. If they can be turned off (plugins or options) then only one approval, and testing that it doesn't break anything if its turned off, should be enough.

My reasoning for this is that developers often think their way is the best and only sensible way for the application to work, without appreciating other user points of view. So if changes are going to be forced on everyone, and in particular if they break workflows, they need to meet a higher bar than ones that can be turned off. That is why I have been constantly requesting options to turn off changes that make significant alterations to workflows. Default to on or off is a case by case decision.

And I strongly emphasise that testing doesn't have to be Geany developers, anybody that wants to should be encouraged to test changes.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.