[Mesa-dev] OT: Phabricator? (was: Re: [PATCH 1/2] glsl: enable 'shared' keyword also for layout qualifiers)

Kai Wasserbäch kai at dev.carbon-project.org
Fri Nov 13 06:52:48 PST 2015


Hi Emil,
Emil Velikov wrote on 13.11.2015 13:58:
> On 13 November 2015 at 09:14, Kai Wasserbäch <kai at dev.carbon-project.org> wrote:
>> Emil Velikov wrote on 12.11.2015 18:45:
>>> On 12 November 2015 at 15:36, Samuel Iglesias Gonsálvez
>>> <siglesias at igalia.com> wrote:
>>>> On 12/11/15 15:28, Timothy Arceri wrote:
>>>>> On 13 November 2015 12:22:39 am AEDT, "Samuel Iglesias Gonsálvez" <siglesias at igalia.com> wrote:
>>>>>> 'shared' was added in ARB_uniform_buffer_object and also used
>>>>>> in ARB_shader_storage_buffer_object.
>>>>>
>>>>> Hi Samuel,
>>>>>
>>>>> Shared for UBO and SSBOs is not a key word its just an identifier for a layout qualifier, are you sure you need to make it available for those extensions?
>>>>>
>>>>
>>>> Right. Please ignore this patch.
>>>>
>>> In this case, may I suggest that you tag the patch as Rejected (or
>>> similar) in patchwork [1]. Afaict there are quite a few patches in
>>> there from yourself and fellow colleagues. Any chance someone can go
>>> through them and change their status appropriately ?
>>
>> Since I'm reading this from time to time I was wondering whether Mesa wouldn't
>> be better served by Phabricator instance? Maybe Matt and Tom, who send in most
>> of AMD's patches for the AMDGPU backend in LLVM can weigh in here?
>>
>> I'm using Phabricator myself for a big project and I must say it's really neat.
>> Most status/meta updates can happen automatically as you commit your changes,
>> the review state is tracked properly and if a patch was rejected/abandoned that
>> is usually also clear from the state. Ie. in most cases there is no need to have
>> multiple people walk through the same list of patches/bugs etc.
>>
>> (Bonus: for switching over from a Bugzilla to Phabricator, there's a pretty big
>> precedent with complete porting tools: Wikimedia did that)
>>
> Regardless of how clever the tool is there is always some user
> interaction needed. Damien have been working on improving patchwork
> and I believe it will be working pretty neatly in the not too distant
> future.

sure, there'll always be some level of interaction. My point was, that
Phabricator allows me in my experience with it, to reduce the amount of direct
interactions with it.

Example: if I put up a new revision for review, I can do so with a command line
tool I use instead of a git push to some feature branch and a git send-email to
the list. If code owners are defined, these can get added automatically by the
system as subscribers/reviewers (Herald rules can do that too). If a change has
been reviewed I land it with my command line tool which automatically marks the
review correctly. If somebody has requested to do something differently I can
reply to the comments inline and/or update the change for review. It all feels
pretty natural. (See
<https://secure.phabricator.com/book/phabricator/article/differential/> and
<https://secure.phabricator.com/book/phabricator/article/arcanist_diff/> for
some details on that workflow.)

> Personally I'm not too fussed what we use - although the general
> question on X vs Y is a po-tay-to po-tah-to like case. To each their
> own :) Although I'd suspect that we can/should have a discussion on
> next XDC on topics such as these ?

I'm most likely not going to be at any XDC in the foreseeable future, but a
discussion about tools would probably best suited for a personal meeting.

Anyway, if there is more interest in Phabricator or this discussion I'm happy to
answer your questions off list or in a different thread. I'll stop posting in
this thread, since it is off-topic (sorry for that). Especially since I'm not a
major contributor to Mesa.

Cheers,
Kai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151113/69d00fbc/attachment.sig>


More information about the mesa-dev mailing list