[coreboot] [PATCH] flashrom: Group probe function together with ID
peter at stuge.se
Sat Apr 11 16:38:23 CEST 2009
Carl-Daniel Hailfinger wrote:
> >> clean design
> > Not now. Please submit your full series of patches to trac, against
> > the 1.1 milestone.
> These patches are just a refresh of a series which is almost 6
> months old.
Ok. Please create new tickets as neccessary and attach those patches
so that they are not lost on the mailing list again.
Without git I don't like email so much for patch management. And even
with git I don't have any experience of working like that, but I
suppose it is easy and efficient.
> Nobody cares about flashrom 1.0 enough to actually fix the
> remaining design and user interface problems:
> - The short command lines switches have no decided upon capitalization.
> - Switch combination may lead to accidental ROM content destruction
> (great feature!).
Does this have a ticket? Maybe related to #103?
> - No way to test flashrom functionality with a single command.
> - Unclean generic matching handling.
> - We claim a generic match has unknown read, write, erase, probe results
> although read, write, erase do fail. I have a patch for this, but it has
> not been committed.
I don't think these two have tickets.
Thank you for bringing up these points! Please add the tickets that
are missing, I think all of these issues at the very least deserve to
be decided on, with afterthought, before 1.0. All of them may not
actually be resolved for 1.0, but we should go over them.
Let's continue using trac for this, please.
> And now means in the next 7 days, otherwise it will drag on longer
> and longer until someone is frustrated enough to simply release the
> current tree as 1.0.
I think that concern is unfounded. I certainly hope so. Meanwhile,
please do put the new tickets into trac and let's take care of them
one by one.
Some tickets could definately be re-opened, they may have been closed
prematurely. I've reopened 100 and 106 but don't have a real overview
right now, so there may be more candidates.
> Speaking of flashrom operation modes, only the following make sense
I agree with this, except for two things as noted in #106.
> The autoerase on write functionality (which is not present for all
> chips) needs to be decided upon as well.
> Can we please fork an 1.0 branch and continue development on trunk?
Hm? Would trunk be the redesign? Does it make sense to fork before
1.0 is finished? I think it could - if enough things will change.
More information about the coreboot