[OpenWrt-Devel] improved handling of contributions [Was: Re: patches from 2018]
Petr Štetiar
ynezz at true.cz
Mon Oct 28 09:59:23 EDT 2019
Adrian Schmutzler <mail at adrianschmutzler.de> [2019-10-28 13:17:34]:
Hi,
> 1. Those where the submitter left track after (initial) feedback
> I would even choose a relatively short time span for that (e.g. one month).
so this probably means PRs with `needs changes` tag and defined inactivity,
right?
> 2. Those where there never was any feedback
> However, I do not think it's fair to just close an old submission without
> any developer (or others people's) feedback (category 2), just because
> nobody is interested in it.
And whats the point to keep them lingering on the GH forever? My feeling is,
that people are simply afraid to reject the PRs so they simply ignore them,
but in the end, net result is the same.
> I'd see this differently if the old submissions would do any harm, but since
> they are just lying around and making a list a little longer, it's not like
> they pose a big problem.
If we're talking about following GH PR filter:
is:pr is:open comments:0 updated:<2019-04-28 sort:created-asc
Then it yields following result:
kernel: add kmod-frame-vector https://github.com/openwrt/openwrt/pull/1518
kernel: build kmod-dma-buf properly if required https://github.com/openwrt/openwrt/pull/1519
Both PRs from the same author, almost 1 year old. I believe, that if some bot
would autoclose those (or at least marked those with `stale` label which would
mean autoclose in next 30 days without any activity) it might signal the
author, that there probably is more effort needed to make it merged.
> one could provide a standardized
> feedback that 1. patches do not apply anymore,
> This will remove inapplicable patches from the list,
this could (and should) be automated and it's not an issue I would say.
> 2. it seems to be that interest in the subject isn't there
what could be more explicit then no activity for > 6 months?
> and 3. that resubmission of a rebased patch is possible if the author wants
> that
indeed, but rebased patch (and additional work attached to that) wouldn't
necessarily mean, that it wouldn't linger in the patchwork for the following
year, until next pre-christmas cleanup.
> but reach out for those having invested time in an enhancement to OpenWrt
To me it seems, that it might make more sense to take a look around for
inspiration, how it's being handled in other FOSS projects and try to improve
current workflow.
This PW/GH/FS fragmentation still makes me crazy, but anyway just a quick
ideas for PW/GH, we could handle the aging of the contributions more gradualy,
like in more phases:
1. change patch status from 'New' to 'Needs Review / ACK' after 30 days of
inactivity
- on GH label=`needs reviewer`
2. change patch status from 'Needs Review / ACK' to 'Under Review' and assign
it randomly (to predefined set of volunteer commiters) after 60 days of
inactivity
- on GH label=`awaiting review`
3. change patch status from 'Under Review' to 'Needs Review / ACK' after 90 days
of inactivity
- on GH label=`stale` and remove the randomly assigned reviewer
4. change patch status from 'Needs Review / ACK' to 'Rejected' after 120 days
of inactivity, sending out some meaningful mail with a link to
exaplanation of the currently failed merging process on the wiki
- on GH close the PR
This way (backed up with some details on wiki page) it should hopefully make
more sense to the contributors.
-- ynezz
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list