Re: why was meta-dlna submodule history stripped out?

[Tomas Frydrych <tf+lists.yocto@r-finger.com>]

Hi Saul

On 19/10/12 19:01, Saul Wold wrote:
> My apologies, I updated the MAINTAINER and README files.

Thanks.

>> (I am delighted Intel is finding Guacamayo useful, but the obliteration
>> of the history makes it look as if the credit for this official Yocto
>> layer goes to Intel; I am sure that was not intentional.)
>>
> No this was not intentional, the combo-layer tool seems to do that. I
> used combo layer because we wanted to pull in the kvm changes so that
> this could be shown as a VM.

Well, Poky uses the combo-layer and it maintains the commit history,
even nicely injects the original hashes into the commit messages for
reference. My basic gripe is that the 'Initial meta-dlna creation'
commit squashes some 370+ commits, which represent somewhere in the
region 500 man hours, bulk of it by sleep(5) ltd. I'd prefer if a public
layer in a Linux Foundation collaborative project did not do away with that.


> In the first pass, there were mostly minor changes to cut this down to
> what was needed for the headless media server.

This is the bit I don't get; it's not like oe-core contains just what is
needed for poky-tiny, but I don't see you creating an oe-core fork for
it. In fact this makes so little sense I doubt it was an engineering
decision, perhaps someone somewhere forgot to take their NIH pills? :)


> As I moved to 1.3 there
> were more changes that I have made, you can see what's going on in the
> 1.3wip branch of meta-dlna. 

You are already getting bitten by the fact that you are forking
meta-guacamayo. Upstream master has been updated to work with 1.3 some
time back. It took fair amount of work to do (more than I'd have
expected; lot of work to get things to build, and then quite a bit more
to get them work).


> If you want some of those changes in meta-guacamayo please take them.

Why is Intel so crap at working with upstream projects? I'll happily
take any meaningful contributions (that excludes adding
MACHINE_FEATURES='x86' into the layer.conf, though!), but please submit
them.


> Right now I am fighting a dbus/rygel segfault.

I am pretty sure I know which one, you are welcome to update to upstream
meta-guacamayo, forks really are not a cost-efficient way of doing things.

Kind regards,

Tomas