Hi Jani,
On Mon, Jun 19, 2023 at 4:30 PM Jani Nikula <jani.nikula@xxxxxxxxx> wrote:
> [Trimmed the recipients considerably; there's really no need to keep
> spamming so many people about this.]
CC sfr
> On Mon, 19 Jun 2023, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote:
> > Not knowing dim I think there is a simple(?) technical solution here: It
> > only has to make sure that after the pull request from drm-misc to drm
> > was sent, no new patches are added to the branch that is merged in next.
>
> The drm-misc-next and drm-intel-next branches are *always* open to
> patches, regardless of the merge window. That's not going to change. We
> never tell people "this is not the right time for your patches" due to
> the merge window, like some subsystems do.
Good (personally, I don't like it when a subsystem is not open to patches,
as it means that when I finally have time to work on patches myself, I
cannot submit them ;-)
> We have separate branches specifically for feeding to linux-next and
> they serve no other purpose. The tooling tries to push the right thing
> there, depending on the last pull request cutoff, so that linux-next
> reflects what it's supposed to, but obviously the tooling doesn't have
> the smarts to figure out when the last pull request is going to be
> sent. (Really, humans don't always get that right either, because
> predicting the future is kind of hard.)
OK. So all of this was a genuine mistake...
> Looks like you hit an issue, and although nobody else has complained
> about this one over the 9 years we've been using dim, it royally
> confused you. Sorry about that. There's always room for improvement in
> the tooling, in the process, and in the human communication.
Thanks for the explanation!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
