Can we improve maintainership?

[bittner]

This repository seems a bit unmaintained. Can we do something about it?

For @puppetlabs ModuleSync seems to have stopped being a project of interest (#160). PDK is meant to take over everything ModuleSync was started for, and this is a good thing---at least for what Puppet and Puppet modules is concerned.

For everyone using ModuleSync actively, and specifically outside of the strict context of Puppet modules, the story looks a bit different. We at @vshn, for example, have started to manage Git repositories in their generic sense with ModuleSync. Many of them are related to Puppet (profiles, hieradata), but many of them are not. This makes it obvious, for people that don't see this yet, that "ModuleSync" is a project that is generally useful. In a way that it even may make sense to maybe rename it one day. To make this fact more evident.

We're strong believers of the values -- and advantages -- of Free Software, and believe we know the long-term price of maintaining private forks. I'd rather see that we continue with this piece of software, well-maintained, in the community.

[zachfi]

Thank you for raising the issue. I'll dip a toe in for some discussion, I've certainly appreciated this project, and give thanks to its authors every time I use it, which happens to be just this week.

The value I get from this project has been a way for me to track the changes that are going on in the community around testing and module best practices and remaining relatively ignorant of the specific versions etc, as well as the consistency you get from injecting data into templates to render consistent configurations. Which in a way, is the same delight I've had for puppet itself, just in a different context. This has allowed me to rebase my configs periodically (twice? a year) and update all the practices for the modules that I maintain. This has been super useful for me, who doesn't spend nearly as much time working on puppet I as used to, though I still use and want to maintain the modules under my keep.

Where this project starts to lose its utility for me personally, is in the specific workflows associated with performing the various steps of testing and releasing a module. I've always felt like the overside square peg for the round hole here, perhaps by design, but perhaps something of a one-size fits all approach that doesn't fit anyone well. I think if you look at the recent issues list, its clear that folks wants their specific feature to help their workflow.

I think what you are referring to that you've built, if I understand correctly, is a generic data -> template git repo management, which sounds super useful for all kinds of projects where you want to pass data into templates that become files, as a way to keep similar looking projects behaving very similarly. Indeed I've written several tools to do just this, though perhaps not in the generic sense, and not in ruby. With this feature alone you get pretty close to delivering the value of this project as far as consistency of configuration for a bunch of git repos. What you do next after modifying all of these files to converge on your desired state is another mater, which is lumped in here as bin/ scripts and a couple dozen rake tasks.

As I see it, the workflow management components that are somewhat puppet specific would prevent the sort of generic repo management that I think you are referring to. The bin scripts such as bin/clean-git-checkouts but only with the knowledge of where in the workflow you would want to use this, and there may be several such work flow steps that a user might want to perform inside of their own repo set, which can be done, but only with modification of the scripts themselves, and not merely some data that would describe the steps to take, and at which points of the workflow. Much in the way that a .travis.yml file has ordered steps to take, than just executing ./runtravis.sh, there is structure, and not just raw execution without context.

[bittner]

@xaque208 You should really give PDK and Pdksync a try. It's great!

[zachfi]

@bittner I'll do just that. I'd been waiting for maturity, but perhaps that day has arrived.

[bastelfreak]

Hi. From a Vox Pupuli perspective this project isn't deprecated, we're still using it and a migration to PDK will take a some time. Yes there are some open PRs. As on every open source project, we're low in maintainers. @bittner let me know if you're interested in joining Vox Pupuli to help or if you know any people with ruby/puppet knowledge, we're always happy about new maintainers.

[zachfi]

It looks to me like pdksync is trying to do what this project is doing also, but probably with PDK. I'd been thinking that, as @bastelfreak mentions, that perhaps this project (primarily through the configurations) would end up using PDK at some point, but I'm not clear what would be required of modulesync directly to support that migration.

[bastelfreak]

Our long term goal is to migrate https://github.com/voxpupuli/modulesync_config to something that works with the pdk. David did some work on this at voxpupuli/modulesync_config#550 . But, at least from my point of view, this has a very low priority because the current modulesync setup works and I don't see a need to change it.

[bittner]

Hi. From a Vox Pupuli perspective this project isn't deprecated, we're still using it and a migration to PDK will take a some time. Yes there are some open PRs. As on every open source project, we're low in maintainers. @bittner let me know if you're interested in joining Vox Pupuli to help or if you know any people with ruby/puppet knowledge, we're always happy about new maintainers.

I'd be happy to join, but it would be sufficient to add @tobru to the circle of maintainers that are allowed to merge PRs. In addition, @mhutter is definitely someone with Ruby/Puppet knowledge.

[bittner]

I'll be probably starting to work on adding GitLab MR support (merge requests) soon. Is there any realistic chance to have this then merged into this repository, or shall we just plan to keep on using our own fork?

See also: #80 (comment)

[bastelfreak]

@tobru was already a member of Vox Pupuli, I added him to the correct GitHub group. @tobru you can now also review and merge PRs in this project (if you want to). @bittner yes, please provide the PR and we're happy to review it.

[bittner]

@bastelfreak, I'm afraid this went down the wrong throat. I've discussed this with @tobru and @mhutter, and we agreed that it probably makes most sense that I offer myself for maintainership.

I'd need permissions only on this project and on modulesync_config for maintaining the related alignments on the configuration repository.

Can I then also add reviewers to PRs? That would be important. I'll need people to help me out with reviewing PRs. -- Thanks!

[bittner]

@bastelfreak 🔔 ping

[bastelfreak]

I sent you the github invitation. Most of the collaborators get email notifications about new PRs and review them if they think they are qualified and have some free time. Adding explicit reviewers of course works as well. Please keep in mind to not merge your own PRs. Most of our repositories have a CONTRIBUTING.md or a .github/CONTRIBUTUNG.md. Also we've some (mostly module specific) guidelines on our website. I recommend to everybody to join our IRC channel #voxpupuli on freeenode. That makes quick ad hoc feedback easier.

[bittner]

Thank you! I understand and agree.

I see that reviewers can only be users that are members of the Vox Pupuli organization. That's unfortunate, but probably makes sense.

[bastelfreak]

Ah yes, I think that's a github feature/limitation. But still everybody can approve it, even if they are not part of the org.

[DavidS]

To tie up what @bastelfreak has been saying about the low priority to move over to pdksync, I completely understand your (both as individual and as community) view not to work on replacing something that's working for you.

That said, and with the caveat that I'm neither a member of the PDK nor PDKsync team anymore, I do believe it would be of long-term mutual benefit to have more folks contribute to the pdk-templates and use PDKsync, in the same manner that the PDK and the pdk-templates have shown that it's better to have a common skeleton for modules.

Given this belief I'll continue working (as time permits :-/ ) on converging the puppetlabs/pdk-templates and the voxpupuli/modulesync_config to a point where a cutover is cheap or free. As a first step I'm looking to collect mostly cosmetic changes in the PR Tim linked, and lift (steal ;-) ) any nice features you folks have here into pdk-templates. Once I have all the low-hanging fruits done it'll be easier to see what is left and what can be done about those differences.

[bittner]

Should we close this issue?