Topics

Beaker Ownership RFC

Lucy Wyman <lucy@...>
 

Hi Vox!

First, thank you SO MUCH for everything you do, and for your interest in maintaining Beaker. I've put together an RFC for transferring ownership and had it approved within Puppet, so we're ready to have anyone from Vox who's interested read it over and discuss! Please feel free to leave any comments, questions, or concerns either in the document, this email thread, slack, or IRC and we can discuss. I will also be at the next Vox meeting on Tuesday, June 23rd as well if there's anything folks want to discuss in real-time.

Thanks so much! I hope everyone is staying well.

Ewoud Kohl van Wijngaarden
 

On Mon, Jun 15, 2020 at 08:10:46AM -0700, Lucy Wyman wrote:
Hi Vox!

First, thank you SO MUCH for everything you do, and for your interest in
maintaining Beaker. I've put together an RFC
<https://docs.google.com/document/d/1AHcStgkg060YBLjLiat-3nVnU1ENTUtP8gHE_dhWHms/edit?usp=sharing>
for transferring ownership and had it approved within Puppet, so we're
ready to have anyone from Vox who's interested read it over and discuss!
Please feel free to leave any comments, questions, or concerns either in
the document, this email thread, slack, or IRC and we can discuss. I will
also be at the next Vox meeting on Tuesday, June 23rd as well if there's
anything folks want to discuss in real-time.

Thanks so much! I hope everyone is staying well.
Hello Lucy,

As someone who does use beaker and is frustrated by the lack of its maintenance, I'm certainly interested. However, I'm disappointed by the proposal.

First of all, it only mentions the Beaker respository (which I assume is https://github.com/puppetlabs/beaker). However, in practice I haven't found issues there or things I missed. The majority of issues are in related repositories. Like https://github.com/puppetlabs/beaker-hiera which is archived, but the functionality is completely missing now. It meantions it should be in beaker-puppet, but isn't. beaker-hostgenerator the PRs are usually open for a month or 2 before seeing any response.

There is also a very strong control that everything has to go through Puppet employees when it comes to a release. To me this is a big issue. Vox Pupuli is IMHO its own organization and should (mostly) work indepent. If you don't trust VP to manage it, then you shouldn't hand it over. Note that only a small subset of people actually has control over https://rubygems.org/profiles/voxpupuli. Most collaborators only rely on automation when a tag is pushed.

So in short, I'd love to see active development on Beaker again but think that the current proposal undermines the Vox Pupuli projects integrity.

It would be my preference to go the open source way. Fully transfer the projects and be maintainers via the meriocratic way.

If this is undesirable and control must be kept, then I'd suggest to create a new organization on Github and transfer it there.

Trevor Vaughan
 

I'm all for widening the scope of Beaker maintenance but I have to agree with Ewoud that this seems like a Puppet project with a Vox name.

Based on this proposal, leaving it in the Puppetlabs namespace and just adding select individuals as admins on the repos would serve the same purpose.

Trevor


On Tue, Jun 16, 2020 at 9:18 AM Ewoud Kohl van Wijngaarden <ewoud+voxpupuli@...> wrote:
On Mon, Jun 15, 2020 at 08:10:46AM -0700, Lucy Wyman wrote:
>Hi Vox!
>
>First, thank you SO MUCH for everything you do, and for your interest in
>maintaining Beaker. I've put together an RFC
><https://docs.google.com/document/d/1AHcStgkg060YBLjLiat-3nVnU1ENTUtP8gHE_dhWHms/edit?usp=sharing>
>for transferring ownership and had it approved within Puppet, so we're
>ready to have anyone from Vox who's interested read it over and discuss!
>Please feel free to leave any comments, questions, or concerns either in
>the document, this email thread, slack, or IRC and we can discuss. I will
>also be at the next Vox meeting on Tuesday, June 23rd as well if there's
>anything folks want to discuss in real-time.
>
>Thanks so much! I hope everyone is staying well.

Hello Lucy,

As someone who does use beaker and is frustrated by the lack of its
maintenance, I'm certainly interested. However, I'm disappointed by the
proposal.

First of all, it only mentions the Beaker respository (which I assume is
https://github.com/puppetlabs/beaker). However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories. Like https://github.com/puppetlabs/beaker-hiera
which is archived, but the functionality is completely missing now. It
meantions it should be in beaker-puppet, but isn't. beaker-hostgenerator
the PRs are usually open for a month or 2 before seeing any response.

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release. To me this is a big issue.
Vox Pupuli is IMHO its own organization and should (mostly) work
indepent. If you don't trust VP to manage it, then you shouldn't hand it
over. Note that only a small subset of people actually has control over
https://rubygems.org/profiles/voxpupuli. Most collaborators only rely on
automation when a tag is pushed.

So in short, I'd love to see active development on Beaker again but
think that the current proposal undermines the Vox Pupuli projects
integrity.

It would be my preference to go the open source way. Fully transfer the
projects and be maintainers via the meriocratic way.

If this is undesirable and control must be kept, then I'd suggest to
create a new organization on Github and transfer it there.





--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

Lucy Wyman
 

However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories.

Absolutely! This is echoed across the community. I have a note at the bottom of the RFC under the heading "What about other Beaker-related repositories?". We're starting with Beaker because it's the biggest pain point, and plan to transfer ownership for Beaker-related repos to interested parties with Beaker as a precedent. Would you or Vox be interested in owning and maintaining beaker-hiera, beaker-hostgenerator, and beaker-puppet?

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release.

Yes, that's absolutely true of this draft. We're happy to pin Beaker if it breaks our pipelines, I think we're mostly nervous that it will break right before a release. I'll discuss with affected teams about whether we'd like a heads up + a day to run tests internally and pin, or if we're ok with treating Beaker like any other upstream repo and pinning after release. I don't think we expect releases to be gated on Puppet approval, but we might like some courtesy time to pin without panic.

Based on this proposal, leaving it in the Puppetlabs namespace and just adding select individuals as admins on the repos would serve the same purpose.

We'd really like to move Beaker out of our namespace if possible, and removing Puppet approval from the release process gives Vox more autonomy. I hope that's ok?


On Tue, Jun 16, 2020 at 7:52 AM Trevor Vaughan <tvaughan@...> wrote:
I'm all for widening the scope of Beaker maintenance but I have to agree with Ewoud that this seems like a Puppet project with a Vox name.

Based on this proposal, leaving it in the Puppetlabs namespace and just adding select individuals as admins on the repos would serve the same purpose.

Trevor

On Tue, Jun 16, 2020 at 9:18 AM Ewoud Kohl van Wijngaarden <ewoud+voxpupuli@...> wrote:
On Mon, Jun 15, 2020 at 08:10:46AM -0700, Lucy Wyman wrote:
>Hi Vox!
>
>First, thank you SO MUCH for everything you do, and for your interest in
>maintaining Beaker. I've put together an RFC
><https://docs.google.com/document/d/1AHcStgkg060YBLjLiat-3nVnU1ENTUtP8gHE_dhWHms/edit?usp=sharing>
>for transferring ownership and had it approved within Puppet, so we're
>ready to have anyone from Vox who's interested read it over and discuss!
>Please feel free to leave any comments, questions, or concerns either in
>the document, this email thread, slack, or IRC and we can discuss. I will
>also be at the next Vox meeting on Tuesday, June 23rd as well if there's
>anything folks want to discuss in real-time.
>
>Thanks so much! I hope everyone is staying well.

Hello Lucy,

As someone who does use beaker and is frustrated by the lack of its
maintenance, I'm certainly interested. However, I'm disappointed by the
proposal.

First of all, it only mentions the Beaker respository (which I assume is
https://github.com/puppetlabs/beaker). However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories. Like https://github.com/puppetlabs/beaker-hiera
which is archived, but the functionality is completely missing now. It
meantions it should be in beaker-puppet, but isn't. beaker-hostgenerator
the PRs are usually open for a month or 2 before seeing any response.

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release. To me this is a big issue.
Vox Pupuli is IMHO its own organization and should (mostly) work
indepent. If you don't trust VP to manage it, then you shouldn't hand it
over. Note that only a small subset of people actually has control over
https://rubygems.org/profiles/voxpupuli. Most collaborators only rely on
automation when a tag is pushed.

So in short, I'd love to see active development on Beaker again but
think that the current proposal undermines the Vox Pupuli projects
integrity.

It would be my preference to go the open source way. Fully transfer the
projects and be maintainers via the meriocratic way.

If this is undesirable and control must be kept, then I'd suggest to
create a new organization on Github and transfer it there.





--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

Ewoud Kohl van Wijngaarden
 

On Tue, Jun 16, 2020 at 11:22:43AM -0700, Lucy Wyman wrote:
However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories.

Absolutely! This is echoed across the community. I have a note at the
bottom of the RFC under the heading "What about other Beaker-related
repositories?". We're starting with Beaker because it's the biggest pain
point, and plan to transfer ownership for Beaker-related repos to
interested parties with Beaker as a precedent. Would you or Vox be
interested in owning and maintaining beaker-hiera, beaker-hostgenerator,
and beaker-puppet?
I can't speak for others, but I would certainly like that. beaker-vagrant is another.

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release.

Yes, that's absolutely true of this draft. We're happy to pin Beaker if it
breaks our pipelines, I think we're mostly nervous that it will break right
before a release. I'll discuss with affected teams about whether we'd like
a heads up + a day to run tests internally and pin, or if we're ok with
treating Beaker like any other upstream repo and pinning after release. I
don't think we expect releases to be gated on Puppet approval, but we might
like some courtesy time to pin without panic.
In general we should maintain compatibility according to semver so strict pinning should generally not be needed. Regressions should be dealt with by a bugfix release. Of course I understand the pain when this happens during a release, but IMHO it's not different from the constant CI runs for many different Puppet modules. Good code reviews and good regression tests in CI together with good communication are the solution to this. For example by giving a heads up that a release is planned.

I'd be fine with a group that has to ack a release and that group can contain Puppet employees but it shouldn't be limited to Puppet employees.

Based on this proposal, leaving it in the Puppetlabs namespace and just
adding select individuals as admins on the repos would serve the same
purpose.

We'd really like to move Beaker out of our namespace if possible, and
removing Puppet approval from the release process gives Vox more autonomy.
I hope that's ok?

On Tue, Jun 16, 2020 at 7:52 AM Trevor Vaughan <tvaughan@...>
wrote:

I'm all for widening the scope of Beaker maintenance but I have to agree
with Ewoud that this seems like a Puppet project with a Vox name.

Based on this proposal, leaving it in the Puppetlabs namespace and just
adding select individuals as admins on the repos would serve the same
purpose.

Trevor

On Tue, Jun 16, 2020 at 9:18 AM Ewoud Kohl van Wijngaarden <
ewoud+voxpupuli@...> wrote:

On Mon, Jun 15, 2020 at 08:10:46AM -0700, Lucy Wyman wrote:
Hi Vox!

First, thank you SO MUCH for everything you do, and for your interest in
maintaining Beaker. I've put together an RFC
<
https://docs.google.com/document/d/1AHcStgkg060YBLjLiat-3nVnU1ENTUtP8gHE_dhWHms/edit?usp=sharing

for transferring ownership and had it approved within Puppet, so we're
ready to have anyone from Vox who's interested read it over and discuss!
Please feel free to leave any comments, questions, or concerns either in
the document, this email thread, slack, or IRC and we can discuss. I will
also be at the next Vox meeting on Tuesday, June 23rd as well if there's
anything folks want to discuss in real-time.

Thanks so much! I hope everyone is staying well.
Hello Lucy,

As someone who does use beaker and is frustrated by the lack of its
maintenance, I'm certainly interested. However, I'm disappointed by the
proposal.

First of all, it only mentions the Beaker respository (which I assume is
https://github.com/puppetlabs/beaker). However, in practice I haven't
found issues there or things I missed. The majority of issues are in
related repositories. Like https://github.com/puppetlabs/beaker-hiera
which is archived, but the functionality is completely missing now. It
meantions it should be in beaker-puppet, but isn't. beaker-hostgenerator
the PRs are usually open for a month or 2 before seeing any response.

There is also a very strong control that everything has to go through
Puppet employees when it comes to a release. To me this is a big issue.
Vox Pupuli is IMHO its own organization and should (mostly) work
indepent. If you don't trust VP to manage it, then you shouldn't hand it
over. Note that only a small subset of people actually has control over
https://rubygems.org/profiles/voxpupuli. Most collaborators only rely on
automation when a tag is pushed.

So in short, I'd love to see active development on Beaker again but
think that the current proposal undermines the Vox Pupuli projects
integrity.

It would be my preference to go the open source way. Fully transfer the
projects and be maintainers via the meriocratic way.

If this is undesirable and control must be kept, then I'd suggest to
create a new organization on Github and transfer it there.



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --