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 <scim...@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 >