1. Topics
  2. Distro 1.0 Planning minutes

Distro 1.0 Planning minutes

Kamble, Nitin A <nitin.a.kamble@...>
 

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

 

 

 

 

 

 

 

 
Esben Haabendal <eha@...>
 

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

Dongxiao: sysroot per machine per recipe
Is it possible to elaborate on this topic? What was discussed and what
was the conclusion?

/Esben
Richard Purdie <rpurdie@...>
 

On Wed, 2010-11-10 at 10:50 +0100, Esben Haabendal wrote:
"Kamble, Nitin A" <nitin.a.kamble@...> 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
Esben Haabendal <eha@...>
 

Richard Purdie <rpurdie@...> writes:

On Wed, 2010-11-10 at 10:50 +0100, Esben Haabendal wrote:
"Kamble, Nitin A" <nitin.a.kamble@...> 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
Richard Purdie <rpurdie@...>
 

On Wed, 2010-11-10 at 11:52 +0100, Esben Haabendal wrote:
Richard Purdie <rpurdie@...> writes:

On Wed, 2010-11-10 at 10:50 +0100, Esben Haabendal wrote:
"Kamble, Nitin A" <nitin.a.kamble@...> 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
1 - 5 of 5