On 5/9/20 8:52 PM, Tobias Urdin wrote:
Hello,
I don't agree, we should continue on the chosen path of not supporting Puppet 5 in the Victoria release.
We've had Puppet 6 support since I introduced the testing for it in 2018 back then we ran Puppet 5 and Puppet 6 on every commit until we deemed it pretty redundant and moved Puppet 6 jobs to experimental while keeping the Puppet 6 syntax and unit jobs.
We've never claimed that Puppet OpenStack is going to support downstream OS repackaging of Puppet, even though RDO/TripleO does the same we've always tested Puppet with upstream versions for our testing, only Debian has skipped that and testing with downstream packages.
I don't understand why you insist that we shouldn't use downstream distribution packages. I haven't heard that the project claimed that we are "support[ing] downstream OS repackaging of Puppet", but I haven't heard that we aren't either, or even any preference in this regard. This I miss this information somewhere? Did someone even write this somewhere? Or is this only your own view? One thing is that the Debian packages for Puppet are of better quality than the upstream ones in many ways. There's also the problem that adding an external artifact is *not* what my project is about (see below).
I don't think keeping Puppet 5 jobs for Debian would be a good idea because it would block the whole idea of moving to Puppet 6 in the first place.
What would we earn from Puppet 6? Is there some improvements in the language you would like to benefit of? We aren't even using half of what Puppet 5 offers (like typed variables, for example). Maybe we could start by that.
Puppet 5 will be EOL one month after Victoria release, while I highly doubt that we will introduce changes that will break Puppet 5 in the Victoria cycle we would like to start looking forwarding instead of being stuck with all the legacy stuff
Not having things that are breaking me is exactly what I am requesting here. So yeah, please don't break me !!! :) My installer is fully contained in Debian and contains absolutely ZERO external resources. I want to keep things this way for many reasons, including being able to ship the whole product on a redistribuable CD made by things only from Debian. I very much agree that we should move forward with Puppet 6 at some point, but in Debian, we're far from being there yet, unfortunately. Packaging Puppet 6 requires a lot of things to happen, like for example (if I'm not mistaking) having Puppet upstream to support Ruby 2.7, which is currently in Sid, plus packaging lots of Clojure stuff and so on. All I'm asking is that you delay this enough so the work can be done, and given the amount of work and my time constraint, I'm really not sure what this means, unfortunately.
If anybody ever want something to do I have nice big list of things that we could do, I've posted an old version of it in an email to this mailing list during PTL nominations.
Can you point at it so I have a look? (just the subject so I can search or any other pointer...). I have some ideas too of things I'd like to get done. For example, I have started a provider for barbican secret, in order to get swift on-disk encryption being setup automatically (this is currently a half-automated thing for me right now), and many other improvements of this kind. Have we booked some sessions for the virtual PTG? Cheers, Thomas Goirand (zigo)