Re: efivar and mokutil long standing FTBFS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 13. 08. 19 19:43, Peter Robinson wrote:
> > Firstly they're just FTBFS in F-30.... This isn't exactly long
> > standing, if it was F-26 like some that were retired I could
> > completely understand that statement but F-30 is pushing the rhetoric
> > a bit here.
>
> It has been half a year without any response. Hence it is long standing.
> You may think that half a year is not long standing. Fine. Sorry for using that
> language when I should have said "6 months old" instead.
>
> >> efivar and mokutil fail to build from source. They have been retired, then
> >> unretired and they still fail to build from source.
> >
> > What do you mean by retired and unretired and still FTB?
>
> They have been retired as part of the FTBFS policy.
> Then they have been unretired and retagged because it broke the compose.
> Yet they still have not been rebuilt.

The retirement, which took me by shock and IMO wasn't well advertised,
happened while people were traveling to flock last Wednesday, and
people are still returning a week later. People also have deadlines
and real work to do and there's literally _SO_ much bugzilla mail from
all of this most people just mute it or out right delete it because
they can't damn well keep up [1]

[1] https://twitter.com/hughsient/status/1161382573228142594

> >> Following the policy:
> >> https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/
> >>
> >> I kindly ask the maintainers to rebuild them or orphan them if they cannot take
> >> care of them.
> >
> > Maybe you're not aware of this thing called RHEL-8, maybe the
> > maintainer has been snowed under and as they stand they work as
> > intended and it's not exactly a complete drama if they're not fixed
> > right away. Or maybe he's drowning in email from the 8+ pointless
> > repetitive bug updates that have been added to the bugs.
>
> I believe that if a maintainer doesn't have 5 minutes to say "I'm swamped with
> RHEL 8 (or whatever else), please, can somebody help me with those FTBFS" or
> even "I don't care" they are pretty much no-maintainers. Getting the FTBFS fixed
> in 6 months is not right-away. If you find the repetitive bug updates pointless,
> feel free to propose a better approach.

In some cases, and using these cases as a perfect example, they
require specialised information about low level things like UEFI,
secure boot, signing of core boot process where there's specialised
information and I don't even fill up a hand of fingers listing the
people that have this skill set and all of those people are so
overloaded with work that they actively prioritide stuff. This isn't a
basic python binding here.

> > I happen to know he's working on updates to them, but he also has
> > other priorities.
>
> I don't happen to know that. The lack of communication is making it hard. For
> what i know they are not even aware of this issue.

Well the deluge of a bazillion extra bug emails doesn't help TBH. I
have generally kept up with bug emails and this is now stressing me
out I'm probably going to quit!

> Don't we all have other priorities? Is it so hard to communicate about out
> priorities openly?

Yes! For some it is.

> > There really has to be a better way to deal with this, I spoke with
> > many people, that are drowning in pointless email, like weekly SPAM
> > reminders are really too much. One group I had a discussion with are
> > well aware of the problems of their FTB packages but have other
> > priorities and fix them when they get moments between the tidal waves.
> >
> > For example the OLPC/sugar stuff I do I'm slowly, as I and they get
> > time, training others up on the packaging/Spin side of things,
> > upstream is moving towards python3 and everyone is aware of this and
> > the issues involved, but while we do this we now have hours of extra
> > work to do because a whole bunch of the packages have been ripped out
> > from under us in the process without proper notification if you happen
> > to miss an email to devel, or in some of the people I'm working with
> > aren't even on devel. PLEASE make it stop.... I'm actually considering
> > stopping most of my work in Fedora because it makes me way too anxious
> > to continue and that coming from me is something, I'd really hate to
> > think how many silent contributors we're losing from this.
>
> Are you proposing to stop doing exactly what? Following policies? Having
> policies? Or is something that I personally am doing that I should stop? I
> gladly head proposals of how to make things better. But "PLEASE make it stop..."
> isn't really a constructive proposal.
>
> I realize that getting constant notifications is overwhelming. But when we don't
> do that, people are angry about "unannounced" breakage.

Well you can't currently see the forest for the trees and this
bullshit, for the first time in 15 years in making me think about
quitting the Fedora project, and I spoke with many at Flock are
seriously stressed about it and sick of it. I will be bringing this up
at council because this is not sustainable and whether it be by
retiring all of the packages because everything that depends on the
kernel is retired or scaring away all the part time contributors this
militant level of process is causing active harm to the project.

Peter
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux