A few months ago we added a policy that required 2 gem authors per
plugin. We did, however struggle to actually get two authors on some
plugins.
To make this a more "official" policy, I've created a "Foreman" account
on Rubygems, and the user <theforeman.rubygems@gmail.com> can be added
to any gem we keep on our namespace. This should minimize any issues
when transferring gems to new owners.
The account has a recovery email of my RedHat address, which means it
can be recovered even if I get hit by a bus (because my superiors can
open it). I will also revive the discussion about sharing infra
passwords with appropriate security
Unless anyone has any strong objections, I'll send a PR for review to
make adding this owner an official policy for our gems.
That user is now added to every gem I have access to. Feel free to do
the same with your own
Greg
···
On 10/11/17 14:02, Greg Sutcliffe wrote:
> To make this a more "official" policy, I've created a "Foreman" account
> on Rubygems, and the user can be added
> to any gem we keep on our namespace. This should minimize any issues
> when transferring gems to new owners.
tl;dr: on tags it can deploy the gem to rubygems. It standardizes the
deploy process and you're sure that any gem has a tag and vice versa.
···
On Fri, Nov 10, 2017 at 02:02:10PM +0000, Greg Sutcliffe wrote:
>A few months ago we added a policy that required 2 gem authors per
>plugin. We did, however struggle to actually get two authors on some
>plugins.
>
>To make this a more "official" policy, I've created a "Foreman" account
>on Rubygems, and the user can be added
>to any gem we keep on our namespace. This should minimize any issues
>when transferring gems to new owners.
>
>The account has a recovery email of my RedHat address, which means it
>can be recovered even if I get hit by a bus (because my superiors can
>open it). I will also revive the discussion about sharing infra
>passwords with appropriate security ;)
>
>Unless anyone has any strong objections, I'll send a PR for review to
>make adding this owner an official policy for our gems.
For what it's worth: it'd be good if this was rubygems@theforeman.org,
even if it's still stored on gmail. That way you can easily change it as
long as you own the domain.
···
On Fri, Nov 10, 2017 at 02:02:10PM +0000, Greg Sutcliffe wrote:
>To make this a more "official" policy, I've created a "Foreman" account
>on Rubygems, and the user can be added
>to any gem we keep on our namespace. This should minimize any issues
>when transferring gems to new owners.
I was about to suggest exactly this. Add the gems to a bot, let the
bot handle pushing new versions. Can be automated from the Git so we
don't even need any other authors on a gem (provided the access to the
bot account is properly shared for yanking etc).
Thoughts everyone?
···
On 10/11/17 14:23, Ewoud Kohl van Wijngaarden wrote:
>
> I like this. What are the opinions on deploying gems through Travis like
> voxpupuli does?
>
> https://docs.travis-ci.com/user/deployment/rubygems/
>
> tl;dr: on tags it can deploy the gem to rubygems. It standardizes the
> deploy process and you're sure that any gem has a tag and vice versa.
Agreed. Ohad is away (he controls the DNS domain), and I wanted to get
it done while I was thinking about it. I'll get that alias sorted when
he's back.
···
On 10/11/17 15:20, Ewoud Kohl van Wijngaarden wrote:
> On Fri, Nov 10, 2017 at 02:02:10PM +0000, Greg Sutcliffe wrote:
>> To make this a more "official" policy, I've created a "Foreman" account
>> on Rubygems, and the user can be added
>> to any gem we keep on our namespace. This should minimize any issues
>> when transferring gems to new owners.
>
> For what it's worth: it'd be good if this was rubygems@theforeman.org,
> even if it's still stored on gmail. That way you can easily change it as
> long as you own the domain.
