[QGIS-Developer] [Qgis-psc] Official PSC call on pull request policies

Marco Bernasocchi marco at qgis.org
Tue Feb 27 16:43:36 PST 2024


Thanks for the clarification Nyall, as Andreas wrote we'll discuss it next
Tuesday at PSC and will get back to you short after.

Cheers Marco

On Wed, 28 Feb 2024, 00:07 Nyall Dawson, <nyall.dawson at gmail.com> wrote:

>
>
> 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/a92d7ee1/attachment-0001.htm>


More information about the QGIS-Developer mailing list