> > > On 21 Jul 2017, at 12:41, Frediano Ziglio <fziglio@xxxxxxxxxx> wrote: > > > >> > >> On Fri, Jul 21, 2017 at 06:18:49AM -0400, Frediano Ziglio wrote: > >>> Beside that I wonder why I had to wait 8 months for these reviews, > >>> not counting the time to decide to rewrite this part of code > >>> (with all the wasted time trying to not do it) and the time we > >>> waited to fix a known bug which is also a regression (image copy > >>> paste are not working) and potentially a security risk (the library > >>> versions used contain security bugs but actually the code is disabled). > >>> Looks like that if a Red Hat client is not pushing for a fix > >>> solutions are not that important. > >> > >> People can be busy with other things, and patches can fall through the > >> cracks, it's ok to send a 'ping' message once in a while to bring a > >> patch series back to people's attention. > >> > >> Christophe > >> > > > > I'm really getting tired of this reply.. > > Hmmm, maybe we can do a few things to reduce that problem. > It would be nice if we had a way to get back to unreviewed patches > without having to browse through the mailing list. > > Also, as a newbie, I must say I often spend quite some time finding > the base for a patch, which is a shame, because that’s a problem > that git URLs solve quite nicely. The problem is amplified by the > fact that we have multiple components, and patches sometimes > don’t really specify which component they apply to. > > So maybe we can fix the two problems with one stone. What about > > 1. Pushing branches for review under a consistent name, e.g. something > like ‘review/c3d/recorder’ > > 2. Adding the git URL in the patch, e.g. > https://cgit.freedesktop.org/spice/spice-gtk/log/?h=review/c3d/recorder. > > 3. Once the patch has been committed, simply do a ‘git push freedesktop > :review/c3d/recorder’ > to delete the branch. > > > I see several benefits to doing this: > > 1. We always know exactly which component and branch is being patched > > 2. When you work on branch, a daily “git fetch” will fetch all the new > “review” > branches, so a simple git branch -a will show you what needs to be reviewed. > > 3. If you want to test, a git checkout is enough to test (assuming you did > the git fetch above). Simpler IMO than git am (even if I assume most of us > have scripts to process incoming mail) > > > Do you think something like this would help? > Would help but who/where should we track the external/personal repository? We would need to track even upstream contributions. This would help with keeping the patches updated. Not with list of pending changes. Frediano _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel