Re: new commitfest transition guidance

Hi,

> > What if we automatically move any patches to the current commitfest if new
> > patch attachments are sent to the corresponding message thread? Heck,
> > perhaps if there are any new messages *at all* in the message thread, and
> > the commitfest entry has not been closed already, we should move it to the
> > current commitfest.
>
> +1 ... this would go a long way towards reducing the manual effort
> needed to maintain these things.
>
> > We could even have commitfest respond to the message
> > thread to inform when automated actions of this nature have been taken.
>
> Dunno that we need automated mail about it though.
>
> (I don't care for the other idea of not having dated CFs at all.
> That would mean that an entry never disappears unless manual action
> is taken to remove it. Making untouched threads silently age out
> seems like the better path forward.)

Perhaps we should consider the other way around. All the patches are
moved to the next CF automatically, as we did before. Except for the
cases when there were no updates for a certain amount of time (e.g. a
few months). In this case the application sends an email to the
corresponding thread notifying that the CF entry was closed due to
inactivity, but if this was done by mistake feel free moving it by
hand to the upcoming CF.

I believe this would be more productive / convenient. In certain cases
it may take a couple of months to get attention from the reviewers and
the patch doesn't necessarily need a rebase during this time period.
This is a normal situation. However if there was no activity in the
thread for several months this indeed is a good indicator that
something is off.

Even if the application closes an entry by mistake few of the authors
have dozens of simultaneously open entries, so reopening an entry or
two several times a year doesn't take too much effort. In all other
respects the proposed approach is not worse than what we did until
now.

--
Best regards,
Aleksander Alekseev