Re: Project development and governance model

On lip 24, Tasos Alvas wrote: I just use vim, it has automatic wrap for files in the 'mail' mode. Well, what's fun for me is designing the infrastructure, trying out new things and integrating everything at various levels. For example coming up with the 'parse_kv_config' and 'parse_kv_items' filters over the course of a few roles where in each iteration I honed in on a good generalized approach to configuration was rewarding. Or finding out a good way to manage LDAP configuration and data in the directory via Ansible. But that's basically the crux of the DebOps project as a whole - bring different stuff together and integrate it into a working solution. What I would like to do is focus on that part. That's why for me it's hard to delegate writing stuff to other people - if I design a way to do something, it's basically identical to writing the actual code, so I might as well do it right away... But that's probably something I will have to rein in to allow for more collaborative work in this project. Adding contributions to DebOps requires at least some understanding of how everything works, and DebOps has a steep learning curve on top of Debian and Ansible, not to mntion the whole sysadmin work with designing your infrastrucure, etc. I'm not sure how we can lower the bar to entry apart from documenting everything extensively. Maybe more detailed instructions in the DEVELOPMENT.rst documentation that show how contributions are reviewed and what common mistakes can be easily avoided could be useful for new developers. You probably nailed it with the hat idea. I'm not sure about specific categories from the point of view of a software project, but if we look at it from a sysadmin perspective there's usually separation of concerns in larger teams - networking, hypervisor management, application deployment, DBA, firewall and security, etc. These roles could be applied in DebOps development, where different experts in each field chime in when things get added. It will be heard to implement review notifications via codeowners though, since a single file named 'defaults/main.yml' in most roles can have configuration from multiple fields - firewall config, webserver, database, LDAP, and so on. We would probably have to have a "general pipeline" of sorts through which everything is pushed before being committed to the main repository, not unlike LKML. Then people can chime in if they see obvious issues, they can be corrected before final version is committed to the official repository. And I guess this is why 'debops-devel' mailing list was created, we would just have to start using it more. Just thinking aloud here... I'm not sure how feasile would implementation of this be in the current state of DebOps and how it is developed. Meaningful contributions are expensive. You need to set up a development environment if you want to write a proper role, test everything, write documentation, fix all linting issues, etc. I've heard about many cases of people that use DebOps and a few custom roles added on top of it. The custom roles are barebones just to make things work your environment, and they are left in a barebones state because they work for them. Overcoming the above hurdle is really hard; some people even ask me to write the roles properly from scratch which I'm happy to do, although they either have to wait, or I have to drop whatever I'm currently working on to do their thing. And then something else comes along that requires attention, either in te project or at th workplace, and I'm distracted yet again. I guess that's the life of a system administrator for you. Or we could go in the other direction similar to how Linux kernel went, and do short release cycles every couple weeks or so. If your change or a new role didn't make it to the last release, that's fine, just wait to the next one. But that probably requires a dedicated person just for the task of combining all the changes and making a release. Linus became de facto that person after many years of developing Linux, when the community was large and diverse enough to let the development momentum go on without his involvement. Not to mention that the whole model of a 'stable branch' would have to be redesigned and handled by more people. DebOps has a looong way for that to happen. For now, I guess we're stuck. You mean [1]? Fixing that would require diving into the bowels of the 'pki' role and messing with the shell scripts. I guess if you call that "easy", we can go with that. :-) [1]: https://github.com/debops/debops/issues/1424 For the issue and pull request labels, I went with a system described here[2], you might want to check it out. I wouldn't say that low priority is synonymous with a good first issue... First issues can be spelling mistakes, a missing comma, wrong number of empty lines in 'defaults/main.yml' between variables, something that's obvious to see in the code you browse at the moment. [2]: http://karolis.koncevicius.lt/posts/improving_github_issue_labels/ I would say, forget about it. The separate keyring repository was created to coordinate access to hundreds of various role repositories in the 'debops' GitHub organization. With the move to a single monorepo, keeping your own fork in which you can work on separate branches and do pull requests from them became trivial, so there's no need to track the GPG keys of coontributors. I guess when the CREDITS file gets added, when can specify the GPG fingerprints of people in it and it will be enough to gather the keys via a script. And we will have a proper source of truth for that as well. For me as a release manager (another hat, hmmm), GPG signing a release doesn't really matter, that's more important for the downstream - eventual Debian package will depend on a signed release to authenticate it. You might have a good idea, a proper LDAP server for various services in DebOps could allow for even more "dogfooding" and provide access to the wiki and other services if they crop up. I currently don't have access for a cheap and performant enough VM to set it up externally. I'll check with my workplace to see if I can have a dedicated VM for the project that could hold LDAP and some other authentication stuff. Imre proposed access to a VM on his infrastructure, I wonder if we could use it for that purpose... Hook, line and sinker... :-) Yup, it would be nice to set one up eventually, maybe when enough people declare that they would back it financially.. I don't really have time or resources to do that at the moment though. But moving out from a single work environment to focus entirely on writing shared infrastructure used by other organizations would be an interesting job. Less stress from dealing with daily issues of empty mailboxes, full disk drives, user calls, etc. Basically a Tier 4 - infrastructure research and development[3] for multiple organizations. [3]: https://en.wikipedia.org/wiki/Technical_support#Tier_4 Maybe someday. :) -- Maciej