I've been thinking for a while about plugins, and how to continue them
when original authors move on. It's only natural that developers will
come and go, so we need to think about how to deal with this. We've got
a few examples of this now, and have had others in the past.
I'm playing with Salt in my spare time at the moment, with a view to
(maybe) taking on the foreman_salt plugin, since Stephen is no longer
working on it. However, it's only chance that I know this fact -
there's no easy way for an author to mark a plugin as "orphaned".
Some plugins are awaiting changes but the author hasn't responded
(yet!). Foreman_bootdisk has some open PRs at the moment that fall into
this category (PRs 42, 43 for example), and default_hostgroup has pen
issues (oops!). Presumably we need a way to ping authors and find out
if they're just AFK or have stepped away from the plugin entirely.
Some plugins are definitely abandoned. I recall Chris Pisano taking
over the foreman_banner plugin last year and struggling to get in touch
with the original author at all.
For context, Fedora does have a policy for this that makes some sense:
That's quite heavy, but some of the points make sense. So, do we need
to add something to our docs about this. My gut feeling is:
Yes, we do
Only applies to plugins in "theforeman" GitHub repo
We need to add extra maintainers to the Rubygems before the author
leaves - Chris had a real issue here. This could be a requirement of
getting aplugin packaged, for example.
We need to allow authors to "abandon" a plugin clearly (something
like how the Arch User Repository does it maybe?)
FWIW, the approach I arrived at for smart-proxy plugins:
Explain the original developer their options for hosting the plugin
(i.e. within Foreman github organization, and outside of it, and what
each option entails). The former implies that Foreman developers have
a say over technical matters that affect maintenance (for example test
coverage).
Should they choose to move their code into the Foreman
organization, ask them to grant a committer access to at least one of
the Foreman core developers, and rights to release gems.
Agree with them on commit and review process.
Cheers,
-d
···
On Tue, Jul 18, 2017 at 4:15 AM, Greg Sutcliffe wrote:
> Hi all,
>
> I've been thinking for a while about plugins, and how to continue them
> when original authors move on. It's only natural that developers will
> come and go, so we need to think about how to deal with this. We've got
> a few examples of this now, and have had others in the past.
>
> 1) I'm playing with Salt in my spare time at the moment, with a view to
> (maybe) taking on the foreman_salt plugin, since Stephen is no longer
> working on it. However, it's only chance that I know this fact -
> there's no easy way for an author to mark a plugin as "orphaned".
>
> 2) Some plugins are awaiting changes but the author hasn't responded
> (yet!). Foreman_bootdisk has some open PRs at the moment that fall into
> this category (PRs 42, 43 for example), and default_hostgroup has pen
> issues (oops!). Presumably we need a way to ping authors and find out
> if they're just AFK or have stepped away from the plugin entirely.
>
> 3) Some plugins are definitely abandoned. I recall Chris Pisano taking
> over the foreman_banner plugin last year and struggling to get in touch
> with the original author at all.
>
> For context, Fedora does have a policy for this that makes some sense:
>
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai
> ners
>
> That's quite heavy, but some of the points make sense. So, do we need
> to add something to our docs about this. My gut feeling is:
>
> * Yes, we do
> * Only applies to plugins in "theforeman" GitHub repo
> * We need to add extra maintainers to the Rubygems *before* the author
> leaves - Chris had a real issue here. This could be a requirement of
> getting aplugin packaged, for example.
> * We need to allow authors to "abandon" a plugin clearly (something
> like how the Arch User Repository does it maybe?)
>
> Thoughts?
> Greg
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
I honestly do not know the best way to go about this, I have limited
experience in this area, but it was a hassle to say the least when I wanted
to contribute to the foreman_banner plugin. I actually never ended up
taking it over. Basically the process was me forking, making changes,
opening a PR (pretty standard). Then after a few days trying to hunt down
the owner through MANY difference means of communication. By the end of it,
they would not transfer ownership of the project to me but rather merged my
PR and released a new Gem. I would assume that after that it basically went
back to being unmaintained. All in all I would say the entire process took
almost a month.
Again, I do not know the best way, or even a way to solve for this but I'll
take anything. I would have loved to take over that plugin and keep
developing upon it.
···
On Tuesday, July 18, 2017 at 7:15:26 AM UTC-4, Greg Sutcliffe wrote:
>
> Hi all,
>
> I've been thinking for a while about plugins, and how to continue them
> when original authors move on. It's only natural that developers will
> come and go, so we need to think about how to deal with this. We've got
> a few examples of this now, and have had others in the past.
>
> 1) I'm playing with Salt in my spare time at the moment, with a view to
> (maybe) taking on the foreman_salt plugin, since Stephen is no longer
> working on it. However, it's only chance that I know this fact -
> there's no easy way for an author to mark a plugin as "orphaned".
>
> 2) Some plugins are awaiting changes but the author hasn't responded
> (yet!). Foreman_bootdisk has some open PRs at the moment that fall into
> this category (PRs 42, 43 for example), and default_hostgroup has pen
> issues (oops!). Presumably we need a way to ping authors and find out
> if they're just AFK or have stepped away from the plugin entirely.
>
> 3) Some plugins are definitely abandoned. I recall Chris Pisano taking
> over the foreman_banner plugin last year and struggling to get in touch
> with the original author at all.
>
> For context, Fedora does have a policy for this that makes some sense:
>
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai
> ners
>
> That's quite heavy, but some of the points make sense. So, do we need
> to add something to our docs about this. My gut feeling is:
>
> * Yes, we do
> * Only applies to plugins in "theforeman" GitHub repo
> * We need to add extra maintainers to the Rubygems *before* the author
> leaves - Chris had a real issue here. This could be a requirement of
> getting aplugin packaged, for example.
> * We need to allow authors to "abandon" a plugin clearly (something
> like how the Arch User Repository does it maybe?)
>
> Thoughts?
> Greg
>
> Hi all,
>
> I've been thinking for a while about plugins, and how to continue them
> when original authors move on. It's only natural that developers will
> come and go, so we need to think about how to deal with this. We've got
> a few examples of this now, and have had others in the past.
>
> 1) I'm playing with Salt in my spare time at the moment, with a view to
> (maybe) taking on the foreman_salt plugin, since Stephen is no longer
> working on it. However, it's only chance that I know this fact -
> there's no easy way for an author to mark a plugin as "orphaned".
>
> 2) Some plugins are awaiting changes but the author hasn't responded
> (yet!). Foreman_bootdisk has some open PRs at the moment that fall into
> this category (PRs 42, 43 for example), and default_hostgroup has pen
> issues (oops!). Presumably we need a way to ping authors and find out
> if they're just AFK or have stepped away from the plugin entirely.
>
> 3) Some plugins are definitely abandoned. I recall Chris Pisano taking
> over the foreman_banner plugin last year and struggling to get in touch
> with the original author at all.
>
> For context, Fedora does have a policy for this that makes some sense:
>
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai
> ners
>
> That's quite heavy, but some of the points make sense. So, do we need
> to add something to our docs about this. My gut feeling is:
>
> * Yes, we do
> * Only applies to plugins in "theforeman" GitHub repo
> * We need to add extra maintainers to the Rubygems before the author
> leaves - Chris had a real issue here. This could be a requirement of
> getting aplugin packaged, for example.
+1 to this, I am stuck with foreman-docker where I want to give publish
access to Bastilian but I can't
> * We need to allow authors to "abandon" a plugin clearly (something
> like how the Arch User Repository does it maybe?)
I think marking this in a GitHub issue, README or somewhere like that
would be enough, not sure if we need anything more formal than that
(there are 1000s of packages in Fedora, only a few 10s of plugins?)
In general +1. I'm not sure if official policy changes anything, probably does
not do any harm either. It would be great if someone went over all plugins
under theforeman org on github, found projects with single owner and ask the
owner to extend the list. Or someone scritped a simple check so we would avoid
this situation in future. I think what Dmitri described is fair and should
become a common practice for new repos/gems in our org.
···
On úterý 18. července 2017 13:15:22 CEST Greg Sutcliffe wrote:
> Hi all,
>
> I've been thinking for a while about plugins, and how to continue them
> when original authors move on. It's only natural that developers will
> come and go, so we need to think about how to deal with this. We've got
> a few examples of this now, and have had others in the past.
>
> 1) I'm playing with Salt in my spare time at the moment, with a view to
> (maybe) taking on the foreman_salt plugin, since Stephen is no longer
> working on it. However, it's only chance that I know this fact -
> there's no easy way for an author to mark a plugin as "orphaned".
>
> 2) Some plugins are awaiting changes but the author hasn't responded
> (yet!). Foreman_bootdisk has some open PRs at the moment that fall into
> this category (PRs 42, 43 for example), and default_hostgroup has pen
> issues (oops!). Presumably we need a way to ping authors and find out
> if they're just AFK or have stepped away from the plugin entirely.
>
> 3) Some plugins are definitely abandoned. I recall Chris Pisano taking
> over the foreman_banner plugin last year and struggling to get in touch
> with the original author at all.
>
> For context, Fedora does have a policy for this that makes some sense:
>
> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai
> ners
>
> That's quite heavy, but some of the points make sense. So, do we need
> to add something to our docs about this. My gut feeling is:
>
> * Yes, we do
> * Only applies to plugins in "theforeman" GitHub repo
> * We need to add extra maintainers to the Rubygems *before* the author
> leaves - Chris had a real issue here. This could be a requirement of
> getting aplugin packaged, for example.
> * We need to allow authors to "abandon" a plugin clearly (something
> like how the Arch User Repository does it maybe?)
>
> Thoughts?
> Greg
I think this covers all we discussed, but perhaps it's on the owners
(myself, Eric, Ohad) to be more proactive about enforcing it when
migrating plugins to our Org on GitHub? I think is basically what
Dmitri is saying.
Also, given how buried this is, I'll make the PR about moving it to the
website… if/when it's merged we can update the wiki.
···
On Wed, Jul 19, 2017 at 10:13:24AM +0200, Marek Hulán wrote:
>On úterý 18. července 2017 13:15:22 CEST Greg Sutcliffe wrote:
>> Hi all,
>>
>> I've been thinking for a while about plugins, and how to continue them
>> when original authors move on. It's only natural that developers will
>> come and go, so we need to think about how to deal with this. We've got
>> a few examples of this now, and have had others in the past.
>>
>> 1) I'm playing with Salt in my spare time at the moment, with a view to
>> (maybe) taking on the foreman_salt plugin, since Stephen is no longer
>> working on it. However, it's only chance that I know this fact -
>> there's no easy way for an author to mark a plugin as "orphaned".
>>
>> 2) Some plugins are awaiting changes but the author hasn't responded
>> (yet!). Foreman_bootdisk has some open PRs at the moment that fall into
>> this category (PRs 42, 43 for example), and default_hostgroup has pen
>> issues (oops!). Presumably we need a way to ping authors and find out
>> if they're just AFK or have stepped away from the plugin entirely.
>>
>> 3) Some plugins are definitely abandoned. I recall Chris Pisano taking
>> over the foreman_banner plugin last year and struggling to get in touch
>> with the original author at all.
>>
>> For context, Fedora does have a policy for this that makes some sense:
>>
>> https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai
>> ners
>>
>> That's quite heavy, but some of the points make sense. So, do we need
>> to add something to our docs about this. My gut feeling is:
>>
>> * Yes, we do
>> * Only applies to plugins in "theforeman" GitHub repo
>> * We need to add extra maintainers to the Rubygems *before* the author
>> leaves - Chris had a real issue here. This could be a requirement of
>> getting aplugin packaged, for example.
>> * We need to allow authors to "abandon" a plugin clearly (something
>> like how the Arch User Repository does it maybe?)
>>
>> Thoughts?
>> Greg
>
>In general +1. I'm not sure if official policy changes anything, probably does
>not do any harm either. It would be great if someone went over all plugins
>under theforeman org on github, found projects with single owner and ask the
>owner to extend the list. Or someone scritped a simple check so we would avoid
>this situation in future. I think what Dmitri described is fair and should
>become a common practice for new repos/gems in our org.
This went fairly quiet, but we all seem largely in agreement. I'll
draft something up for the website and send a PR tomorrow. I had a few
side questions though:
> In general +1. I'm not sure if official policy changes anything,
> probably does not do any harm either
Indeed, and helps us to remember to add maintainers when bringing a
plugin into the GitHub org.
> It would be great if someone went over all plugins under theforeman
> org on github, found projects with single owner and ask the owner to
> extend the list. Or someone scritped a simple check so we would
> avoid this situation in future. I think what Dmitri described
> is fair and should become a common practice for new repos/gems in our
> org.
Is there a way to view that info on Rubygems? I can't see it on the gem
pages themselves, is there an API I've missed?
···
On Wed, 2017-07-19 at 10:13 +0200, Marek Hulán wrote:
On Tue, 2017-07-18 at 16:28 +0200, Daniel Lobato Garcia wrote:
+1 to this, I am stuck with foreman-docker where I want to give
publish
I'd like to look at a larger revamp of the plugins section of the site
in a while (there was another thread about this, I think) but this will
do for now.
I'll script up the list of plugins that need extra maintainers
tomorrow.
···
On pondělí 14. srpna 2017 17:31:00 CEST Greg Sutcliffe wrote:
> Hi all,
>
> This went fairly quiet, but we all seem largely in agreement. I'll
> draft something up for the website and send a PR tomorrow. I had a few
> side questions though:
>
> On Wed, 2017-07-19 at 10:13 +0200, Marek Hulán wrote:
> > In general +1. I'm not sure if official policy changes anything,
> > probably does not do any harm either
>
> Indeed, and helps us to remember to add maintainers when bringing a
> plugin into the GitHub org.
>
> > It would be great if someone went over all plugins under theforeman
> > org on github, found projects with single owner and ask the owner to
> > extend the list. Or someone scritped a simple check so we would
> > avoid this situation in future. I think what Dmitri described
> > is fair and should become a common practice for new repos/gems in our
> > org.
>
> Is there a way to view that info on Rubygems? I can't see it on the gem
> pages themselves, is there an API I've missed?
–
Marek
On Tue, 2017-07-18 at 16:28 +0200, Daniel Lobato Garcia wrote:
+1 to this, I am stuck with foreman-docker where I want to give
publish
Ah, perfect, thanks. I'll get a policy drafted up and then I can script
this an mail all plugins that only have a single owner to ask them to
add another.
Greg
···
On Tue, 2017-08-15 at 08:20 +0200, Marek Hulán wrote:
> curl https://rubygems.org/api/v1/gems/foreman_chef/owners.json
>
> see http://guides.rubygems.org/rubygems-org-api/#owner-methods for
> more details.
