> On 5/19/20 01:40, Laszlo Ersek wrote:
>
> That seems strange. I have one rule per edk2-* list, for moving such incoming
> email into the appropriate list folder. That's all.
>
> While I read all the subject lines (skim all the threads) on edk2-devel,
> generally, if you share reviewer or maintainer responsibilities for some
> subsystem, then people posting patches for that subsystem are supposed to
> CC you explicitly, in addition to messaging the list.
I tend to make the assumption that people do not CC me on the patches that they
are supposed to CC me on. So I set up my filtering rules to do a deep
inspection of the message contents to see if it touches a package that I
maintain.
> Checking whether others have commented is near trivial if your MUA
> supports a threaded view.
>
> Checking whether a co-maintainer of yours has pushed a given series is also
> simple if they diligently report the fact of merging on the list (in the
> subject
> patch threads).
Yes, checking for comments is trivial. However, my fellow co-maintainers are
not very diligent on sending push notifications. So when I see comments from
one of my fellow co-maintainers I immediately ask myself the question: "Did
they already push this, and does it make sense for me to spend time reviewing
this patch series?" Answering that question involves a git pull and a review of
history in gitk to see what has been done already.
> I think this is not your job, as a reviewer/maintainer. Once your review is
> complete, or blocked on a question you need an answer to, the ball is back in
> the contributor's court. They can answer, or post the next version, whenever
> they see fit. Until then, the most they can expect of you is answering any
> further questions they might have for understanding your previous feedback
> better. You need not push contributors to complete their contributions.
I think my experience is colored somewhat here. I'd say more than half the
time, the contributor is another Intel employee. Often times, they are
contributing code changes that I asked them to implement. :)
> "State machine" is a very good analogy! Personally, I don't find it tiresome.
> Yes, it's important to recognize the events (= new emails) that trigger
> transitions between states. (For example: when I complete a review, when I
> get a new version of a series or a brand new series, when I get asked a
> question.) Once I recognize those events correctly, I just diligently massage
> said tags ("stars").
>
> And I keep iterating over my set of "starred" messages; I do actual work
> (e.g., reviews) in "bottom halves"; detached from new emails.
>
> I don't find this a burden as I have to manage my "real life" with task lists
> anyway. Without them, my real life would collapse in a week; so it's nothing
> unusual for me. (And no, I don't allow shady cloud-based automatisms to
> manage my life for me; I value my privacy way above my
> comfort.)
Agreed that I also keep my personal task lists in a paper notebook and manage
my real life list manually. However, my real life list is much smaller (since I
have most of the context in my head already)... and its private. Everything I
do on this mailing list is public anyway, so having some centralized service
keep track of state transitions doesn't bother me. The "bottom half" of that
state transition is going to generate a public email from my address, so it's
not like the current state of the state machine that I'm running in my head is
private.
Thanks,
Nate
> Thanks!
> Laszlo
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#59841): https://edk2.groups.io/g/devel/message/59841
Mute This Topic: https://groups.io/mt/74289183/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
