why was meta-dlna submodule history stripped out?

why was meta-dlna submodule history stripped out?

[Tomas Frydrych]

Looking over meta-dlna in Yocto git I see it's little more than a fork
of meta-guacamayo from guacamayo-project.org -- could someone please
explain to me why the git history was stripped out from this 'combo' layer?

(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.)

I am also interested in knowing why the fork was deemed necessary in the
first place, just in case it was for technical reasons that could be
addressed at source.

Tomas

why was meta-dlna submodule history stripped out?

[Tomas Frydrych]

Looking over meta-dlna in Yocto git I see it's little more than a fork
of meta-guacamayo from guacamayo-project.org -- could someone please
explain to me why the git history was stripped out from this 'combo' layer?

(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.)

I am also interested in knowing why the fork was deemed necessary in the
first place, just in case it was for technical reasons that could be
addressed at source.

Tomas

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

[Saul Wold]

On 10/19/2012 07:33 AM, Tomas Frydrych wrote:
>
> Looking over meta-dlna in Yocto git I see it's little more than a fork
> of meta-guacamayo from guacamayo-project.org -- could someone please
> explain to me why the git history was stripped out from this 'combo' layer?
>
My apologies, I updated the MAINTAINER and README files.

> (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.

> I am also interested in knowing why the fork was deemed necessary in the
> first place, just in case it was for technical reasons that could be
> addressed at source.
>
In the first pass, there were mostly minor changes to cut this down to 
what was needed for the headless media server. 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. If you want some of those changes in 
meta-guacamayo please take them.

My goal is to make the meta-dlna be more cut down and not require the
as much. If we can accomplish that directly with meta-guacamayo that 
would be awesome.

Right now I am fighting a dbus/rygel segfault.

Sau!

> Tomas
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

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

[Paul Eggleton]

On Friday 19 October 2012 11:01:09 Saul Wold wrote:
> On 10/19/2012 07:33 AM, Tomas Frydrych wrote:
> > (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.

This is the default behaviour of combo-layer, on the assumption that most 
people don't want all the history from the very beginning. It is not clearly 
documented but there is a simple procedure you can follow to set up the combo 
repo if you do want complete history:

1) Instead of combo-layer init, run git init

2) Create conf/combo-layer.conf based on the template configuration 
(scripts/combo-layer.conf.example) ensuring last_revision is blank for all 
components

3) git add conf/combo-layer.conf, then git commit

4) Run combo-layer update

> > I am also interested in knowing why the fork was deemed necessary in the
> > first place, just in case it was for technical reasons that could be
> > addressed at source.
> 
> In the first pass, there were mostly minor changes to cut this down to
> what was needed for the headless media server. 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. If you want some of those changes in
> meta-guacamayo please take them.

In the same way we manage the poky repository, at least as far as the master 
branch is concerned I think we should be sending the fixes back upstream first 
and then using the combo-layer tool to pull them back down when they are 
merged.

Long term however I'd rather see the additional unique recipes in meta-
guacamayo itself go into more official OE community layers. meta-dlna would 
continue to take them from there using combo-layer though I suspect. (This is 
the plan I have for meta-baryon.)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Ross Burton]

On Saturday, 20 October 2012 at 13:16, Paul Eggleton wrote:
> Long term however I'd rather see the additional unique recipes in meta-
> guacamayo itself go into more official OE community layers. meta-dlna would
> continue to take them from there using combo-layer though I suspect. (This is
> the plan I have for meta-baryon.)

Agreed.  I've been attempting to push the obvious fixes to packages in oe-core back there, and meta-oe/meta-multimedia is an obvious home for the bulk of the rest.  Guacamayo should ideally be an integration and customisation home consisting of bbappends and guacamayo-specific recipes only, IMHO. 

Ross

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

[Tomas Frydrych]

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

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

[Tomas Frydrych]

On 20/10/12 13:16, Paul Eggleton wrote:
> On Friday 19 October 2012 11:01:09 Saul Wold wrote:
> Long term however I'd rather see the additional unique recipes in meta-
> guacamayo itself go into more official OE community layers.

Ah, so there is an official community and an unoffical one, this
community stuff is becoming rather difficult. ;-)

I don't have any objections in principle, in fact you will see that
number of the recipes in meta-guacamayo consists of a generic recipe and
a guacamayo-specific bbappend. The main reason for maintaining most of
the recipes in meta-guacamayo is precisely so that they would be
maintained and updated in timely fashion and work with the stable
release of Yocto. Guacamayo aims to facilitate that.

Tomas

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

[Paul Eggleton]

On Monday 22 October 2012 09:06:41 Tomas Frydrych wrote:
> On 20/10/12 13:16, Paul Eggleton wrote:
> > On Friday 19 October 2012 11:01:09 Saul Wold wrote:
> > Long term however I'd rather see the additional unique recipes in meta-
> > guacamayo itself go into more official OE community layers.
> 
> Ah, so there is an official community and an unoffical one, this
> community stuff is becoming rather difficult. ;-)

I was referring to the meta-openembedded repository on openembedded.org. If 
people are looking for recipes they're going to be looking for them there first 
- surely it would be better that they'd find them there rather than just 
assuming they haven't been written and writing new ones themselves...?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre