Dne 21.2.2017 v 01:31 Ralf Corsepius napsal(a): > On 02/21/2017 01:09 AM, Kevin Fenzi wrote: >> On Mon, 20 Feb 2017 18:24:21 -0500 >> Neal Gompa <ngomp...@gmail.com> wrote: >> >>> On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler >>> <kevin.kof...@chello.at> wrote: >>>> Dennis Gilmore wrote: >>>>> I do not get what you mean by your statement, it is extremely vague >>>>> with no detail. can you please expand on it in the context of the >>>>> change? and the changes it will bring to the entire workflow of >>>>> rawhide? >>>> >>>> Rawhide is just nowhere near working, half the packages have broken >>>> dependencies due to not building with the latest GCC. >> >> Thats a bit over dramatic don't you think? > No. I fully agree with Kevin K. > > Feb 15 rawhide is 100% dysfunctional. > >> 968 currently on the FTBFS list, and even there many of those don't >> have broken deps because the previous build still works. > Many of the packages you are referring to probably are parts of dep > chains, which gradually get fixed or have been missed during the > official "mass-rebuild". > > What you are missing: Due to you keeping the package having been > rebuilt since Feb 15 behind closed doors, NOBODY outside RH can have > tested them and is able to go after run-time bugs these package > introduce.
Come on. Outside or inside RH, we are on the same boat. There are problems which needs to be resolved. I don't understand why you paint it as some conspiracy. Vít > >>> I also wonder if we're thinking about this problem all wrong. What if >>> the answer isn't to increase the friction in Rawhide, but instead to >>> create a regular output stream that people can use to be above >>> releases? That's more or less how Tumbleweed works, as it's >>> essentially snapshotted and published from Factory when it "checks >>> out" via the OpenQA gate. Now, OBS has the nice ability of being able >>> to have granular control of how publishing actually works. I think the >>> way Koji's tagging mechanism works may provide a similar capability, >>> and we could leverage that to produce something like mattdm's >>> oft-wanted "Fedora Bikeshed". >> >> I think we can have a more stable rawhide without going to a higher >> level here. > > I do think we can do better on details, but I consider the whole idea > of a "stable rawhide" to be self-contractory and naive, because it's > current rawhide job to be "broken". > > IMO, what you are doing basically is trying to render rawhide into a > "rolling release" (A non-sense of its own, IMO) and to shift rawhide > out of the public (== community) > > Ralf > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
