Hi
I have a proposition for AUR package builds. Currently, if a package goes out of date, it can be flagged so but we need the maintainer to update it. So, if a non-maintainer wants to send the update the package build, (s)he will need to create a new package. My proposition is to have a git based system where a package's related files can be maintained. So, the following benefits can be targeted: - to update a package build, one does not need to copy the old one and create a new package; sending a PR will suffice - the maintainer model can be improved. A core set of maintainers or an active and trusted set of maintainers can review such PRs if the maintainer is not available. - even if no reviewer is available, the modified package build can be released as non-approved one and users will still be able to use the package build.
I would like to know thoughts about this proposition.
Regards, Amitav
On Mon, Nov 06, 2017 at 07:25:04PM -0800, Amitav Mohanty via aur-general wrote:
Hi
Hello
I have a proposition for AUR package builds. Currently, if a package goes out of date, it can be flagged so but we need the maintainer to update it.
Makes sense so far.
So, if a non-maintainer wants to send the update the package build, (s)he will need to create a new package. [...]
What? Why not just post a link to a patch/diff on the package?
[...] My proposition is to have a git based system where a package's related files can be maintained.
The AUR /is/ currently git-based?
[...] So, the following benefits can be targeted:
- to update a package build, one does not need to copy the old one and
create a new package; sending a PR will suffice
Again, what is wrong with posting a link to a patch or diff in the package's comments
- the maintainer model can be improved. A core set of maintainers or an
active and trusted set of maintainers can review such PRs if the maintainer is not available.
Packages can have more than one maintainer on the AUR. If a package is ditched for so long that intervention is needed for a package to be taken off the maintainer and given to someone else who is willing to maintain it, then this is what the Trusted Users are for.
- even if no reviewer is available, the modified package build can be
released as non-approved one and users will still be able to use the package build.
This comes inherently with the user-submitted diff/patch in the comments, as is currently the "approved" behaviour.
I would like to know thoughts about this proposition.
Regards, Amitav
Thanks, David
On Mon, 6 Nov 2017 19:25:04 -0800 Amitav Mohanty via aur-general aur-general@archlinux.org wrote:
Hi
I have a proposition for AUR package builds. Currently, if a package goes out of date, it can be flagged so but we need the maintainer to update it. So, if a non-maintainer wants to send the update the package build, (s)he will need to create a new package. My proposition is to have a git based system where a package's related files can be maintained.
It's already git based.
So, the following benefits can be targeted:
- to update a package build, one does not need to copy the old one and
create a new package; sending a PR will suffice
You can already do PRs, just use email.
- the maintainer model can be improved. A core set of maintainers or an
active and trusted set of maintainers can review such PRs if the maintainer is not available.
There is already co-maintainers.
- even if no reviewer is available, the modified package build can be
released as non-approved one and users will still be able to use the package build.
That sounds like chaos.
I would like to know thoughts about this proposition.
Regards, Amitav
Hi
To the suggestion of using links to diff/patch and using email or comments, my only counter-argument is that how would you organize them. I am sure we all have seen multiple versions of packages in AUR, e.g. version X.Y.Z and version "abc-git" to separate stable versus latest. Those cases can be handled using git branches without requiring separate AUR packages.
I understand that I am used to a model of organizing code that probably does not make sense here. Just seeking opinion.
Regards, Amitav
On Mon, Nov 6, 2017 at 7:45 PM, Doug Newgard scimmia@archlinux.org wrote:
On Mon, 6 Nov 2017 19:25:04 -0800 Amitav Mohanty via aur-general aur-general@archlinux.org wrote:
Hi
I have a proposition for AUR package builds. Currently, if a package goes out of date, it can be flagged so but we need the maintainer to update
it.
So, if a non-maintainer wants to send the update the package build, (s)he will need to create a new package. My proposition is to have a git based system where a package's related files can be maintained.
It's already git based.
So, the following benefits can be targeted:
- to update a package build, one does not need to copy the old one and
create a new package; sending a PR will suffice
You can already do PRs, just use email.
- the maintainer model can be improved. A core set of maintainers or an
active and trusted set of maintainers can review such PRs if the
maintainer
is not available.
There is already co-maintainers.
- even if no reviewer is available, the modified package build can be
released as non-approved one and users will still be able to use the package build.
That sounds like chaos.
I would like to know thoughts about this proposition.
Regards, Amitav
On Mon, 6 Nov 2017 20:08:00 -0800 Amitav Mohanty via aur-general aur-general@archlinux.org wrote:
Hi
To the suggestion of using links to diff/patch and using email or comments, my only counter-argument is that how would you organize them. I am sure we all have seen multiple versions of packages in AUR, e.g. version X.Y.Z and version "abc-git" to separate stable versus latest. Those cases can be handled using git branches without requiring separate AUR packages.
I understand that I am used to a model of organizing code that probably does not make sense here. Just seeking opinion.
Regards, Amitav
Diff/patch through email is not the same as a PR. See the linux kernel to see how PRs are actually handled with git. Github is not git.
Recommended reading material:
https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/
aur-general@lists.archlinux.org