On Mon, Nov 26, 2018 at 7:45 PM Paul Frields <stickster@xxxxxxxxx> wrote: > > On Mon, Nov 26, 2018 at 5:47 PM Dennis Gilmore <dennis@xxxxxxxx> wrote: > > El lun, 26-11-2018 a las 17:14 -0500, Josh Boyer escribió: > > > Because the people that would be tasked with doing the development are > > > also tasked with cranking out the release. It's a "need more people problem". > > > > This is no longer entirely true, development of the compose tools is > > done entirely by PNT DevOps today. Bodhi and other tools in parts of > > the delivery pipeline are developed by people in Fedora Engineering who > > also have other tasks to do. > > > > > > ready to go. Ultimately a lot of those sort of ways of optimising > > > > things are things that have been known for some time but no one has > > > > actually stepped up to do the dev work and it it into production > > > > shape. Stopping the standard distro work won't miraculously make > > > > that > > > > other work happen and appear. > > > > > > Well, I kind of disagree. Barring magical people that appear out of > > > the woodwork that know how the tools work and how they need to be > > > improved, I don't see an alternative. Not doing a release to focus on > > > our tech debt seems like a good tradeoff. If there are others that > > > really WANT to continue cranking the release with the tools as they > > > are today... that might be something that could be pursued. It would > > > still require net new contributors to a critical area. > > > > We would need to engage with the team working on the compose tools and > > see what time they can dedicate to meeting Fedora's needs. Likely a > > end state needs to be defined. then the work can be scoped. > > There are a lot of assumptions wrapped up in these statements. I'm not > sure we should be assuming that delivery mechanisms ought to all be > tied to internal Red Hat teams. This might be a good opportunity for > us (meaning people variously assigned in both places) to think about > whether we should try to decouple more of our delivery side (compose, > push, etc.), while keeping a tight bond at the build/test side. Sure. We still either need more people or to drop existing things to cover that with the existing people. > The customers RH serves have specific expectations, and in part that > dictates how delivery tooling is done. Binding the community to that > may be counterproductive. This is especially true now that RHEL 8 Beta > is out -- it's the perfect time for us to be rethinking at that level. There are already a number of tools that are shared across Fedora and RHEL and I can tell you for a fact that many on the RHEL side would like to see the same or similar improvements that have been mentioned here. Let's start scoping the problems and solutions before we decide Fedora should go off and do it's own thing (again). I'm interested in evolving more than just tooling. I continue to want to see Fedora and CentOS coming together more closely, so that we can leverage both of the amazing communities these projects provide. If we do that, we should be scoping how to do release tooling effectively across both Fedora and CentOS, while still keeping RHEL in mind as well. Having 3 (or more) different implementations of compose and release tooling seems ridiculous. I'd like to get it down to a community version and then have RHEL additions for product specific things if possible, driven by RHEL stakeholders. That way we get an actual upstream/downstream relationship with our tooling in addition to our distro. josh _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
