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 <ngompa13(a)gmail.com> wrote:
>
>> On Mon, Feb 20, 2017 at 5:20 PM, Kevin Kofler
>> <kevin.kofler(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org