[PROPOSAL] Bug Triage for Modules

[Igor Galić]

Hi folks,

I would like to propose a bug triage for the puppet modules
team. At least for the time being, during the transition to
beaker I would also like to see the QA team included in
these meetings.

Many of our modules are in rough shape: They are plagued with
incomplete or wrong documentation and incomplete tests.

I think a weekly get-together would greatly accelerate our
progress or at least allow us to focus on key issues.
Moreover, it would allow us to more evenly distribute the
know-how about module internals and the workings of the
test suites. Being from Europe, I especially want to see a
more even distribution across time-zones. Currently it's
heavily focused in PST.

I highly welcome your input and your suggestions for a time.
A good place seems to be the same as that where we currently
hold puppet (hiera+facter+stdlib) bug triages: Google Hangout.


So long,
--
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i.g...@brainsware.org
URL: http://brainsware.org/
GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641

[Ryan Coleman]

Hi Igor, 

I'm the product manager for the Puppet Forge and Modules teams. Thanks for the note. I've commented in-line. 

On Wed, Jan 29, 2014 at 10:58 AM, Igor Galić <i.g...@brainsware.org> wrote:

I would like to propose a bug triage for the puppet modules
team. At least for the time being, during the transition to
beaker I would also like to see the QA team included in
these meetings. 

I like the proposal but we can't commit to this right now. 

 

Many of our modules are in rough shape:

I assume you mean Puppet Labs Forge modules here. Let me know if that's wrong. 

 

They are plagued with
incomplete or wrong documentation and incomplete tests.

Plagued seems a little strong to me but yes, there's lots to do. 

I think a weekly get-together would greatly accelerate our
progress or at least allow us to focus on key issues.
Moreover, it would allow us to more evenly distribute the
know-how about module internals and the workings of the
test suites. Being from Europe, I especially want to see a
more even distribution across time-zones. Currently it's
heavily focused in PST.

I'd like to be at a point where we can participate like this and at this cadence. I agree that the platform team here sets a good example. For a little internal context, their team is much larger and more established than ours. The module team formed in July and is a team of two. We're actively hiring to expand the team but at this point, we're stretched thin on our current work to improve module testing (beaker) and remain somewhat timely on pull requests. I owe you many more thoughts on beaker soon.  

On this front though, our project manager (Heidi) is spending time this week (and next) with the module team to improve the JIRA modules project. We'd like to make it easier to tell what's going on for issues or PRs against a given Puppet Labs module and make it easier for the engineering team to prioritize and triage those items in a timelier fashion.  

Again, thanks for discussing this and for all of your contributions. We'll get here soon, hopefully by next quarter if hiring is successful.

--

Ryan Coleman | Modules & Forge | ryanycoleman on twitter & #puppet IRC

 

[Andy Parker]

On Wed, Jan 29, 2014 at 3:03 PM, Ryan Coleman <ry...@puppetlabs.com> wrote:

Hi Igor, 

I'm the product manager for the Puppet Forge and Modules teams. Thanks for the note. I've commented in-line. 

On Wed, Jan 29, 2014 at 10:58 AM, Igor Galić <i.g...@brainsware.org> wrote:

I would like to propose a bug triage for the puppet modules
team. At least for the time being, during the transition to
beaker I would also like to see the QA team included in
these meetings. 

I like the proposal but we can't commit to this right now. 

 

Many of our modules are in rough shape:

I assume you mean Puppet Labs Forge modules here. Let me know if that's wrong. 

Yes, I think that is what he meant. He took part in the puppet PR triage today and brought up the possibility of having the module team do them as well.

 

 

They are plagued with
incomplete or wrong documentation and incomplete tests.

Plagued seems a little strong to me but yes, there's lots to do. 

I think a weekly get-together would greatly accelerate our
progress or at least allow us to focus on key issues.
Moreover, it would allow us to more evenly distribute the
know-how about module internals and the workings of the
test suites. Being from Europe, I especially want to see a
more even distribution across time-zones. Currently it's
heavily focused in PST.

I'd like to be at a point where we can participate like this and at this cadence. I agree that the platform team here sets a good example. For a little internal context, their team is much larger and more established than ours. The module team formed in July and is a team of two. We're actively hiring to expand the team but at this point, we're stretched thin on our current work to improve module testing (beaker) and remain somewhat timely on pull requests. I owe you many more thoughts on beaker soon.  

I am a little biased, but I think you might want to consider trying it out. It only needs to take as much time as you can devote to it. We started at one hour every fortnight, but weren't able to keep up with incoming PRs and so have changed to giving ourselves about 2 hours. After around 1.5 hours, though, we are pretty beat and so the last half hour is usually just some conversation or working on the actions that we had decided. One of the hardest things is to hold back from overcommitting during it and taking on too much.

I don't want to push you into anything, but it might be something to try.

 

On this front though, our project manager (Heidi) is spending time this week (and next) with the module team to improve the JIRA modules project. We'd like to make it easier to tell what's going on for issues or PRs against a given Puppet Labs module and make it easier for the engineering team to prioritize and triage those items in a timelier fashion.  

The PR triage hangouts are much more about quick turnaround and discussion on the PR topics. They aren't as much about "what is going on", but really making the decision about what *needs* to go on. I also find them to be a good chance to interact with people outside of PL and a nice break from my normal, daily grind.  In fact we've had Ashley show for ours several times and his input has been invaluable.

 

Again, thanks for discussing this and for all of your contributions. We'll get here soon, hopefully by next quarter if hiring is successful.

--

Ryan Coleman | Modules & Forge | ryanycoleman on twitter & #puppet IRC

 

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAFkZv1vqz8Yp7o51mGeO6j%2BDOdOhaLs18mbMcv7gTyOrLstezQ%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Andrew Parker

an...@puppetlabs.com

Freenode: zaphod42

Twitter: @aparker42

Software Developer

Join us at PuppetConf 2014, September 23-24 in San Francisco

[Erik Dalén]

On a related note, what are the features of beaker vs rspec-system?

We adopted rspec-system at Spotify and have written some node providers and fixes for it. Partly because it seemed like that was what the community modules were using (the ones that actually had any tests of that sort).

So what is the rationale for switching to beaker?

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/1792340092.99980.1391021937288.JavaMail.zimbra%40brainsware.org.

For more options, visit https://groups.google.com/groups/opt_out.

--
Erik Dalén

[Ryan Coleman]

On Thu, Jan 30, 2014 at 1:55 AM, Erik Dalén <erik.gus...@gmail.com> wrote:

On a related note, what are the features of beaker vs rspec-system?

We adopted rspec-system at Spotify and have written some node providers and fixes for it. Partly because it seemed like that was what the community modules were using (the ones that actually had any tests of that sort).

So what is the rationale for switching to beaker?

Hi Erik, I just sent a larger note to Puppet-Dev on Beaker. In essence, Beaker aims to provide Puppet Enterprise testing in addition to the functionality provided by rspec-system as a single testing framework for all PL projects and products. Migrating from rspec-system to Beaker (whenever you would want to do that) is not all that cumbersome and we'll write a migration guide soon-ish. See that thread for more. 

[Ryan Coleman]

On Wed, Jan 29, 2014 at 3:03 PM, Ryan Coleman <ry...@puppetlabs.com> wrote:

On Wed, Jan 29, 2014 at 10:58 AM, Igor Galić <i.g...@brainsware.org> wrote:

I would like to propose a bug triage for the puppet modules
team. At least for the time being, during the transition to
beaker I would also like to see the QA team included in
these meetings. 

I like the proposal but we can't commit to this right now. 

On this front though, our project manager (Heidi) is spending time this week (and next) with the module team to improve the JIRA modules project. We'd like to make it easier to tell what's going on for issues or PRs against a given Puppet Labs module and make it easier for the engineering team to prioritize and triage those items in a timelier fashion.  

The engineering team did meet last week and in addition to improving how we work with the JIRA MODULES project, the team decided to give your proposal a trial sooner than later. We're aiming to start with hangout next Tuesday, a week from today. I'll email Puppet-Users and Puppet-Dev later this week with more details. Thanks again for making the proposal.