'milkymist' group in comps?

[Bill Nottingham]

1) When you added this to F14/F15/EL6, you added a typo; this
broke the F-14 branched compose and the EPEL updates push.
*Please* verify your changes before pushing.

2) Aside from that... how does this merit a separate group?

- We already have the electronic lab group
- If we add a group each for developing for any embedded/custom
  board, we're going to run into group explosion really quickly

Bill

[Chitlesh GOORAH]

On Mon, Oct 11, 2010 at 9:42 PM, Bill Nottingham <notting(a)redhat.com&gt; wrote:
>  1) When you added this to F14/F15/EL6, you added a typo; this
>  broke the F-14 branched compose and the EPEL updates push.
>  *Please* verify your changes before pushing. 
Sorry I missed it

>  2) Aside from that... how does this merit a separate group?
>
>  - We already have the electronic lab group
>  - If we add a group each for developing for any embedded/custom
>   board, we're going to run into group explosion really quickly 
Well it does merit a separate group and we differ in terms of goals.

Fedora/Free Electronic Lab focuses primarily on ASIC design. We were
pretty bad in terms of knowhow in the embedded environment, until
Shakthi joined us. Hence our solutions for embedded tool are
improving. But our FEL goal is not only provide to but also to foster
a community around it.

Milkymist community builds and enhance their own toolchain (currently
not fully supported by Fedora). They have contributors who contribute
for tools such as gcc, qemu, other libraries (too software for FEL
goals). They have many patches that need to push to upstream.
Milkymist founder and I believe that we can collaborate as the
milkmist community is situated between FEL and Fedora, in terms of
tools and upstream patch-push. It is a win-win situation for everyone.

Having a separate group will prevent flooding ASIC engineers (existing
FEL users) with non-useful tools. Having a separate group will
strengthen RedHat/Fedora focus on patch submission for important tools
such as gcc, qemu,.....

In short, that was it. It's sad though you can differ FEL goals from the rest.

Chitlesh

[Bill Nottingham]

Chitlesh GOORAH (chitlesh.goorah(a)gmail.com) said: 
>  Milkymist community builds and enhance their own toolchain
> (currently
>  not fully supported by Fedora). They have contributors who contribute
>  for tools such as gcc, qemu, other libraries (too software for FEL
>  goals). They have many patches that need to push to upstream.
>  Milkymist founder and I believe that we can collaborate as the
>  milkmist community is situated between FEL and Fedora, in terms of
>  tools and upstream patch-push. It is a win-win situation for everyone. 
OK, that's clear. But I am worried that if we go down this road, we'll
eventually have 20 or 30 groups for different SoCs for embedded use,
and that seems like it will eventually be problematic. Is there some
generic moniker that could be used for this usage?

Bill

[Chitlesh GOORAH]

On Tue, Oct 12, 2010 at 8:23 PM, Bill Nottingham <> wrote:
>  OK, that's clear. But I am worried that if we go down this road,
> we'll
>  eventually have 20 or 30 groups for different SoCs for embedded use,
>  and that seems like it will eventually be problematic. Is there some
>  generic moniker that could be used for this usage? 
To be honest that would be a great idea. But I don't know any other
active and vibrant community like milkymist and openmoko alike. I
suggest that, let it be like this. If it gets momentum and other HW
communities pop in, we can rename it, I won't object.

> From a strategy perspective, let's bring forces together and show
> that 
this model works. It does, then good for us and our efforts brought
several communities into our wagon. What do you think, let it be its
roadmap ?

regards,
Chitlesh

[Bill Nottingham]

Chitlesh GOORAH (chitlesh.goorah(a)gmail.com) said: 
>  > OK, that's clear. But I am worried that if we go down this
> road, we'll
>  > eventually have 20 or 30 groups for different SoCs for embedded use,
>  > and that seems like it will eventually be problematic. Is there some
>  > generic moniker that could be used for this usage?
>  
>  To be honest that would be a great idea. But I don't know any other
>  active and vibrant community like milkymist and openmoko alike. I
>  suggest that, let it be like this. If it gets momentum and other HW
>  communities pop in, we can rename it, I won't object. 
Works for me.

Bill

[Przemek Klosowski]

On 10/12/2010 02:23 PM, Bill Nottingham wrote:
>  Chitlesh GOORAH (chitlesh.goorah(a)gmail.com) said:
> > Milkymist community builds and enhance their own toolchain (currently
> > not fully supported by Fedora). 
...
>  OK, that's clear. But I am worried that if we go down this road,
> we'll
>  eventually have 20 or 30 groups for different SoCs for embedded use, 
The electronics lab community is a generic concept, with clearly 
defined, self-evident scope and specific FOSS software products. 
Milkymist on the other hand has two problems:

  - it is not a mainstream interest--I try to keep up with embedded and 
electronic topics and I have never heard of it, which of course doesn't 
mean it isn't worthy. As Bill said, we should be careful how we organize 
the information, because otherwise it'll be hard to find anything. 
Grouping milkymist with something else electronics isn't
a bad idea.

  - related to that, the term 'milkymist' is obscure: google returns 
hits for some sort of VJ software as well. "Milkymist embedded 
visualization hardware project" might be excessively long, but surely 
there's a happy middle somewhere.

[James Laska]

On Mon, 2010-10-11 at 15:42 -0400, Bill Nottingham wrote:
>  1) When you added this to F14/F15/EL6, you added a typo; this
>  broke the F-14 branched compose and the EPEL updates push.
>  *Please* verify your changes before pushing.  
How did the compose break?  Is this something that the autoqa
rats_sanity test [sh|c]ould have caught?

https://fedorahosted.org/pipermail/autoqa-results/2010-October/046361.html
https://fedorahosted.org/pipermail/autoqa-results/2010-October/046372.html

Thanks,
James

[Bill Nottingham]

James Laska (jlaska(a)redhat.com) said: 
>  > 1) When you added this to F14/F15/EL6, you added a typo; this
>  > broke the F-14 branched compose and the EPEL updates push.
>  > *Please* verify your changes before pushing. 
>  
>  How did the compose break? 
The comps file in git failed to parse, such that the with-translations
comps file could not be made.

>  Is this something that the autoqa
>  rats_sanity test [sh|c]ould have caught? 
No, this is well before the tree gets to that state. It would need to
be implemented as a check on git push.

Bill

[James Laska]

On Tue, 2010-10-12 at 16:54 -0400, Bill Nottingham wrote:
>  James Laska (jlaska(a)redhat.com) said: 
>  > > 1) When you added this to F14/F15/EL6, you added a typo; this
>  > > broke the F-14 branched compose and the EPEL updates push.
>  > > *Please* verify your changes before pushing. 
>  > 
>  > How did the compose break?
>  
>  The comps file in git failed to parse, such that the with-translations
>  comps file could not be made.
>  
>  > Is this something that the autoqa
>  > rats_sanity test [sh|c]ould have caught?
>  
>  No, this is well before the tree gets to that state. It would need to
>  be implemented as a check on git push. 
We attempt to validate comps in this test using the comps.rng in git
(see results logs posted earlier).  I'm not tremendously familiar with
that part of the test, but I believe it should catch that?

https://fedoraproject.org/wiki/QA:Comps_Validity_Test_Case

Thanks,
James

[Bill Nottingham]

James Laska (jlaska(a)redhat.com) said: 
>  > No, this is well before the tree gets to that state. It would
> need to
>  > be implemented as a check on git push.
>  
>  We attempt to validate comps in this test using the comps.rng in git
>  (see results logs posted earlier).  I'm not tremendously familiar with
>  that part of the test, but I believe it should catch that? 
You're validating it after the repo has already been made. In this case,
it was broken such that the repo couldn't even be made.

Bill

[James Laska]

On Tue, 2010-10-12 at 17:01 -0400, Bill Nottingham wrote:
>  James Laska (jlaska(a)redhat.com) said: 
>  > > No, this is well before the tree gets to that state. It would need to
>  > > be implemented as a check on git push.
>  > 
>  > We attempt to validate comps in this test using the comps.rng in git
>  > (see results logs posted earlier).  I'm not tremendously familiar with
>  > that part of the test, but I believe it should catch that?
>  
>  You're validating it after the repo has already been made. In this case,
>  it was broken such that the repo couldn't even be made. 
Ah, thanks for the clarification.

James