Distro 1.0 Planning minutes

Distro 1.0 Planning minutes

[Kamble, Nitin A]

[-- Attachment #1: Type: text/plain, Size: 2276 bytes --]

Attendees:
PRC: Dave, RP, PRC Distro Team,
US: Beth, Scott, Nitin, Saul

Opens: no opens

4 milestones

M2: 6 sprints

M3 : 6 sprints
  around a week of sprint
  sprint A is bit longer

M4: stabilizing & bug fixing

Release: on Apr 1st (April Fool's Day), Contingency Apr 15th
 release venue: Linux foundation event on Apr 6th week

PRC Holidays:
  New hear holiday: Feb 3rd, normally 8 days, people may take extra days off before or after
  Saul: QA testing may need pushing further 1 week ?
  Dave: the QA test may be complete by the new year holiday

For publically publishing this plan, remove owner/source ?
: take it offline

Main goals of 1.0 release:
  Improve overall experience, and add new BSPs.

Package updates:
  License Checksum & Source Checksum  (in bb files)
    Will be made fetal errors
  Source Checksum:
    The current checkers only checks the source checksum in the ini files and not in bb files.
    Will drop from sprint B ?
    Need to do Audit to find how many are mismatching.
    AR: for Saul
  Mark will be doing package distribution
  Need to do package updates as soon as we can.


M3: Package updates, should be a small list

Yu Ke: work with Saul, rootless X & checksum

Qing: work with Mark on zypper/RPM, performance investigation,
  RP: fork vs. exec discussion

Edwin: KVM/qemu work, qemu recipe maintainer, audio in qemu?
  Our qemu has big patch for GL pass through

Dongxiao:  sysroot per machine per recipe
        Image creator ?
        ophono ?

Lei: help Beth with package history
   How long is your internship? 1 year. till next summer

Nitin:
   M2: toolchain, eglibc, gcc with testing, perl
   M3: mklibs with mark
   eglibc & busybox need newer patches for fedora 14;  josh's patches can go in.

Scott:
   security process
   libtool sysroot support
   upstream documentation enabling/disabling
   helping Beth with autobuilder
   helping with sysadmin

Beth:
   Autobuilder
   updates
   creating license directory for release process
   Documentation of release process & clarifying
   Package History with Saul & RP

open task list:
   BSP work
   profiling & tracing
   Package developer tool ?
   updating metademo apps









[-- Attachment #2: Type: text/html, Size: 7778 bytes --]

Re: Distro 1.0 Planning minutes

[Esben Haabendal]

"Kamble, Nitin A" <nitin.a.kamble@intel.com> writes:

> Dongxiao:  sysroot per machine per recipe

Is it possible to elaborate on this topic?  What was discussed and what
was the conclusion?

/Esben

Re: Distro 1.0 Planning minutes

[Richard Purdie]

On Wed, 2010-11-10 at 10:50 +0100, Esben Haabendal wrote:
> "Kamble, Nitin A" <nitin.a.kamble@intel.com> writes:
> 
> > Dongxiao:  sysroot per machine per recipe
> 
> Is it possible to elaborate on this topic?  What was discussed and what
> was the conclusion?

This is what we discussed in person in Cambridge, the idea of making it
possible to have one sysroot per machine or one sysroot per recipe. Our
intention is to make this work in the next few months.

I pointed you at the existing task based sstate code which should make
this kind of thing relatively straight forward.

Cheers,

Richard

Re: Distro 1.0 Planning minutes

[Esben Haabendal]

Richard Purdie <rpurdie@linux.intel.com> writes:

> On Wed, 2010-11-10 at 10:50 +0100, Esben Haabendal wrote:
>> "Kamble, Nitin A" <nitin.a.kamble@intel.com> writes:
>> 
>> > Dongxiao:  sysroot per machine per recipe
>> 
>> Is it possible to elaborate on this topic?  What was discussed and what
>> was the conclusion?
>
> This is what we discussed in person in Cambridge, the idea of making it
> possible to have one sysroot per machine or one sysroot per recipe. Our
> intention is to make this work in the next few months.
>
> I pointed you at the existing task based sstate code which should make
> this kind of thing relatively straight forward.

This definitely sounds interesting.

Will it be possible to have recipe A (build) depend on B, which (build)
depends on C, without having C in the per recipe stage of A?

Will it be possible to have recipe A (build) depend on selected files
from B, f.x. only a subset of libraries built by a recipe?

/Esben

Re: Distro 1.0 Planning minutes

[Richard Purdie]

On Wed, 2010-11-10 at 11:52 +0100, Esben Haabendal wrote:
> Richard Purdie <rpurdie@linux.intel.com> writes:
> 
> > On Wed, 2010-11-10 at 10:50 +0100, Esben Haabendal wrote:
> >> "Kamble, Nitin A" <nitin.a.kamble@intel.com> writes:
> >> 
> >> > Dongxiao:  sysroot per machine per recipe
> >> 
> >> Is it possible to elaborate on this topic?  What was discussed and what
> >> was the conclusion?
> >
> > This is what we discussed in person in Cambridge, the idea of making it
> > possible to have one sysroot per machine or one sysroot per recipe. Our
> > intention is to make this work in the next few months.
> >
> > I pointed you at the existing task based sstate code which should make
> > this kind of thing relatively straight forward.
> 
> This definitely sounds interesting.
> 
> Will it be possible to have recipe A (build) depend on B, which (build)
> depends on C, without having C in the per recipe stage of A?

Yes, that is the plan. I'm hoping this allows us to rigorously check
package dependencies and whilst we might not default to it all the time,
it would allow us to test this periodically.

> Will it be possible to have recipe A (build) depend on selected files
> from B, f.x. only a subset of libraries built by a recipe?

This currently isn't planned.

Cheers,

Richard