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
