Consider 'pull request' github model in AUR

mkaczanowski · 2016-03-02 02:31:38

Hey,
recently I wanted to merge a diff to AUR package. The owner was not responsive, so I left the patch in comments.

I am wondering if someone was considering to implement model of pull requests (like on github). Instead of leaving patch in comment I could do pull request.
Benefits:
1. Pull requests leaves trace who is doing what (useful to see that someone else is working on the same thing, etc)
2. Easier to navigate - diffs in comments are not very readable. Also you should be able to comment on pull request
3. "Request forget" - make a pull request and remove local directory. Your changes are already submitted, if owner decides to merge you don't need to do 'git push ...' anymore

I would find it very useful.

What do you think? How much work it could take?

jasonwryan · 2016-03-02 02:32:47

Moving to AUR Issues...

Also, pretty sure this was discussed on the AUR ML around the time of aur4.

eschwartz · 2016-03-02 02:57:57

You can pastebin the .patch and link it in the comments...

As for me, I keep all my PKGBUILDS on GitHub: https://github.com/eli-schwartz/pkgbuilds
People can submit pull requests there, if they want.

I don't see why the AUR needs to duplicate that functionality.

mkaczanowski · 2016-03-02 03:11:25

@Eschwartz your solution is somewhere in the middle and I like this approach in a few cases. For instance:
https://aur.archlinux.org/packages/qbittorrent-git/

By going to that page I can't determine whether you have github repository for that package or not. I would find it useful to see some url like 'Maintained on github', so other people will know.

But the other case is when package owner is not using github? In that case we go to my origin question.

As for me the model you have (with this extra piece of information on the page) is sufficient, but then I still hit the problem when someone does not have github or anything like that.

Last edited by mkaczanowski (2016-03-02 03:11:38)

mkaczanowski · 2016-03-02 03:12:30

I will revert one thing. There is an information about what 'source repo' but there is no info about your repository

Last edited by mkaczanowski (2016-03-02 03:13:40)

eschwartz · 2016-03-02 03:52:32

And I intend to add the line "# All my PKGBUILDs are managed at https://github.com/eli-schwartz/pkgbuilds" to each PKGBUILD, as I update them. A couple of them have that line already.

mkaczanowski · 2016-03-02 04:12:56

Good approach, but I still think it should be visible on website. Below "Upstream URL".
I feel like this is natural place to look for such information.

I guess this will require changes in mksrcinfo and pkgbase.
@Eschwartz do you know who can I loop in a thread to make it happen? (of course I may bake up diff, but I would like to discuss it more broadly)

eschwartz · 2016-03-02 04:27:07

Perhaps raise it as an issue on the aur-dev mailing list. And/or file an enhancement request to aurweb on the bugtracker.

I wouldn't mind an account setting for "upstream source of PKGBUILDs", which could e.g. get displayed on all your packages.

fukawi2 · 2016-03-02 05:48:59

The aur-general mail list is the appropriate place to discuss this. This thread will not get the eyeball attention it needs on the forums.

Awebb · 2016-03-02 08:43:08

The pull request mechanic would require the AUR to accept Github style forks for every package from every user. There already is a "Manage Co-Maintainers" button. If you really need to fix a package and can't wait for the current maintainer to reply to you, request the package to be orphaned and adopt it.

mkaczanowski · 2016-03-02 09:56:25

Mail list sounds good.

@Awebb As far as I know if you're not co-maintainer you can't pull request anything.
I did requested package as orphaned and sent email to owner to add me as co-maintainer but I didn't get any response.

My impression is that current workflow is slowing me down. Normally I would do fork and pull request. Then if I see or someone else sees that pull requests are hanging without answer and those are valuable; the co-owner could be added or owner would be changed.

As @Eschwartz mentioned, duplicating functionalities is not the best idea, but adding simple information in AUR that package is being developed on github or other alike sites is somewhat mitigating the issue.

Thanks for taking a voice in this thread

I value my time. Mailing owner + requesting orphan + taking over package + checking if someone else did some patches in comments etc. is IMHO much of overhead.
As I mentioned in my vision I would do pull request (whether I am co/maintainer or not) and leave it. If it gets merged cool if not then I can say 'Hey there are 3 pull requests hanging, those are important and I believe this is good ground to change owner'.

Fast and simple. If i

Lone_Wolf · 2016-03-02 14:17:17

Aur now has the option to pin comments.

That would be the perfect place for comments like :

pkgbuilds are alsa available here, unofficial binary repo here etc.

mkaczanowski · 2016-03-02 15:21:56

As for me 'comments' is not right place for this kind of information.
It should be in .SRCINFO imo

Alad · 2016-03-02 15:57:49

mkaczanowski wrote:

As for me 'comments' is not right place for this kind of information.
It should be in .SRCINFO imo

Adding it to SRCINFO implies adding it to PKGBUILD. IOW, you're asking to add fields for things that are irrelevant to pacman.

Everyone who uses AUR packages is required to read the PKGBUILD. That means a "# see repo foo" is in plain sight already.

Last edited by Alad (2016-03-02 15:58:46)

ugjka · 2016-03-02 16:10:32

I don't know much about git tbh but what about this? https://git-scm.com/docs/git-request-pull

eschwartz · 2016-03-02 16:27:43

mkaczanowski wrote:

As for me 'comments' is not right place for this kind of information.
It should be in .SRCINFO imo

As Alad said, that would require expanding the PKGBUILD syntax

And anyone who is going to make a patch or PR against a PKGBUILD has certainly read the PKGBUILD in order to edit it.
So a maintainer expressing in a comment the willingness to accept PRs, is AFAIAC a satisfactory way of dealing with things.

But once again, any serious discussion will need to take place on the aur-dev mailing list, where the people who are in charge of aurweb will see.
(Or pacman-dev, but I highly doubt you will get it standardized as a PKGBUILD variable.)

eschwartz · 2016-03-02 16:34:36

ugjka wrote:

I don't know much about git tbh but what about this? https://git-scm.com/docs/git-request-pull

That is a way of auto-generating a comment which describes a series of changes.
Pastebinning and linking the *.patch or *.diff or even github.com/*/*/commit/$sha1 does literally the same thing, but without the boilerplate AUR comment message -- thus requiring you to write a better comment.

Last edited by eschwartz (2016-03-02 16:35:00)

Awebb · 2016-03-02 21:02:09

The fallacy here is, that pull requests would not change the actual problem, an unresponsive maintainer.

eschwartz · 2016-03-02 21:10:30

Awebb wrote:

The fallacy here is, that pull requests would not change the actual problem, an unresponsive maintainer.

In theory, it would make it easier for people to see if there are proposed changes.

But I agree that isn't particularly useful, because there is not actually an urgent need for that, and especially because an unresponsive maintainer can and should be replaced.
And I assume the active maintainers check the comments to their packages -- as far as I am concerned, the purpose of leaving a comment pointing at my GitHub repo is purely for the sake of convenience.

Last edited by eschwartz (2016-03-02 21:11:21)

fukawi2 · 2016-03-02 21:43:08

Awebb wrote:

The fallacy here is, that pull requests would not change the actual problem, an unresponsive maintainer.

Correct. The valid solution here is to file an orphan request against the package to remove the unresponsive maintainer.

mkaczanowski · 2016-03-04 10:03:20

Yeah, I agree that PKGBUILD might not be the best place as this information is not relevant to pacman.
But yet I am not convinced that comment (even pinned) is good place for maintainer github/whatever url.

I still believe that this small piece of information should be visible on the aur package page in main section.

mkaczanowski · 2016-03-04 10:45:07

@Lone_Wolf how can you pin comment? I don't see it

Awebb · 2016-03-04 11:23:28

Eschwartz wrote:

Awebb wrote:
The fallacy here is, that pull requests would not change the actual problem, an unresponsive maintainer.
In theory, it would make it easier for people to see if there are proposed changes.

If you ignore ood flags and comments, why would you bother checking for pull requests?

michis · 2016-03-04 12:05:22

mkaczanowski wrote:

Yeah, I agree that PKGBUILD might not be the best place as this information is not relevant to pacman.
But yet I am not convinced that comment (even pinned) is good place for maintainer github/whatever url.
I still believe that this small piece of information should be visible on the aur package page in main section.

Keep in mind that not every maintainer holds his/her PKGBUILDs at a separate location (github, or whatever). It's not a must-have...

mkaczanowski · 2016-03-04 12:34:46

As @Eschwartz mentioned, duplicating functionalities is not the best idea, but adding simple information in AUR that package is being developed on github or other alike sites is somewhat mitigating the issue.

@michs Agree, thats why my original question was about making pull/requests as an default option. Addidg url of external repo to AUR page is just a mitigation of a problem.

Arch Linux

#1 2016-03-02 02:31:38

Consider 'pull request' github model in AUR

#2 2016-03-02 02:32:47

Re: Consider 'pull request' github model in AUR

#3 2016-03-02 02:57:57

Re: Consider 'pull request' github model in AUR

#4 2016-03-02 03:11:25

Re: Consider 'pull request' github model in AUR

#5 2016-03-02 03:12:30

Re: Consider 'pull request' github model in AUR

#6 2016-03-02 03:52:32

Re: Consider 'pull request' github model in AUR

#7 2016-03-02 04:12:56

Re: Consider 'pull request' github model in AUR

#8 2016-03-02 04:27:07

Re: Consider 'pull request' github model in AUR

#9 2016-03-02 05:48:59

Re: Consider 'pull request' github model in AUR

#10 2016-03-02 08:43:08

Re: Consider 'pull request' github model in AUR

#11 2016-03-02 09:56:25

Re: Consider 'pull request' github model in AUR

#12 2016-03-02 14:17:17

Re: Consider 'pull request' github model in AUR

#13 2016-03-02 15:21:56

Re: Consider 'pull request' github model in AUR

#14 2016-03-02 15:57:49

Re: Consider 'pull request' github model in AUR

#15 2016-03-02 16:10:32

Re: Consider 'pull request' github model in AUR

#16 2016-03-02 16:27:43

Re: Consider 'pull request' github model in AUR

#17 2016-03-02 16:34:36

Re: Consider 'pull request' github model in AUR

#18 2016-03-02 21:02:09

Re: Consider 'pull request' github model in AUR

#19 2016-03-02 21:10:30

Re: Consider 'pull request' github model in AUR

#20 2016-03-02 21:43:08

Re: Consider 'pull request' github model in AUR

#21 2016-03-04 10:03:20

Re: Consider 'pull request' github model in AUR

#22 2016-03-04 10:45:07

Re: Consider 'pull request' github model in AUR

#23 2016-03-04 11:23:28

Re: Consider 'pull request' github model in AUR

#24 2016-03-04 12:05:22

Re: Consider 'pull request' github model in AUR

#25 2016-03-04 12:34:46

Re: Consider 'pull request' github model in AUR

Board footer