[QGIS-Developer] [Qgis-psc] Official PSC call on pull request policies
Nyall Dawson
nyall.dawson at gmail.com
Tue Feb 27 15:08:35 PST 2024
On Wed, 28 Feb 2024 at 08:49, Marco Bernasocchi <marco at qgis.org> wrote:
> Thanks Nyall, thanks Sandro,
>
> Just a quick question, is the
> -is:draft
> Filter an option at all? I guess it does not reduce the n/r by default but
> could help?
>
> https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft
>
That hides them, yes. But the bigger question remains as to what value
having unfinished work in the queue has in the first place. In my opinion
if it's not ready for review and merge, it's not actually a "pull REQUEST"
and just doesn't belong there. In my proposal there's already mention that
short term pull requests can be permitted for the express purpose of
performing a CI test run, so after that why is there a need to allow
unfinished work to remain in the queue?
If the need is for others to see and be exposed to unfinished work, then
let's look at an extreme example: I have some 100's of branches of work in
an unfinished state on my QGIS fork, from proof of concept experiments
through to things which I just don't think work well enough to be
submitted. Should all of those draft/wip branches be pull requests in the
QGIS repo? 🤣 If the justification for allowing draft/wip requests is that
others can see what's being/been done, then I guess the same argument would
apply to all of this.
Nyall
>
>
> Cheers Marco
>
>
> On Tue, 27 Feb 2024, 23:09 Sandro Santilli via QGIS-PSC, <
> qgis-psc at lists.osgeo.org> wrote:
>
>> Thanks Nyall for raising this thread!
>>
>> On Mon, Feb 26, 2024 at 09:21:05AM +1000, Nyall Dawson wrote:
>>
>> > Policy #1: https://github.com/qgis/QGIS/pull/56062
>> >
>> > In short, Sandro proposes that the pull request queue be an open queue
>> > of ALL work happening everywhere, in any state of completeness. Pull
>> > requests are permitted for semi-complete work, and for long-term
>> > (including multi-year) projects which are not yet ready for review or
>> > merge. The justification here is that having this work open in the
>> > queue makes it widely visible and so that other developers are aware
>> > of ongoing work across the community.
>>
>> I would add that allowing long-term PRs also serves the purpose of making
>> it easy for contributors to check the state of their work against CI as
>> running tests locally is so hard that I dubt anyone is doing that.
>>
>> > Policy #2: https://github.com/qgis/QGIS/pull/56523
>>
>> [...]
>>
>> > When the queue includes work which is not ready for review, then it
>> > becomes very tricky to work out the actual status of pull requests and
>> > which ones should be focused on during review time.
>>
>> I think this is a limitation of the software used to get the list
>> of pull requests needing focus, and should be threated as such.
>> If github makes it hard to filter on "PR state" we could use a label
>> to do that.
>>
>> --strk;
>> _______________________________________________
>> QGIS-PSC mailing list
>> QGIS-PSC at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20240228/815fe8c8/attachment.htm>
More information about the QGIS-Developer
mailing list