Mailing List Archive

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

On Tue, 2020-08-18 at 15:36 +0000, 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

On Tue, Aug 18, 2020 at 11:48 AM Micha? Górny <mgorny@gentoo.org> wrote:
>
> On Tue, 2020-08-18 at 15:36 +0000, 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?

On Tue, Aug 18, 2020 at 8:05 AM Joonas Niilola <juippis@gentoo.org> 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/juippis@gentoo.org
>
> you can see a tab called "pull requests" there,
> https://packages.gentoo.org/maintainer/juippis@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.

On Tue, 2020-08-18 at 11:58 -0400, Mike Gilbert wrote:
> On Tue, Aug 18, 2020 at 11:48 AM Micha? Górny <mgorny@gentoo.org> wrote:
> > On Tue, 2020-08-18 at 15:36 +0000, 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

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/proaudio@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/proaudio@gentoo.org/bugs) which
seems to be missing some bugs as my list with "Assignee:
proaudio@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/juippis@gentoo.org
>
> you can see a tab called "pull requests" there,
>   https://packages.gentoo.org/maintainer/juippis@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
>
>

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/proaudio@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/proaudio@gentoo.org/bugs)
> which seems to be missing some bugs as my list with "Assignee:
> proaudio@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

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

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

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/proaudio@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/proaudio@gentoo.org/bugs)
>> which seems to be missing some bugs as my list with "Assignee:
>> proaudio@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 ;)
can't we have a bug tracker for this webapp? i think it's so useful that
it would deserve such a space :-)
> -- juippis

fordfrog

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

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 <mgorny@gentoo.org>
> > wrote:
> > > On Tue, 2020-08-18 at 15:36 +0000, 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.

>>>>> On Tue, 18 Aug 2020, Micha? Górny wrote:

> On Tue, 2020-08-18 at 15:36 +0000, 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

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

On 8/18/20 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/juippis@gentoo.org
>
> you can see a tab called "pull requests" there,
>   https://packages.gentoo.org/maintainer/juippis@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
>
>


Personally, I'd rather see a generic package maintenance tags.
"Accepts Github PRs"
"Accepts any contribution freely"
"Accepts project member contributions"
"Accepts contributions after contact/N Week timeout"
"Accepts no contributions"
or similar

Most of my packages fall within projects that keep synchronized with
external overlays/repositories and it drives me absolutely bonkers when
someone edits my packages (contrary to Gentoo official policy) without
speaking to me first so that I can ensure the changes are replicated.
So I'd welcome something that pushes further standardization of that
preexisting policy. Allow devs to specify when they are OK with
relaxing the existing policy, but keep it in force for those who want
and/or need it.

--
Thanks,

Adam Feldman
Gentoo Developer
NP-Hardass@gentoo.org
0x671C52F118F89C67

On 2020-08-18 14:05, Joonas Niilola wrote:

> 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 like this idea. While I do use GitHub PRs and GitLab MRs in the course
of my work I personally have found them more trouble than they are worth
as far as Gentoo is concerned - and GitHub in particular I am not a huge
fan of.

--
MS