Bug#924685: RFP: cumin -- An automation and orchestration framework
Hi, > Heck, you shouldn't even need to build your own debs if we do this > right; this will trickle down to bookworm and, from there, backports, > ubuntu, etc. Agreed, from my perspective an upstream-included debian/ dir is only useful until it gets packaged. From that point onwards fetching a Debian source package for rebuilds is way simpler and downstream distros like Ubuntu sync from Debian anyway instead of an upstream repo. It's also one thing less to maintain/keep in sync. Cheers, Moritz
Bug#924685: RFP: cumin -- An automation and orchestration framework
On 2022-11-23 17:59:41, Riccardo Coccioli wrote: > On Wed, Nov 23, 2022 at 5:15 PM Moritz Mühlenhoff > wrote: > >> Hi Antoine, >> >> [Adding Riccardo Coccioli, my colleague at Wikimedia and the primary >> author of Cumin to CC] >> >> > which makes me wonder: should we drop the debian branch on github and >> > gerrit? or should we (say, debian sponsors) pull changes from you and >> > sync them to salsa? >> > >> > how should we play this long term? >> >> My proposal would be to discard the debian branch on gerrit/github and >> make salsa.debian.org the authoritative repository for Cumin debs (and >> just build backports for apt.wikimedia.org based on the latest version >> on salsa/unstable). >> >> But let's hear from Riccardo on this as well. >> >> Cheers, >> Moritz >> > > I'd like to better understand why it would be better/easier to move the > debian branch into salsa instead of leaving it attached to the upstream > project. I'm not that familiar with the whole debian process, so correct me > if I'm missing something obvious. Sure. It really depends on how you want to manage this package. So far I've been assuming I'd be doing some of the work at least, which means I'd need access to the git repo, hence salsa, where I can also grant *you* access. I suspect the reverse is not possible, and I wouldn't be able to contribute back to the wikimedia repositories myself... > It would seem to me that leaving the debian branch into the upstream > repository would also allow other distro/users to build their own deb > package using the same config without importing a separate repository. I don't think you need write access to the repository to build your own deb, that's the thing. If you just add a pointer in the wikimedia repo to salsa, people will know where to find the repo. Heck, you shouldn't even need to build your own debs if we do this right; this will trickle down to bookworm and, from there, backports, ubuntu, etc. > As for the debian/watch file if you don't mind I would like to upload a > slightly different one that I use for another project as the tags are all > signed and it does work with the new GitHub APIs (see also the recent "Q: > uscan with GitHub" thread in debian-devel). Oh, yes of course, I'd be happy to see that. Let me know if you want access to the salsa repo. I'm fine either way. a. -- For every complex problem, there is an answer that is clear, simple - and wrong. - H.L. Mencken
Bug#924685: RFP: cumin -- An automation and orchestration framework
On Wed, Nov 23, 2022 at 5:15 PM Moritz Mühlenhoff wrote: > Hi Antoine, > > [Adding Riccardo Coccioli, my colleague at Wikimedia and the primary > author of Cumin to CC] > > > which makes me wonder: should we drop the debian branch on github and > > gerrit? or should we (say, debian sponsors) pull changes from you and > > sync them to salsa? > > > > how should we play this long term? > > My proposal would be to discard the debian branch on gerrit/github and > make salsa.debian.org the authoritative repository for Cumin debs (and > just build backports for apt.wikimedia.org based on the latest version > on salsa/unstable). > > But let's hear from Riccardo on this as well. > > Cheers, > Moritz > I'd like to better understand why it would be better/easier to move the debian branch into salsa instead of leaving it attached to the upstream project. I'm not that familiar with the whole debian process, so correct me if I'm missing something obvious. It would seem to me that leaving the debian branch into the upstream repository would also allow other distro/users to build their own deb package using the same config without importing a separate repository. As for the debian/watch file if you don't mind I would like to upload a slightly different one that I use for another project as the tags are all signed and it does work with the new GitHub APIs (see also the recent "Q: uscan with GitHub" thread in debian-devel). Thanks both for resuming the work on this! Riccardo
Bug#924685: RFP: cumin -- An automation and orchestration framework
Hi Antoine, [Adding Riccardo Coccilo, my colleague at Wikimedia and the primary author of Cumin to CC] > which makes me wonder: should we drop the debian branch on github and > gerrit? or should we (say, debian sponsors) pull changes from you and > sync them to salsa? > > how should we play this long term? My proposal would be to discard the debian branch on gerrit/github and make salsa.debian.org the authoritative repository for Cumin debs (and just build backports for apt.wikimedia.org based on the latest version on salsa/unstable). But let's hear from Riccardo on this as well. Cheers, Moritz
Bug#924685: RFP: cumin -- An automation and orchestration framework
On 2022-11-23 16:29:36, Moritz Mühlenhoff wrote: > Hi, > >> On 2022-11-18 14:49:28, Moritz Mühlenhoff wrote: >> > There is https://apt.wikimedia.org/wikimedia/pool/main/c/cumin/ which >> > would be a good starting point. >> >> ... if you don't mind, I'll start here instead: >> >> https://github.com/wikimedia/cumin/tree/debian >> >> i assume those are roughly equivalent? > > Yeah, the canonical repo is > https://gerrit.wikimedia.org/g/operations/software/cumin, but the > Github mirror will also do fine. hmmm... well actually, the origin of the repo doesn't really matter as I'll be pushing this to salsa anyways... which makes me wonder: should we drop the debian branch on github and gerrit? or should we (say, debian sponsors) pull changes from you and sync them to salsa? how should we play this long term? -- We reject kings, presidents and voting. We believe in rough consensus and running code. - David Clark
Bug#924685: RFP: cumin -- An automation and orchestration framework
Hi, > On 2022-11-18 14:49:28, Moritz Mühlenhoff wrote: > > There is https://apt.wikimedia.org/wikimedia/pool/main/c/cumin/ which > > would be a good starting point. > > ... if you don't mind, I'll start here instead: > > https://github.com/wikimedia/cumin/tree/debian > > i assume those are roughly equivalent? Yeah, the canonical repo is https://gerrit.wikimedia.org/g/operations/software/cumin, but the Github mirror will also do fine. Cheers, Moritz
Bug#924685: RFP: cumin -- An automation and orchestration framework
looking at this now... On 2022-11-18 14:49:28, Moritz Mühlenhoff wrote: > There is https://apt.wikimedia.org/wikimedia/pool/main/c/cumin/ which > would be a good starting point. ... if you don't mind, I'll start here instead: https://github.com/wikimedia/cumin/tree/debian i assume those are roughly equivalent? -- If you want to go fast, go alone. If you want to go far, go together. - African proverb
Bug#924685: RFP: cumin -- An automation and orchestration framework
Antoine wrote: Thanks! I would put that in the Python team, is that okay? Probably next > week too. > Sure, Python team sounds good to me as well. Cheers, Moritz
Bug#924685: RFP: cumin -- An automation and orchestration framework
On 2022-11-18 14:49:28, Moritz Mühlenhoff wrote: > Hi Antoine, > >> > NEW was thawed, and I just reinstalled cumin in a virtualenv, and >> > thought of this bug. :) Need help with the packaging? I'd be happy to >> > just throw it in the python packaging team... >> >> Ping! did you receive that message? > > Sorry for the late reply, this got backlogged in my inbox! > > It would be fantastic if you could bootstrap an initial upload, let's maybe > just pick debian/cumin on Salsa? I'd like to lure some of my Debian-savvy, > but not yet-DDs/DMs, colleagues into the maintenance as well :-) > > There is https://apt.wikimedia.org/wikimedia/pool/main/c/cumin/ which > would be a good starting point. Thanks! I would put that in the Python team, is that okay? Probably next week too. -- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?' - Mike Godwin, Electronic Frontier Foundation
Bug#924685: RFP: cumin -- An automation and orchestration framework
Hi Antoine, > > NEW was thawed, and I just reinstalled cumin in a virtualenv, and > > thought of this bug. :) Need help with the packaging? I'd be happy to > > just throw it in the python packaging team... > > Ping! did you receive that message? Sorry for the late reply, this got backlogged in my inbox! It would be fantastic if you could bootstrap an initial upload, let's maybe just pick debian/cumin on Salsa? I'd like to lure some of my Debian-savvy, but not yet-DDs/DMs, colleagues into the maintenance as well :-) There is https://apt.wikimedia.org/wikimedia/pool/main/c/cumin/ which would be a good starting point. Cheers. Moritz
Bug#924685: RFP: cumin -- An automation and orchestration framework
On 2021-09-01 10:37:22, Antoine Beaupré wrote: > On 2019-03-16 21:17:52, Moritz Muehlenhoff wrote: >> Antoine Beaupre wrote: >>> Upstream (in CC) already ships Debian packages on their Github >>> releases page, but it would be great to see this in Debian. >>> >>> I'd be happy to sponsor this package if upstream is willing to act as >>> maintainers, otherwise I will look at packaging this myself. >> >> Hi Antoine, >> thanks for your interest in Cumin :-) >> >> We're totally planning to maintain Cumin in Debian, but there's a >> few breaking changes lined up we don't want to impose on Debian >> users (plus NEW is frozen anyway), so this will probably only >> happen in a few months at the start of the bullseye development cycle. > > Hi! > > NEW was thawed, and I just reinstalled cumin in a virtualenv, and > thought of this bug. :) Need help with the packaging? I'd be happy to > just throw it in the python packaging team... Ping! did you receive that message? -- We don't need any more heroes. We just need someone to take out recycling. - Banksy
Bug#924685: RFP: cumin -- An automation and orchestration framework
On 2019-03-16 21:17:52, Moritz Muehlenhoff wrote: > Antoine Beaupre wrote: >> Upstream (in CC) already ships Debian packages on their Github >> releases page, but it would be great to see this in Debian. >> >> I'd be happy to sponsor this package if upstream is willing to act as >> maintainers, otherwise I will look at packaging this myself. > > Hi Antoine, > thanks for your interest in Cumin :-) > > We're totally planning to maintain Cumin in Debian, but there's a > few breaking changes lined up we don't want to impose on Debian > users (plus NEW is frozen anyway), so this will probably only > happen in a few months at the start of the bullseye development cycle. Hi! NEW was thawed, and I just reinstalled cumin in a virtualenv, and thought of this bug. :) Need help with the packaging? I'd be happy to just throw it in the python packaging team... a. -- Je viens d'un pays où engagé veut dire que tu t'es trouvé une job. - Patrice Desbiens
Bug#924685: RFP: cumin -- An automation and orchestration framework
On 2019-03-16 21:17:52, Moritz Muehlenhoff wrote: > Antoine Beaupre wrote: >> Upstream (in CC) already ships Debian packages on their Github >> releases page, but it would be great to see this in Debian. >> >> I'd be happy to sponsor this package if upstream is willing to act as >> maintainers, otherwise I will look at packaging this myself. > > Hi Antoine, > thanks for your interest in Cumin :-) > > We're totally planning to maintain Cumin in Debian, but there's a > few breaking changes lined up we don't want to impose on Debian > users (plus NEW is frozen anyway), so this will probably only > happen in a few months at the start of the bullseye development cycle. Awesome, I'm really happy to hear that! I figured it would be useful to have a tracking bug here, and it would be awesome if you could keep up to date. Otherwise I would understand as well of course. :) Let me know if you need a hand, I've packaged a few python things in Debian, for what that's worth... A.
Bug#924685: RFP: cumin -- An automation and orchestration framework
Antoine Beaupre wrote: > Upstream (in CC) already ships Debian packages on their Github > releases page, but it would be great to see this in Debian. > > I'd be happy to sponsor this package if upstream is willing to act as > maintainers, otherwise I will look at packaging this myself. Hi Antoine, thanks for your interest in Cumin :-) We're totally planning to maintain Cumin in Debian, but there's a few breaking changes lined up we don't want to impose on Debian users (plus NEW is frozen anyway), so this will probably only happen in a few months at the start of the bullseye development cycle. Cheers, Moritz
Bug#924685: RFP: cumin -- An automation and orchestration framework
Package: wnpp Severity: wishlist * Package name: cumin Version : 3.0.2 Upstream Author : Wikimedia foundation * URL : https://wikitech.wikimedia.org/wiki/Cumin * License : GPLv3 Programming Lang: Python Description : An automation and orchestration framework Cumin provides a flexible and scalable automation framework to execute multiple commands on multiple hosts in parallel. It allows to easily perform complex selections of hosts through a user-friendly query language which can interface with different backend modules and combine their results for a fine grained selection. The transport layer can also be selected, and can provide multiple execution strategies. The executed commands outputs are automatically grouped for an easy-to-read result. It can be used both via its command line interface (CLI) cumin and as a Python 3 only library. --- This is an interesting project that fills a gap between Puppet configuration management and hand-made batch commands on mutliple hosts. It allows sysadmins to leverage information stored in multiple backends to selectively run jobs on subsets of the infrastructure efficiently. Upstream (in CC) already ships Debian packages on their Github releases page, but it would be great to see this in Debian. I'd be happy to sponsor this package if upstream is willing to act as maintainers, otherwise I will look at packaging this myself.
