Migrate to voxpupuli

[fpletz]

The original maintainers of puppet-php are not developing it actively anymore because they have moved on from Puppet. :panda_face:

Here is your proposed plan of action:

• Find new maintainers and give them push rights to the repository and later also the Puppet Forge
• If we find passionate and active maintainers we will transfer the ownership of puppet-php to them officially

Please comment on this issue if you want to help out. You should at the very least be an active user and ideally have already contributed to the project.

Thanks! :heart:

[mmoll]

I'd like to nominate @igalic for push access as a first measure.

[igalic]

oh dear… i mean… i am honoured and would like to thank you. seeing as this module is _puppet approved_ — would you consider moving it to @voxpupuli? if so, i can make invite either of you to @voxpupuli/module-admin

[jkroepke]

It still a problem here? Looks like the project is still active.

[mmoll]

It still a problem here?

@jkroepke Yes, it is.

Looks like the project is still active.

I try to be a good Janitor. However, I use this module myself only in a very limited scope in an "unusual" setup and don't have too much time to really test it and its PRs as I would normally do. Also, the lacking spec test coverage is making big refactorings hard. My main goal for now would be to get PHP 5.6/7.0 version selection to a really woking state for all supported OSes and then release a 4.0.0.

[jkroepke]

My main goal for now would be to get PHP 5.6/7.0

You should be open a epic ticket like https://github.com/owncloud/core/pull/21237. User like me can grab small tasks from it and send and pr to you.

[mmoll]

You should be open a epic ticket

We do have a 4.0.0 milestone - and, yes, I (or anybody else) could open new issues for that to break it down a little bit and I might do that, as soon as time permits. However, this does not solve the real problem of getting more people involved with the environments and skillsets needed.

[mmoll]

@jkroepke BTW, we do have a lot of new issues for tracking now ;)

[rendhalver]

It looks like you guys are pretty swamped with the backlog of issues. I would also recommend moving the module under the @voxpulli namespace too even more so considering it's Puppet Approved.

[mmoll]

@rendhalver I opened a lot of issues, to somehow organize the situation. From what I get the state of things improved over the last few weeks and is pretty good on Debian/Ubuntu and SLES now. Other platforms lack testing and implementation of the 5.x/7.0 version switch (which might not be applicable for some, I know it would be doable for FreeBSD). Other module vendors (including Puppet Labs breaking FreeBSD in my experience!) would just release a 4.0 as-is and wait for issues/PRs come in. I also do see that as a viable option, if no further movement happens in the next few weeks.

Regarding voxpupuli, personally I don't think that would be the right place for a PHP module, but would see moving it to there as a very last resort to keep things up. However, at the same time I can't imagine more contributors will get attracted there, so the real problem of finding people that are willing to pour in time to develop this module further would also not get solved.

[rendhalver]

Ah that explains it. I am testing this out for a new website deployment and the current release on puppet forge doesn't looks like it will do what I need it to. I have noticed a lot of useful changes since the last release that will help with this project. Nice work. You could push out a 4.0.0-rc1 release in preparation for the 4.0.0 release so it could get some extra testing. If that will happen before the end of the week I am happy to track master to get that tested in my environment and let you know if I find any bugs.

[rendhalver]

Just letting you know I am using the master branch for this in my project. I haven;t run into any issues yet.

[mmoll]

Good to hear, thanks! I guess unlike on rubygems it won't be possible on the forge to mark a release as RC/beta so it doesn't get used by default?

[rendhalver]

I think the puppet module tool is setup to prefer stable over rc and beta versions. This ancient bug would suggest it does: https://projects.puppetlabs.com/issues/17824

I use puppet-blacksmith and travis-ci do a puppet-forge release when I add tag. If you want a hand setting it up let me know.

[mmoll]

This looks good, I'll try to get out a 4.0.0-beta1 out of the door next week. I'm already using blacksmith over at @theforeman for its modules and quite :green_heart: it.

[rendhalver]

Lovely! Drop a note here when you get that release out and I will start tracking it.

[mmoll]

done :bowtie:

[rendhalver]

Awesome. I will switch to that tomorrow.

[davividal]

I would happily help with whatever I can.

[mmoll]

@davividal If you can tackle any of the open issues, opening PRs would be much appreciated. Also reviewing incoming PRs of other people and even opening new issues to pinpoint problems we need to solve for a 4.0.0 release are bringing value.

[igalic]

@mmoll — it seems that this issue has been hijacked to discuss … something else :D perhaps it's time to close it? it seems to me that @mayflower is doing just a fine job of maintaining the module (again?)

[mmoll]

tbh, I'm still looking for help and there are still plenty of open issues to be solved for 4.0.0

[khdevel]

Hello,

What is the current status of the "new puppet-php maintainers"? Is the code in a "freeze state" or under development?

Thank you!

[mmoll]

@khdevel I can only point to my statement above

[igalic]

@mmoll o/~ hi

[mmoll]

@igalic So, we'd like to give this to @voxpupuli as there were no new potential maintainers coming up here. I don't have the full control of this repo here, but other people in @mayflower have, what would be the process to transfer this repo?

[daenney]

That's documented here: https://voxpupuli.org/docs/#migrating-a-module-to-voxpupuli 😄.

[mmoll]

@fadenb @fpletz (or anybody else), could you please coordinate?

[fadenb]

• [x] Ask one of the Administrators to add you to the modules/admin team.
• [x] At that point you can transfer your own repository
• [x] If migrating a module from puppetlabs, re-enable github issues.
• [x] Verify that all webhooks except travis are disabled.
• [x] Update the README.md with a description of the deprecation and a link to the new module location.
• [x] Release a 999.999.999 version of the original module to the forge, so users and tools knows to stop using it.
• [ ] Release a copy of your module to the ‘puppet’ forge account.
• [ ] Add the module to our modulesync setup
• [ ] Add the module to our plumbing repository(handles travis secrets)
• [ ] Ask one of the Admins to add the module to the collaborators Team on github.

First steps are done. Will try to complete the rest tomorrow.

[robinbowes]

Did this get migrated yet? I'm currently stuck on:

Error: Could not install 'mayflower-php' (v999.999.999)
  No releases matching '999.999.999' are available from https://forgeapi.puppetlabs.com

[jk2l]

no don't think so. it seem they are still fixing the test case. if you don't need newest OS support. You can consider use old version like 3.4.2

or you can just directly use voxpupuli/puppet-php with git

[robinbowes]

Cheers - I'll pin to 3.4.2 for now

[mmoll]

close this please.

[rnelson0]

It looks like this isn't published to the forge in the puppet namespace yet and should remain open until that is complete.

[mmoll]

oh, ok

[daenney]

@rnelson0 It is published now. Could we close this and poke someone from Puppet Labs to tag puppet/php as the approved module instead of this version?