-
-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[IMP] Search addons maintainers in other branches. Fix : #122 #183
[IMP] Search addons maintainers in other branches. Fix : #122 #183
Conversation
0512ef3
to
9751f9c
Compare
I think we should do this only for migration PRs, i.e. when the addon is not yet on the target branch. Otherwise, this may have security implications, because a maintainers on a branch may not be the same as on other branches. |
Good question I asked myself last night ! Well, in fact, when I adopt an addon, I adopt it most of the time "globally". = "I'd like to have the possibility to merge bugfixes, and backport of bugfixes in older version". Making a PR to add the key in the manifest file is a workflow that can be slow in some repo without a lot of reviewers, but force me to make a PR against all the branches the module is available will make the workflow slower. typical use case : I adopt a module in V12, (making a PR). The PR is merged, but in the meantime, the port of this module has been done for V14. I'm so not the maintainer of the V14 module and I have to make another PR to be set as maintainer. but maybe a V15 PR is pending ! and I'll have to make a third PR. Finally, when i'll make the port of the module in V16 (that is the next release I target) I'll not have the possibility to merge the PR.
Is it a real use case ? I mean : "module in V12 maintained by @sbidoul + module in V15 maintained by @legalsylvain"
So, After these nocturnal reflections, my point of view was:
|
Hello @sbidoul ! Do you keep your point of view ? I'd like to move forward with that PR. I can change the algorithm if it's a blocking point. Let me know ! |
Sorry I had lost track of this. I think you are right. If and when we have this kind of conflicts between maintainers in different branches, we can solve that by other means. So +1 with your approach. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, a couple of suggestions.
src/oca_github_bot/manifest.py
Outdated
url, allow_redirects=True, headers={"Cache-Control": "no-cache"} | ||
) | ||
if r.ok: | ||
manifest = ast.literal_eval(r.content.decode("utf-8")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: it might be better to add a parse_manifest(manifest: bytes)
function in manifest.py
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something like that ?
8d6f595
Co-authored-by: Stéphane Bidoul <[email protected]>
e763a31
to
99b7c2a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi @sbidoul. Thanks for your review. I accepted your 2 proposal.
another comment inline.
otherwise, LGTM.
src/oca_github_bot/manifest.py
Outdated
url, allow_redirects=True, headers={"Cache-Control": "no-cache"} | ||
) | ||
if r.ok: | ||
manifest = ast.literal_eval(r.content.decode("utf-8")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something like that ?
8d6f595
1aa47e3
to
744b57d
Compare
for more information, see https://pre-commit.ci
Next try : 744b57d ;-) |
👍 If it's ready for you I can deploy to the OCA server tomorrow. |
Yes ! ready from my part. when deploying don't forget to add Please ping me if troubles. |
Hi. did you deployed the feature ? Just to know if OCA/product-attribute#1083 (comment) is normal. |
No, it was a sunny week-end :) I'll do it in the next days. |
hum... Next week-end will be sunny also ! ;-) Let me know when it's done. regards. |
Hi @legalsylvain. It is deployed. I'll let you test and announce :) |
Hi @sbidoul. Seems to work : OCA/product-attribute#1083 (comment) Thanks ! |
Excellent. Thanks for the contrib! |
Can you also try merging something you are not allowed to ? |
@legalsylvain Hi, following 108c9ae#r83501261 , we would need to grant some users the ability to merge PRs only for a specific (old) version, as they have competence in that version and PSC members do not work anymore on that (old) version |
Hi @eLBati. Thanks for your message. However : I understand what you ask, but I dont understand the problem you try to fix. Thanks for your precisions. |
Hi there! There's no problem to fix. It's just a feature request. Someone volunteered to maintain a very old branch (8.0), but they have clearly stated they are not interested in moving on from that, and they're not going to contribute anything to more recent branches. We would like to grant them maintainer status for all modules in the 8.0 branch only. Currently, that would imply granting maintainer status for all modules in other branches too, something completely unnecessary (per their request). We feel that limiting permissions to the minimun required is best practice anyway. So we're wondering if there's a way to override the environtment variable Regarding #183 (comment) we don't need module granularity at all. Excluding maintainers specified in the 8.0 branch as a whole would be fine for us. We don't need extra complexity, just a way to override the |
Search for maintainers in all the branches, to make possible maintainer to merge migration PRs. (#122)
Note, it works also for the past. (If i'm declared as maintainers of a 12.0 module, I will also have the possibility to merge PR against 8.0 (for backport / fixes / etc...)
Deployment Note
Once deployed, you should update your
environment
file. if not, the feature will be simply anavailable.