[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: grace note articulation
From: |
James |
Subject: |
Re: grace note articulation |
Date: |
Mon, 24 Dec 2012 17:46:52 +0000 |
Zefram,
On 24 December 2012 17:07, Zefram <address@hidden> wrote:
> James wrote:
>>It is as much work for you to upload your own patches to Rietveld
>
> That's a bit too Web 2.0 for my comfort. I'm not drinking the Google
> Kool-Aid.
Your choice, you don't have to have a gmail account, just a login to reitveld.
>
> I did have a go at your documented process. I'm happy enough with git-cl
> itself, but I found the code-review website deficient in usability.
Works perfectly for me and I am not a developer.
> (Suspect it's relying on non-standard browser behaviour, so that it's
> actually buggy for me, but websites aren't a great interface even when
> they work.)
I doubt that, it works on IE at my work, Firefox/Chrome and that
crappy browser that comes with XFCE at home and even on safari when I
am on the go.
> If there's some version of this process that I can drive
> from the command line (make git-cl do the "announce" part as well as the
> upload?), and doesn't require a One Account To Rule Them All, then I'll
> be happy to join in.
I'm not sure what you mean. The tracker which git-cl updates posts the
issue as patch-new including the link to Rietveld and an email to dev
and uploaded to Rietveld at the same time, then all patches that are
marked as patch-new get tested by automatic scripts and if they pass
they are marked as patch-review and then the devs will review the
changes. All comments are made in Rietveld and sent by email to you
via Rietveld. The tracker part is purely so we know what
bugs/enhancements are in process, idle or ready to push.
Usually no one bothers to review anything if the patch hasn't even
undergone basic make checks.
While it is not to everyone's cup of tea perhaps this is our patch
review procedure and it also means, for example, that people like me
and others who are not developers but can run commands in clis and
read websites can do all the boring grunt work, like watching emails
and posting bug reports or testing patches and making sure they have
been reviewed properly while actual developers spend their time fixing
and reviewing their own and other people's code.
It works well as far as I am concerned.
James