Hi Peter,
I want to apologize if it seemed that I asked you to hold back on any
effort, especially some not directly related to day-to-day tasks, I
did not mean anything like that. [...]
That said, of course it would be great if more developers try the
new submit strategy and see how they feel
Felix Held wrote:
> I can let other developers with submit right try out the new submit
> strategy and not submit anything that's not directly related to
> what I'm working on right now.
I want to apologize if it seemed that I asked you to hold back on any
effort, especially some not directly
Hi Martin and Peter,
sure, I can let other developers with submit right try out the new
submit strategy and not submit anything that's not directly related to
what I'm working on right now. I mainly started looking through the
submittable patches and submit them when I don't spot anything
Martin Roth via coreboot wrote:
> If we continue with this method (and for the rest of this month), I
> think we want to encourage shorter patch trains, consisting of only
> related patches.
Ouch! Yes please, for sure, regardless of the submit strategy.
> Currently, it seems like projects will
Felix,
If you've formed an opinion, maybe you want to take a break from submitting
for a bit to let others test out the new submission strategy?
For everyone else, I'd like to note that over the past year, Felix has hit
submit on more than 45% of all of the coreboot patches that have been
Hi Peter,
By "keep an overview" I mean to know which commits in a pushed branch
that have been reviewed and which not.
Ah, ok; I'd assume that Gerrit won't allow pushing a series of patches
if one patch in there doesn't have +2 and +1 verified yet. Haven't
verified this though.
I'm all
Felix Held wrote:
> > Maybe the patch train is too long if it becomes hard to keep an overview?
>
> I'd say that it always better to have to look at all the individual
> patches instead of just looking at the bigger picture
I agree completely, and don't want to suggest otherwise!
By "keep an
Hi,
I reread the documentation and the thing I missed in there is that
Gerrit will only automatically rebase a patch when submitting when none
of the files it changed have been changed between the parent commit of
the to be submitted patch and the current top of tree. At least this
explains
Hi Peter,
I definitely want to submit a patch train patch by patch and not just
the last submittable patches including all patches before to make sure
that I looked at each individual patch when submitting.
Maybe the patch train is too long if it becomes hard to keep an overview?
I'd say
Felix Held wrote:
> I definitely want to submit a patch train patch by patch and not just
> the last submittable patches including all patches before to make sure
> that I looked at each individual patch when submitting.
Maybe the patch train is too long if it becomes hard to keep an overview?
Hi Patrick,
When going through the list of submittable patches i ran into a two
problems and also got a question:
When a patch before other patches gets abandoned, those patches can no
longer be submitted. Example: CB:66324
When submitting the first patch of a patch series, somehow the
Hi everybody,
22. Juli 2022 16:56, "Patrick Georgi via coreboot"
schrieb:
> On August 1, I'll change the coreboot repo to use that submission strategy
> and then we'll have a
> month to see how it works for us. Late August we can make a decision whether
> to stay with Rebase
> Always or to
Hi Peter!
Hmm, I'm not sure about that? I understand the effective difference
with the new strategy to merely be that a later commit in a pushed
changeset/branch can't be submitted before an earlier one.
That is my understanding of this too. What I wanted to point out in my
last email is
Felix Held wrote:
> Having a commit queue or even running a build test for every patch
> before it gets submitted would catch more breakages before the patches
> land in the tree than switching to the new submit strategy,
Hmm, I'm not sure about that? I understand the effective difference
with
Hi,
even though I'm not completely convinced that the advantages of this new
submit strategy will outweigh the disadvantages for me, I agree that it
would be good to try the always rebase strategy for a month and see how
well it'll work in practice.
Having a commit queue or even running a
Hi again,
On 2022-07-13 I wrote:
> David proposed that we could try out "rebase always" for a while (maybe a
> month) to see how it
> feels.
This idea has been positively received on the list and nobody voiced objection
to such a change.
As a server admin I declare that August will be
I like it. We do this on most of my other projects.
On Thu, Jul 14, 2022, 6:12 AM Peter Stuge wrote:
> Patrick Georgi via coreboot wrote:
> > I was recently made aware that Gerrit now supports adding metadata to
> > commit messages in the "rebase" strategy.
>
> That's cool!
>
>
> > It's a
Patrick Georgi via coreboot wrote:
> I was recently made aware that Gerrit now supports adding metadata to
> commit messages in the "rebase" strategy.
That's cool!
> It's a matter of trade-offs, but given that "rebase always" can now add the
> metadata that was the deal breaker for anything but
18 matches
Mail list logo
