[flashrom] Re: master state / potential release

2022-10-18 Thread Anastasia Klimchuk
The initial list of tickets for the release was created from Nico’s
list of issues to check before the release. (see earlier thread about
the release). Some of these are bugs, some others were in the form
“what do we do with this?”. I understand that since a few months ago
things could have changed, and if as of today we all look at the list
and we all feel like some of the tickets are not blocking release,
that’s fine. We can unlink them from parent 353 and just leave in
bugtracker as a ticket.

Re: bug vs feature and other fields. Please change to whatever you
feel is more appropriate. It doesn’t matter for me which type the
ticket has. Important info for me is parent ticket (or absence of it)
and clear description.

As I posted at that time on the mailing list in “Release preparations”:
> Surely all of the descriptions can be improved, or more info can be added to 
> issues. Especially if you are taking an issue and start working on it.

We can also go once again through the list and decide whether all the
remaining ones are indeed blocking. We can do this on 2rd November UTC
(next scheduled flashrom meeting).

> Even though we (Angel) are not licensed therapists, we are willing to listen 
> to you.
Angel, thank you so much! This is really nice of you! It is so
important to support each other.
I think I am fine. I am very lucky to have a great team at work, and
great upstream teammates!
But I am on the channel as usual :) Surely we will talk!

-- 
Anastasia.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org


[flashrom] Re: master state / potential release

2022-10-18 Thread Richard Hughes
On Tue, 18 Oct 2022 at 16:25, Angel Pons  wrote:
> Maybe it's not intentional, but your email sounds rather unpleasant
> and very confusing. What would you like to achieve?

I have no agenda, I'm just sick of seeing all the behaviour on this
list. There's a certain toxicity.

> Also, out of curiosity, did you see
> https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/message/65BNRWRTKLTMS7EDOGCN2NJYIFX5QXBV/
> before writing your reply?

Yes, I saw that.

> Let's make sure we're on the same page, as misunderstandings have
> already costed the flashrom project way too much time and effort.
> Could you please explain what "at scale" means for you?

More than 10,000 users.

> Um, this is not true. There are people out there using flashrom on DOS

I'm sure there *are* people using flashrom on DOS but I'm not sure
it's something you should optimize a project for.

> Also... Doesn't fwupd use flashrom?

Yes, but in the same way as Google; i.e. we only allow-list specific
hardware (that we test) that uses the internal programmer for a subset
of SPI chips. All the other fwupd functionality is native as the
impedance mismatch between fwupd and libflashrom is striking. We did
play with using other programmers but it didn't work very well.

> > Normal people don't use flashrom in
> > production in any appreciable number.
> Hmmm, this seems to be another potential source of misunderstandings.
> What do you mean with "in production"?

Not on a test system, i.e. one with paying customers. StarLabs
probably wins here, but they're one of the systems we do end-to-end
testing with.

> Who do you think is responsible for flashrom, then? Whose
> responsibility is flashrom?

Well it's not mine: I'm seeing hostility, ego and stop energy -- and
that's not a place I really want to be.

Richard.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org


[flashrom] Re: master state / potential release

2022-10-18 Thread Angel Pons
Hi Richard,

Maybe it's not intentional, but your email sounds rather unpleasant
and very confusing. What would you like to achieve?

Also, out of curiosity, did you see
https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/message/65BNRWRTKLTMS7EDOGCN2NJYIFX5QXBV/
before writing your reply? Maybe you missed it. Perhaps you'd want to
read it: the first paragraph contains information that seems to
contradict some of your claims. It could be that we're talking past
each other.

On Tue, Oct 18, 2022 at 2:50 PM Richard Hughes  wrote:
>
> On Tue, 18 Oct 2022 at 14:22, Nico Huber  wrote:
> > Regressions can be much more severe though, and with the cur-
> > rent development the story might look like: "sorry for the regression!
> > you may have to acquire a hot-air soldering station now to fix your PC.
>
> I don't think that's true. The only people using flashrom at scale is
> Google,

Let's make sure we're on the same page, as misunderstandings have
already costed the flashrom project way too much time and effort.
Could you please explain what "at scale" means for you?

> and they're quite certainly testing every flashrom version
> with every firmware version with every hardware version before
> deploying anything.

Yes, Google most likely checks that flashrom works for *their*
use-cases before deploying anything.

> In the community the only people _really_ using
> flashrom are the ones with SPI clips and screws already removed, if
> we're being completely honest.

Um, this is not true. There are people out there using flashrom on DOS
to update their BIOS, and a significant number of users who come
asking for help on IRC don't even know what a SPI clip is. Do you mean
that these people are not _really_ using flashrom?

Also... Doesn't fwupd use flashrom? Do all fwupd users have a SPI clip
at hand, in case something goes wrong? It would be interesting to know
how fwupd handles the possibility of device(s) no longer booting after
a failed firmware update.

> Normal people don't use flashrom in
> production in any appreciable number.

Hmmm, this seems to be another potential source of misunderstandings.
What do you mean with "in production"?

> > Because I've seen it burning out people (including
> > myself) when one tries to clean up behind others, I argue against fixing
> > bugs that other people introduced.
>
> But flashrom isn't your baby, it's not your responsibility. Advice
> yes, being condescending no.

Huh, why do you say so?

Who do you think is responsible for flashrom, then? Whose
responsibility is flashrom?

> Richard.

Best regards,
Angel
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org


[flashrom] Re: master state / potential release

2022-10-18 Thread Richard Hughes
On Tue, 18 Oct 2022 at 14:22, Nico Huber  wrote:
> Regressions can be much more severe though, and with the cur-
> rent development the story might look like: "sorry for the regression!
> you may have to acquire a hot-air soldering station now to fix your PC.

I don't think that's true. The only people using flashrom at scale is
Google, and they're quite certainly testing every flashrom version
with every firmware version with every hardware version before
deploying anything. In the community the only people _really_ using
flashrom are the ones with SPI clips and screws already removed, if
we're being completely honest. Normal people don't use flashrom in
production in any appreciable number.

> Because I've seen it burning out people (including
> myself) when one tries to clean up behind others, I argue against fixing
> bugs that other people introduced.

But flashrom isn't your baby, it's not your responsibility. Advice
yes, being condescending no.

Richard.
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org


[flashrom] Re: master state / potential release

2022-10-18 Thread Nico Huber
Hi Richard,

thanks for your thoughts. This has woken some more ideas in my mind,
how to express current flashrom troubles.

On 17.10.22 11:26, Richard Hughes wrote:
> Certainly aiming to do releases monthly is much healthier than doing
> releases every few years. I think it's much more achievable to set the
> expectation to the end user "sorry for the regression! it'll be fixed
> in your distro in ~3 weeks, in the meantime use the previous release"
> than trying to squash every bug and add all the features before
> tagging a mythical beautiful bug-free "feature complete" release.

I very much agree to a shorter release cycle. Maybe not monthly, but
every 3 months would be worth a shot, IMO. When we still did releases,
it was about 1 per year. But back then we had little time to spare for
releases. Regressions can be much more severe though, and with the cur-
rent development the story might look like: "sorry for the regression!
you may have to acquire a hot-air soldering station now to fix your PC.
when you are done, please try to help us to debug the issue. although,
even if you do, we may not fix the issue in a release if there's a
chance that something would regress for a flashrom stakeholder.". So
to say, we have other problems that need to be addressed before we can
dream about a release cycle.

The problems seem to run very deep. It's not easy to put into words.
I'll try to sketch one thought briefly as I don't have much time: One
issue is a denial of service on many levels. One level (kind of my DoS)
is the bug fixing. Because I've seen it burning out people (including
myself) when one tries to clean up behind others, I argue against fixing
bugs that other people introduced. This has went so far that I even
stopped pushing reverts for others. Because last time I pushed a revert
of a three-line patch with three flawed lines, people made a drama of
it.

Nico
___
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org