Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Michał Górny wrote: > Read: it's important to slap users to satisfy developer's wannabes. LOL! Michał, you managed to squeeze both misrepresentation and ad hominem into so few words. Please take care. Anyway, you missed my point: It's important that (the project) developers set accurate expectations for contributors. Michał Górny wrote: > If user puts effort to make a good contribution, the developer > shouldn't be rejecting it to 'demonstrate other methods'. Here you confused a couple of different things, maybe you didn't understand what I meant. "demonstrate other methods" is something that the Gentoo project does by enabling choice also in the development process. This is made possible by self-determined infrastructure in parallel with GitHub. This is important and valuable both philosophically and practically, and I think Gentoo should be both proud of it and also proud to present it. "rejecting" would require an action, that's not the case; we're talking about simply documenting which developers don't use GitHub, so that contributions can know the right place to go. Then there's your opinion that developers should do all that contributors want. I disagree with that for two reasons: 1. it doesn't scale, and 2. developers too work in their spare time, and choose how they do so > This is the horrible attitude that kills the project. In general I think that individual lack of reflection is a far greater problem than developer workflow choices within community projects. For Gentoo specifically I think that a fairly small number of structures are the main reason to rather spend time on other projects - that's off topic for this thread though. Assuming good faith and asking for clarification when something seems negative is always a good idea. //Peter
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
> On Tue, 18 Aug 2020, Michał Górny wrote: > On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote: >> I think this is a very good feature. >> >> If I ever do become a proper Gentoo developer I will certainly not >> spend any time on anything to do with GitHub, and in my current >> position of occasional contributor I don't either. The workflow >> imposed by GitHub isn't good and it's important to demonstrate other >> methods. > Read: it's important to slap users to satisfy developer's wannabes. Of course anyone can use nonfree software or platforms (like Github) to do their work, but we cannot force them to do so, neither users nor developers. So, if a developer rejects Github for moral or philosophical reasons then we must accept the fact. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On Tue, 2020-08-18 at 18:06 +0200, Michał Górny wrote: > On Tue, 2020-08-18 at 11:58 -0400, Mike Gilbert wrote: > > On Tue, Aug 18, 2020 at 11:48 AM Michał Górny > > wrote: > > > On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote: > > > > Joonas Niilola wrote: > > > > > some of you may already have seen the new packages.gentoo.org > > > > > page, > > > > > https://packages.gentoo.org/ > > > > > > > > I had not seen that - that's wonderful! > > > > > > > > I would just request that /packages/ is removed from the start > > > > of > > > > package URLs. I understand how this makes request routing more > > > > complicated, but I consider it a significant usability > > > > improvement. > > > > > > > > > > > > ..anyway: > > > > > > > > > I'm suggesting of adding a new metadata flag to our Wiki's > > > > > User:/Project: page which then prints a message to this page > > > > > saying > > > > > whether the maintainer (be it project or user), "accepts" or > > > > > "deals > > > > > with" Github contributions. The wording can be a bit better, > > > > > but it'd be > > > > > there to **notify** our **contributors** whether their time > > > > > and effort > > > > > will most likely be wasted making a pull request for this > > > > > particular > > > > > maintainer. > > > > > > > > I think this is a very good feature. > > > > > > > > If I ever do become a proper Gentoo developer I will certainly > > > > not spend > > > > any time on anything to do with GitHub, and in my current > > > > position of > > > > occasional contributor I don't either. The workflow imposed by > > > > GitHub > > > > isn't good and it's important to demonstrate other methods. > > > > > > > > > > Read: it's important to slap users to satisfy developer's > > > wannabes. > > > > This sentence makes no sense, but it seems to be saying something > > rude. > > > > Would you like to clarify? > > > > If user puts effort to make a good contribution, the developer > shouldn't > be rejecting it to 'demonstrate other methods'. This is the horrible > attitude that kills the project. > Have to second this. "I'm not a Gentoo developer, but if I were, I wouldn't use it" - what sort of ultimate put-down is that, because someone seems to have an axe to grind.
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On 8/18/20 8:52 PM, Miroslav Šulc wrote: > is there a way or would it be possible to get notified on pull > requests that are relevant to me? though i get notifications from > github, i get tens to hundreds daily and most of them are irrelevant > to me so searching for those few that are related to me is really > inefficient for me. You should receive them for any team you're part of? But as you said, sometimes they're in the hundreds per day. The only way I'm aware to sort them is by configuring your e-mail client's filtering. If you use GMail for your devpost, it's pretty easy. > if a maintainer is mia and does not accept pull requests, there is > much lower chance to get his/her package fixed/bumped. i personally do > not hesitate to step up and fix a package though i do not maintain it > if the bug bothers me and i see no activity from the maintainer. and > if i can find a pull request for such a package, it could save me some > time. so what i had on my mind is a situation with maintainer mia + > no-pull-requests-policy -> worse situation than maintainer mia and > yes-pull-requests-policy. If you see a devaway permitting that, sure go ahead. Otherwise it's not different to how things are now - wait for maintainer timeout, get their approval in IRC or by e-mail, or ask QA to do it / permission to do it. >> I believe toggling the flag per-package basis is too much. Sure I can >> see the situation where this happens, but the point here is to enable >> communication between contributor and maintainer. If you're not >> accepting PRs to some packages, you can close the PR informing >> contributor about it. It'd be better than leave it to rot for months, >> years, with no answer. > > you know much better than me how pull requests are processed and what > benefits and problems those bring. for me pull requests are generally > good thing but sometimes when i see the quality of them, basic issues > not resolved like the missing signed-off-by, contributors not > responding and disappearing... i'm just not sure this whole effort > will bring some advancement, but i trust your opinion on that as you > are the one spending a lot of time on github. anyway, when it comes to > this feature mentioned above, if it might be of any use, it can work > as an override for package where it is specified and otherwise be > undefined. in the end the contributor will be interested in whether > the package accepts pull requests, not a dev or project. > If you see faults in the PR, please let the contributor know. It's their only way to improve. Yeah not everyone reads all docs, but if you work with them, the quality gets better. There is a reason for every PR. Nobody will get flooded by them, since there shouldn't be a continuous reason to push them right? And if there is, maybe it implies something about the current state of maintenance... And the package inherits "acceptance state" of its maintainers which'd then be visible, per-package. > can't we have a bug tracker for this webapp? i think it's so useful > that it would deserve such a space :-) You're asking for a tracker, just letting everyone know there is a way to file/list bugs for packages.gentoo.org: New bug -> Websites -> Packages. Arzano should decide whether we track this or not. But for sure a bug about this needs to be created, unless other people shoot the idea down. -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Dne 18. 08. 20 v 19:06 Joonas Niilola napsal(a): On 8/18/20 7:30 PM, Miroslav Šulc wrote: hi, how would be handled cases where you and me agreed that you will take care of pull requests on behalf of sound@ and proaudio@? and what if a package is maintained by multiple maintainers or even some maintainers and a project, each with a different preference? how that would be solved to not bring in some confusion? and how about maintainers that are not gentoo devs? and what if there are packages that have a maintainer that is mia but has the no-accept policy set and some other dev would like to fix a package that has an annoying bug (using a pull request by a contributor) as the reported maintainer is mia, or a contributor might want to maintain the package? and what if a maintainer wants pull requests just for some packages and not for others? and what if a pull request is referenced from a bug at bugzilla but the maintainer does not accept pull requests? One idea for implementation would be to enable the flag in your User: page. Then if any member in a project has it enabled, the project would have it set positive as well. However it doesn't necessary directly translate to you you merging personal PRs -> you merging all of your project PRs. I also thought the project could count Yes's and No's from their members, printing something like "This project has a 66 % probability of handling Github PRs". But that'd look silly. is there a way or would it be possible to get notified on pull requests that are relevant to me? though i get notifications from github, i get tens to hundreds daily and most of them are irrelevant to me so searching for those few that are related to me is really inefficient for me. ... If the current maintainer is MIA, it doesn't change anything from our current situation. At least it doesn't make it any worse than it is, but has advantages for those available. I'm sorry I may have not understood your question correctly here? We can claim maintainer timeout, or ask QA to deal with these situations. It wouldn't change. if a maintainer is mia and does not accept pull requests, there is much lower chance to get his/her package fixed/bumped. i personally do not hesitate to step up and fix a package though i do not maintain it if the bug bothers me and i see no activity from the maintainer. and if i can find a pull request for such a package, it could save me some time. so what i had on my mind is a situation with maintainer mia + no-pull-requests-policy -> worse situation than maintainer mia and yes-pull-requests-policy. I believe toggling the flag per-package basis is too much. Sure I can see the situation where this happens, but the point here is to enable communication between contributor and maintainer. If you're not accepting PRs to some packages, you can close the PR informing contributor about it. It'd be better than leave it to rot for months, years, with no answer. you know much better than me how pull requests are processed and what benefits and problems those bring. for me pull requests are generally good thing but sometimes when i see the quality of them, basic issues not resolved like the missing signed-off-by, contributors not responding and disappearing... i'm just not sure this whole effort will bring some advancement, but i trust your opinion on that as you are the one spending a lot of time on github. anyway, when it comes to this feature mentioned above, if it might be of any use, it can work as an override for package where it is specified and otherwise be undefined. in the end the contributor will be interested in whether the package accepts pull requests, not a dev or project. Your last question wouldn't be any different from a current situation, however other devs/users can inform the contributor that this maintainer can't/doesn't use Github, and the PR can be closed. I'm mostly looking for communication here. I believe being rejected is better than being ignored. The bug can be dealt separately from Github PR. i agree with you, making a contribution and being ignored is demotivating. There's a tool that tells what PRs reference a closed bug, (ie contribution was made, but not accepted/noticed, and the bug was closed regardless of it) https://github.com/wimmuskee/gengee sorry for this flood of questions but atm it brings confusion to me :-) from my point of view and personal preference, i appreciate pull requests from contributors if those are of a decent quality, but for me it's hard to easily find out the relevant pull requests. with the new packages.gentoo.org it might be easier in the future but i'm not sure yet how reliable it is atm as for example the list of outdated packages for proaudio@ (https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated) does not seem to be updated or i misunderstood something. the same goes for the list of bugs (https://packages.gentoo.org/maintainer/proau...@gentoo.org/bugs) which seems
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Dne 18. 08. 20 v 19:10 Joonas Niilola napsal(a): On 8/18/20 8:06 PM, Joonas Niilola wrote: So I think it's just simplest to enable it per-user per-project basis. We can all edit Project: pages, toggling the flag. If you're willing to look and merge sound@ PRs, you enable it for Sound project. However this might cause a problem when a member who enabled the flag leaves the project, or gets retired. But that's relatively easy to keep a track of. As for non-dev maintainers, they **require** @gentoo.org person/project to proxy for them. It'd be a start to mirror the project/dev option, since they'd be the one committing for non-dev maintainers anyway. Also non-dev maintainers can have their own wiki pages to toggle this. However I'm not aware if the linking is as simple as with @gentoo.org metadata info. Forgot to add, if you have say 1 person and 2 projects assigned as maintainers, where 1 does look for Github PRs and 2 does not, it'd still be flagged as "Yes". Or maybe the majority here wins? i think the approach "one yes beats all no-es" makes more sense as there still is one person who can handle the pull request. up to that, the yes might come from a main maintainer and the no from inactive ones... or the opposite... so i guess it might be better to take it as a hint rather than a rule as the outcome might be various. -- juippis fordfrog
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On 8/18/20 8:06 PM, Joonas Niilola wrote: > > So I think it's just simplest to enable it per-user per-project basis. > We can all edit Project: pages, toggling the flag. If you're willing to > look and merge sound@ PRs, you enable it for Sound project. However this > might cause a problem when a member who enabled the flag leaves the > project, or gets retired. But that's relatively easy to keep a track of. > > As for non-dev maintainers, they **require** @gentoo.org person/project > to proxy for them. It'd be a start to mirror the project/dev option, > since they'd be the one committing for non-dev maintainers anyway. Also > non-dev maintainers can have their own wiki pages to toggle this. > However I'm not aware if the linking is as simple as with @gentoo.org > metadata info. > Forgot to add, if you have say 1 person and 2 projects assigned as maintainers, where 1 does look for Github PRs and 2 does not, it'd still be flagged as "Yes". Or maybe the majority here wins? -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On 8/18/20 7:30 PM, Miroslav Šulc wrote: > hi, > > how would be handled cases where you and me agreed that you will take > care of pull requests on behalf of sound@ and proaudio@? and what if a > package is maintained by multiple maintainers or even some maintainers > and a project, each with a different preference? how that would be > solved to not bring in some confusion? and how about maintainers that > are not gentoo devs? and what if there are packages that have a > maintainer that is mia but has the no-accept policy set and some other > dev would like to fix a package that has an annoying bug (using a pull > request by a contributor) as the reported maintainer is mia, or a > contributor might want to maintain the package? and what if a > maintainer wants pull requests just for some packages and not for > others? and what if a pull request is referenced from a bug at > bugzilla but the maintainer does not accept pull requests? One idea for implementation would be to enable the flag in your User: page. Then if any member in a project has it enabled, the project would have it set positive as well. However it doesn't necessary directly translate to you you merging personal PRs -> you merging all of your project PRs. I also thought the project could count Yes's and No's from their members, printing something like "This project has a 66 % probability of handling Github PRs". But that'd look silly. So I think it's just simplest to enable it per-user per-project basis. We can all edit Project: pages, toggling the flag. If you're willing to look and merge sound@ PRs, you enable it for Sound project. However this might cause a problem when a member who enabled the flag leaves the project, or gets retired. But that's relatively easy to keep a track of. As for non-dev maintainers, they **require** @gentoo.org person/project to proxy for them. It'd be a start to mirror the project/dev option, since they'd be the one committing for non-dev maintainers anyway. Also non-dev maintainers can have their own wiki pages to toggle this. However I'm not aware if the linking is as simple as with @gentoo.org metadata info. If the current maintainer is MIA, it doesn't change anything from our current situation. At least it doesn't make it any worse than it is, but has advantages for those available. I'm sorry I may have not understood your question correctly here? We can claim maintainer timeout, or ask QA to deal with these situations. It wouldn't change. I believe toggling the flag per-package basis is too much. Sure I can see the situation where this happens, but the point here is to enable communication between contributor and maintainer. If you're not accepting PRs to some packages, you can close the PR informing contributor about it. It'd be better than leave it to rot for months, years, with no answer. Your last question wouldn't be any different from a current situation, however other devs/users can inform the contributor that this maintainer can't/doesn't use Github, and the PR can be closed. I'm mostly looking for communication here. I believe being rejected is better than being ignored. The bug can be dealt separately from Github PR. There's a tool that tells what PRs reference a closed bug, (ie contribution was made, but not accepted/noticed, and the bug was closed regardless of it) https://github.com/wimmuskee/gengee > > sorry for this flood of questions but atm it brings confusion to me > :-) from my point of view and personal preference, i appreciate pull > requests from contributors if those are of a decent quality, but for > me it's hard to easily find out the relevant pull requests. with the > new packages.gentoo.org it might be easier in the future but i'm not > sure yet how reliable it is atm as for example the list of outdated > packages for proaudio@ > (https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated) > does not seem to be updated or i misunderstood something. the same > goes for the list of bugs > (https://packages.gentoo.org/maintainer/proau...@gentoo.org/bugs) > which seems to be missing some bugs as my list with "Assignee: > proau...@gentoo.org" has 96 bugs atm compared to 76 bugs at > packages.gentoo.org. > > fordfrog Please talk to arzano about this. Although I'm pretty sure he will read this thread ;) -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
hi, how would be handled cases where you and me agreed that you will take care of pull requests on behalf of sound@ and proaudio@? and what if a package is maintained by multiple maintainers or even some maintainers and a project, each with a different preference? how that would be solved to not bring in some confusion? and how about maintainers that are not gentoo devs? and what if there are packages that have a maintainer that is mia but has the no-accept policy set and some other dev would like to fix a package that has an annoying bug (using a pull request by a contributor) as the reported maintainer is mia, or a contributor might want to maintain the package? and what if a maintainer wants pull requests just for some packages and not for others? and what if a pull request is referenced from a bug at bugzilla but the maintainer does not accept pull requests? sorry for this flood of questions but atm it brings confusion to me :-) from my point of view and personal preference, i appreciate pull requests from contributors if those are of a decent quality, but for me it's hard to easily find out the relevant pull requests. with the new packages.gentoo.org it might be easier in the future but i'm not sure yet how reliable it is atm as for example the list of outdated packages for proaudio@ (https://packages.gentoo.org/maintainer/proau...@gentoo.org/outdated) does not seem to be updated or i misunderstood something. the same goes for the list of bugs (https://packages.gentoo.org/maintainer/proau...@gentoo.org/bugs) which seems to be missing some bugs as my list with "Assignee: proau...@gentoo.org" has 96 bugs atm compared to 76 bugs at packages.gentoo.org. fordfrog Dne 18. 08. 20 v 14:05 Joonas Niilola napsal(a): Hey, some of you may already have seen the new packages.gentoo.org page, https://packages.gentoo.org/ and the new maintainer pages in it, https://packages.gentoo.org/maintainers If you open a maintainer page, https://packages.gentoo.org/maintainer/juip...@gentoo.org you can see a tab called "pull requests" there, https://packages.gentoo.org/maintainer/juip...@gentoo.org/pull-requests with description saying: "If you also like to help the Gentoo project, you can consider sending a Pull Request via GitHub. Before doing so, you might want to take a look at the wiki page." I'm suggesting of adding a new metadata flag to our Wiki's User:/Project: page which then prints a message to this page saying whether the maintainer (be it project or user), "accepts" or "deals with" Github contributions. The wording can be a bit better, but it'd be there to **notify** our **contributors** whether their time and effort will most likely be wasted making a pull request for this particular maintainer. This note would then be displayed in every package the maintainer is assigned to, https://packages.gentoo.org/packages/media-libs/rlottie/pull-requests I'd imagine a simple switch in Wiki could do it. No need to add anything to ::gentoo repo. The switch can be visible in User:/Project: page, but it doesn't have to. Unspecified metadata flag would print something like "This maintainer hasn't specified whether they handle Github pull requests. If you wish to help using Github, please also open a bug prior to that and link your pull request commit to that bug (add link to glep-66 here)". Or just default it to "No." Note that the bug text could always be displayed nevertheless, since that is still the main channel to communicate with maintainers. It's undeniable we get a lot of pull requests and unfortunate that many are left without any attention to rot. https://github.com/gentoo/gentoo/pulls I think this would serve both parties - devs and contributors, with little to no cost. -- juippis
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On Tue, 2020-08-18 at 11:58 -0400, Mike Gilbert wrote: > On Tue, Aug 18, 2020 at 11:48 AM Michał Górny wrote: > > On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote: > > > Joonas Niilola wrote: > > > > some of you may already have seen the new packages.gentoo.org page, > > > > https://packages.gentoo.org/ > > > > > > I had not seen that - that's wonderful! > > > > > > I would just request that /packages/ is removed from the start of > > > package URLs. I understand how this makes request routing more > > > complicated, but I consider it a significant usability improvement. > > > > > > > > > ..anyway: > > > > > > > I'm suggesting of adding a new metadata flag to our Wiki's > > > > User:/Project: page which then prints a message to this page saying > > > > whether the maintainer (be it project or user), "accepts" or "deals > > > > with" Github contributions. The wording can be a bit better, but it'd be > > > > there to **notify** our **contributors** whether their time and effort > > > > will most likely be wasted making a pull request for this particular > > > > maintainer. > > > > > > I think this is a very good feature. > > > > > > If I ever do become a proper Gentoo developer I will certainly not spend > > > any time on anything to do with GitHub, and in my current position of > > > occasional contributor I don't either. The workflow imposed by GitHub > > > isn't good and it's important to demonstrate other methods. > > > > > > > Read: it's important to slap users to satisfy developer's wannabes. > > This sentence makes no sense, but it seems to be saying something rude. > > Would you like to clarify? > If user puts effort to make a good contribution, the developer shouldn't be rejecting it to 'demonstrate other methods'. This is the horrible attitude that kills the project. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On Tue, Aug 18, 2020 at 8:05 AM Joonas Niilola wrote: > > Hey, > > some of you may already have seen the new packages.gentoo.org page, > https://packages.gentoo.org/ > > and the new maintainer pages in it, > https://packages.gentoo.org/maintainers > > If you open a maintainer page, > https://packages.gentoo.org/maintainer/juip...@gentoo.org > > you can see a tab called "pull requests" there, > https://packages.gentoo.org/maintainer/juip...@gentoo.org/pull-requests > > with description saying: > "If you also like to help the Gentoo project, you can consider sending a > Pull Request via GitHub. > Before doing so, you might want to take a look at the wiki page." > > I'm suggesting of adding a new metadata flag to our Wiki's > User:/Project: page which then prints a message to this page saying > whether the maintainer (be it project or user), "accepts" or "deals > with" Github contributions. The wording can be a bit better, but it'd be > there to **notify** our **contributors** whether their time and effort > will most likely be wasted making a pull request for this particular > maintainer. > > This note would then be displayed in every package the maintainer is > assigned to, > https://packages.gentoo.org/packages/media-libs/rlottie/pull-requests > > I'd imagine a simple switch in Wiki could do it. No need to add anything > to ::gentoo repo. The switch can be visible in User:/Project: page, but > it doesn't have to. Unspecified metadata flag would print something like > "This maintainer hasn't specified whether they handle Github pull > requests. If you wish to help using Github, please also open a bug prior > to that and link your pull request commit to that bug (add link to > glep-66 here)". Or just default it to "No." > > Note that the bug text could always be displayed nevertheless, since > that is still the main channel to communicate with maintainers. > > It's undeniable we get a lot of pull requests and unfortunate that many > are left without any attention to rot. > https://github.com/gentoo/gentoo/pulls > > I think this would serve both parties - devs and contributors, with > little to no cost. Your proposal makes sense to me.
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On Tue, Aug 18, 2020 at 11:48 AM Michał Górny wrote: > > On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote: > > Joonas Niilola wrote: > > > some of you may already have seen the new packages.gentoo.org page, > > > https://packages.gentoo.org/ > > > > I had not seen that - that's wonderful! > > > > I would just request that /packages/ is removed from the start of > > package URLs. I understand how this makes request routing more > > complicated, but I consider it a significant usability improvement. > > > > > > ..anyway: > > > > > I'm suggesting of adding a new metadata flag to our Wiki's > > > User:/Project: page which then prints a message to this page saying > > > whether the maintainer (be it project or user), "accepts" or "deals > > > with" Github contributions. The wording can be a bit better, but it'd be > > > there to **notify** our **contributors** whether their time and effort > > > will most likely be wasted making a pull request for this particular > > > maintainer. > > > > I think this is a very good feature. > > > > If I ever do become a proper Gentoo developer I will certainly not spend > > any time on anything to do with GitHub, and in my current position of > > occasional contributor I don't either. The workflow imposed by GitHub > > isn't good and it's important to demonstrate other methods. > > > > Read: it's important to slap users to satisfy developer's wannabes. This sentence makes no sense, but it seems to be saying something rude. Would you like to clarify?
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On Tue, 2020-08-18 at 15:36 +, Peter Stuge wrote: > Joonas Niilola wrote: > > some of you may already have seen the new packages.gentoo.org page, > > https://packages.gentoo.org/ > > I had not seen that - that's wonderful! > > I would just request that /packages/ is removed from the start of > package URLs. I understand how this makes request routing more > complicated, but I consider it a significant usability improvement. > > > ..anyway: > > > I'm suggesting of adding a new metadata flag to our Wiki's > > User:/Project: page which then prints a message to this page saying > > whether the maintainer (be it project or user), "accepts" or "deals > > with" Github contributions. The wording can be a bit better, but it'd be > > there to **notify** our **contributors** whether their time and effort > > will most likely be wasted making a pull request for this particular > > maintainer. > > I think this is a very good feature. > > If I ever do become a proper Gentoo developer I will certainly not spend > any time on anything to do with GitHub, and in my current position of > occasional contributor I don't either. The workflow imposed by GitHub > isn't good and it's important to demonstrate other methods. > Read: it's important to slap users to satisfy developer's wannabes. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Joonas Niilola wrote: > some of you may already have seen the new packages.gentoo.org page, > https://packages.gentoo.org/ I had not seen that - that's wonderful! I would just request that /packages/ is removed from the start of package URLs. I understand how this makes request routing more complicated, but I consider it a significant usability improvement. ..anyway: > I'm suggesting of adding a new metadata flag to our Wiki's > User:/Project: page which then prints a message to this page saying > whether the maintainer (be it project or user), "accepts" or "deals > with" Github contributions. The wording can be a bit better, but it'd be > there to **notify** our **contributors** whether their time and effort > will most likely be wasted making a pull request for this particular > maintainer. I think this is a very good feature. If I ever do become a proper Gentoo developer I will certainly not spend any time on anything to do with GitHub, and in my current position of occasional contributor I don't either. The workflow imposed by GitHub isn't good and it's important to demonstrate other methods. //Peter
[gentoo-dev] RFC: New "Accept Github contributions" metadata flag
Hey, some of you may already have seen the new packages.gentoo.org page, https://packages.gentoo.org/ and the new maintainer pages in it, https://packages.gentoo.org/maintainers If you open a maintainer page, https://packages.gentoo.org/maintainer/juip...@gentoo.org you can see a tab called "pull requests" there, https://packages.gentoo.org/maintainer/juip...@gentoo.org/pull-requests with description saying: "If you also like to help the Gentoo project, you can consider sending a Pull Request via GitHub. Before doing so, you might want to take a look at the wiki page." I'm suggesting of adding a new metadata flag to our Wiki's User:/Project: page which then prints a message to this page saying whether the maintainer (be it project or user), "accepts" or "deals with" Github contributions. The wording can be a bit better, but it'd be there to **notify** our **contributors** whether their time and effort will most likely be wasted making a pull request for this particular maintainer. This note would then be displayed in every package the maintainer is assigned to, https://packages.gentoo.org/packages/media-libs/rlottie/pull-requests I'd imagine a simple switch in Wiki could do it. No need to add anything to ::gentoo repo. The switch can be visible in User:/Project: page, but it doesn't have to. Unspecified metadata flag would print something like "This maintainer hasn't specified whether they handle Github pull requests. If you wish to help using Github, please also open a bug prior to that and link your pull request commit to that bug (add link to glep-66 here)". Or just default it to "No." Note that the bug text could always be displayed nevertheless, since that is still the main channel to communicate with maintainers. It's undeniable we get a lot of pull requests and unfortunate that many are left without any attention to rot. https://github.com/gentoo/gentoo/pulls I think this would serve both parties - devs and contributors, with little to no cost. -- juippis signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-python/pyblake2, dev-python/pysha3
# Michał Górny (2020-08-18) # Backports of hash algorithms that are built-in since Python 3.6. # No reverse dependencies left. # Removal in 30 days. Bug #737712. dev-python/pyblake2 dev-python/pysha3 -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
