Re: Discussion: Moving away from Patchwork for Intel i915/Xe CI

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

 



On Wed, 05 Mar 2025, Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Mar 05, 2025 at 07:52:31PM +0200, Jani Nikula wrote:
>> > - For each new series on lore.kernel.org a bridge would create a PR by
>> > taking the latest mirrored drm-tip source, then applying a new series
>> > with `b4 shazam`.
>> 
>> There's a small catch here. Patchwork is currently more clever about
>> handling series revisions when only some of the patches in a series are
>> updated by way of replying to the individual patch. For example [1][2].
>
> FWIW, b4 does partial rerolls already. E.g., using your own example:

Yay, I upgraded to 0.14 and so it does. Thanks!

The point I made is moot, and I agree with Lucas that we should align
with what b4 does.

> 	$ b4 am -o/tmp 20250305114820.3523077-2-imre.deak@xxxxxxxxx
> 	[...]
> 	---
> 	  ✓ [PATCH v5->v6 1/6] drm/i915/hpd: Track HPD pins instead of ports for HPD pulse events
> 		+ Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> (✓ DKIM/intel.com)
> 	  ✓ [PATCH v5->v6 2/6] drm/i915/hpd: Let an HPD pin be in the disabled state when handling missed IRQs
> 		+ Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> (✓ DKIM/intel.com)
> 	  ✓ [PATCH     v6 3/6] drm/i915/hpd: Add support for blocking the IRQ handling on an HPD pin
> 	  ✓ [PATCH v5->v6 4/6] drm/i915/dp: Fix link training interrupted by a short HPD pulse
> 		+ Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> (✓ DKIM/intel.com)
> 	  ✓ [PATCH     v6 5/6] drm/i915/dp: Queue a link check after link training is complete
> 	  ✓ [PATCH v5->v6 6/6] drm/i915/crt: Use intel_hpd_block/unblock() instead of intel_hpd_disable/enable()
> 	  ---
> 	  ✓ Signed: DKIM/intel.com

Side note, I often pipe messages from my MUA (notmuch-emacs) to b4, as
it nicely parses the mails and picks up the message-id from
there. Overall it works great. However, b4 seems to err on the side of
writing color codes to pipes, and I get this as output:

---
  [32m✓[0m [PATCH v5->v6 1/6] drm/i915/hpd: Track HPD pins instead of ports for HPD pulse events
    + Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> ([32m✓[0m DKIM/intel.com)
  [32m✓[0m [PATCH v5->v6 2/6] drm/i915/hpd: Let an HPD pin be in the disabled state when handling missed IRQs
    + Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> ([32m✓[0m DKIM/intel.com)
  [32m✓[0m [PATCH     v6 3/6] drm/i915/hpd: Add support for blocking the IRQ handling on an HPD pin
  [32m✓[0m [PATCH v5->v6 4/6] drm/i915/dp: Fix link training interrupted by a short HPD pulse
    + Reviewed-by: Jani Nikula <jani.nikula@xxxxxxxxx> ([32m✓[0m DKIM/intel.com)
  [32m✓[0m [PATCH     v6 5/6] drm/i915/dp: Queue a link check after link training is complete
  [32m✓[0m [PATCH v5->v6 6/6] drm/i915/crt: Use intel_hpd_block/unblock() instead of intel_hpd_disable/enable()
  ---
  [32m✓[0m Signed: DKIM/intel.com
---

I haven't had the time to dig into b4 source on this, but it would be
great if it could automatically detect whether sending colors is the
right thing to do or not. Basically only emit color codes to interactive
terminals, unless forced also for pipes.

(Alternatively I could try to figure out how to enable colors on emacs
pipe output, but that's another rabbit hole...)


Thanks,
Jani.


-- 
Jani Nikula, Intel




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux