[Mesa-dev] RFC: Prune stale components

[Emil Velikov]

On 3 March 2015 at 12:15, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 03/03/15 11:59, Emil Velikov wrote:
>>
>> On 3 March 2015 at 09:36, Jose Fonseca <jfonseca at vmware.com> wrote:
>>>
>>> On 28/02/15 00:24, Rob Clark wrote:
>>>>
>>>>
>>>> On Fri, Feb 27, 2015 at 5:05 PM, Emil Velikov <emil.l.velikov at gmail.com>
>>>> wrote:
>>>>>>
>>>>>>
>>>>>> - src/gallium/drivers/rbug: -- do people use it? does it work?  it
>>>>>> predates apitrace GL + GUI, which sort of enables a lot of the same
>>>>>> things, but without the issue of having to hit moving target, which is
>>>>>> what gallium interfaces are
>>>>>>
>>>
>>> So it looks from the replies that rbug and rbug-gui is still useful.
>>>
>>>>> If we're going to keep this should we move the rbug-gui tool within the
>>>>> mesa tree ? It would be nice to spare some of the "sigh... it does not
>>>>> build" and let you guys just use it.
>>>>
>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>
>>> It sounds a good idea FWIW.  I believe that rbug-gui depends on the
>>> gallium
>>> interface, and we don't maintain backwards compatibility, so moving it
>>> rbug-gui into somewhere like src/gallium/tools/ and have it built by
>>> default
>>> should enable to keep it in sync more easily.
>>>
>> Indeed that was the reason I brought it up.
>>
>>> That said, integrating rbug-gui into Mesa tree is beyond my immediate
>>> goals/needs.  So I'll let those who do use rbug + rbug-gui to take that
>>> task
>>> on.
>>>
>> Ouch... did not mean to come across as "you should do it" or anything
>> along those lines.
>
>
> No prob.  I just want to make sure that, by agreeing, I wasn't volunteering
> :)
>
>> I'll need to read up a bit on how to preserve the
>> history, but it's already on my list :-)
>
>
> I tried to do that sort of "git-history-rewriting/spliting" acrobatics in
> the past. And I have mixed feelings from my experience: being able to do
> `git blame` on the new tree is indeed nice, but it's hard to get the history
> right, in particular it's pretty hard to ensure that things build at
> arbitrary commits, which can create troubles when bisecting (particularly
> because there is no option for "git bisect --ignore-changes-in-this-path
> src/gallium/tools/rbug-gui"...)
>
> The alternative would be to make http://cgit.freedesktop.org/mesa/rbug-gui/
> read-only, or just slap a big notice in description/read-me saying "this
> code is unmaintained and moved to XYZ", import rbug-gui as a single commit,
> and mention which rbu-gui commit this was taken from in the mesa commit
> message.
>
As a learning exercise I've went ahead with the git filter-branch acrobatics.
Afaict things should be perfectly bisect-able as I've intentionally
removed the history of configure.ac and Makefile.in.

The whole thing seems to build like a charm, but I cannot get it
running (something funny is happening between GTK and QT). Can someone
give it a try ?

The series can be found in branch rbug-gui-import at
https://github.com/evelikov/Mesa/.
Should I spam the list with the three patches first one of which adds
4000 lines of code ?

Cheers,
Emil