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