You are not logged in.
Hi,
If i create a merge request on gitlab bug tracker
1) should i add updated SRCINFO and PKGBUILD as well or just the critical commits?
2) i should not squash multiple commits myself. It will be done by the maintainer himself?
Last edited by Maniaxx (2024-07-06 21:03:56)
sys2064
Offline
I'm no pro nor heavy user of colab projects - but from I got from the few PRs I made and the even fewer which got accepted:
1) only fix one issue at a time - if you want to fix multiple issues open multiple PRs
reason: sometimes a PR can break stuff - if one PR contains multiple changes it's very hard to figure out what the acutal problematic change is
2) use comments as needed: code should usually "speak for itself" - if you need comments either the code is bad or there's a general lack of proper documentation - both should be fixed first before thinking about comments in source
3) be specific: if you see the need for some code changed be most specific why you see the change required
if it's a security fix and the exploit is not yet public known such details should be shared non-public to the dev to point out what's the flaw and why the fix is required
anything else should be part of the commit note
4) as the name says: it's a request - with the maintainer to check and approve it - it's up to you to decide if its worth your time and effort and what to put into it - the worst you can get is a reject without any note
Offline
This is a specific example:
https://gitlab.archlinux.org/archlinux/ … /3/commits
If i explore through several merge requests people seem not to do that. I'm not sure where i've got this from.
sys2064
Offline
https://wiki.archlinux.org/title/Genera … e_requests
Do not make changes to release related variables (pkgver, pkgrel, epoch): Merge requests should be units of changes rather than units of releases. The decision to release changes should be left in the hands of Package Maintainers.
Offline
Thanks. Missed that. I was on the 'bug reporting guidelines' only.
So it should be left untouched.
sys2064
Offline
You can update .SRCINFO to keep it in sync with your changes to the PKGBUILD, even in the same commit. The guidelines say you should not update release-related variables (in either of those files).
Offline
even in the same commit.
The Gitlab GUI (edit file) seems to always create a separate commit per edited file. The merger/maintainer can squash them on merging though if I understand it correctly.
I would prefer that way over cloning locally.
sys2064
Offline