Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2007-03-10 11:41:54
Size: 545
Editor: LukClaes
Comment:
Revision 6 as of 2007-05-16 11:34:46
Size: 4845
Editor: ?FransPop
Comment: Add link to new proposal
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Line 9: Line 8:
----
I wrote to jvw about this project and am "forwarding" his reply. In summary he does not believe that this alone would be an appropriate Google SoC project. -- FilipusKlutiero
   
{{{Hi,

Feel free to forward this to luk, btw.

On Tue, Mar 20, 2007 at 11:10:30AM -0400, Philippe Cloutier wrote:
> Hi Jeroen,
> I'm aware that updating udebs in testing is currently complicated from
> following IRC and debian-release. The Google SoC project proposed by luk
> sounds interesting for me. I discussed that with luk a bit, and he made
> me realize that this could be more than hacking on britney. The problem
> is that very few people know how things are working currently so it's
> difficult to do a reasonably-detailed application for this project.

Right.

> Therefore, I would like to know a bit about:
> what work would this project save? ; what are you doing currently with
> udebs, and how would the project change that? would the project save
> work to other people?

Currently, the work it'd save is not extremely significant. There is a
method with scripts that semi-manually sync udebs of a source package
from unstable to testing. It involves invoking a command, which basicly
does all the necessary checks, and then confirm it.

I'm currently the only person doing so, mostly excusively on request of
fjp, or as triggered by the consistency checking script run from my
crontab (output: http://ftp-master.debian.org/~jeroen/d-i.out)

> how much time (a year?) would that save you?
> which software other than britney needs to be touched significantly?
> do you think this would make an interesting Google SoC project?
> particularly, does the time (12 weeks) seem too much or too few?

I think the solution would be pretty simple. Making sure that udebs get
synced along with regular debs, by having them fed to britney as input
-- britney would already deal with it properly if the udeb package lists
would get properly mangled. 12 weeks would really seem (way) too much
for that, to be honest -- it's not really that complicated, new, or
special, it's "just" a bit of grunt work getting it to work
proof-of-concept on your own system, write a proper patch with
appropriate shell/python magic, and getting it applied.

Implemented this way, udebs can be controlled by the release team much
like (or exactly like) any other source package.

> do you volunteer to mentor this project?

I would, if I'd see something significant to do in this area.
Personally, I don't think udeb handling in britney is that, it'd need to
be something more. No, I don't have any specific suggestions at the
moment.

--Jeroen

--
Jeroen van Wolffelaar
Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
}}}

----

Note that this is an open issue from last years summer of code when Fabio Tranchitella worked on Britney that we have decided (for different reasons) to park until after the release of Etch.
The intention from Fabio and me is to pick this up then.

  I agree with Frans: this is the natural follow up for the work I started last year. I do not
  think that this is a project suitable for SoC.

  -- Fabio Tranchitella

It is probably not extremely difficult, but still needs very careful implementation as the D-I release manager needs to be able to determine which packages containing udebs are allowed to migrate and which not as udebs have incomplete (versioned) dependency information and thus uncoordinated migrations can break an existing release in testing.

-- Frans Pop

  Don't the current 'block' stanza's in hints file provide adequate control? What
  control would you like to have beyond that? Also for lenny, I think in the latter
  half of the release cylce you'd want to block most if not all udeb stuff, by having britney
  deal with udebs just like debs, it can be done completely by RM, udebs will always just
  follow source packages, and britney will make you use force-hints if dependencies wouldn't
  otherwise allow a migration/the package is out-of-sync on some architectures.
  
  --["Jeroen"]

New [http://lists.debian.org/debian-release/2007/05/msg00086.html proposal available] on the debian-release mailing list.

-- Frans Pop

Full support of udebs

  • Mentor: LukClaes (jvw: add yourself here if you're proposing yourself as a mentor)

  • Summary: The goal is to make sure that no special manual intervention is needed for testing migration of udebs

  • Required skills:

    • python
    • C/C++
  • Description: udebs are Debian packages that are stripped down to be really small to be able to use them in debian-installer. Currently there is a manual intervention needed to make sure udebs and their source and deb equivalents are in sync.


I wrote to jvw about this project and am "forwarding" his reply. In summary he does not believe that this alone would be an appropriate Google SoC project. -- FilipusKlutiero

{{{Hi,

Feel free to forward this to luk, btw.

On Tue, Mar 20, 2007 at 11:10:30AM -0400, Philippe Cloutier wrote: > Hi Jeroen, > I'm aware that updating udebs in testing is currently complicated from > following IRC and debian-release. The Google SoC project proposed by luk > sounds interesting for me. I discussed that with luk a bit, and he made > me realize that this could be more than hacking on britney. The problem > is that very few people know how things are working currently so it's > difficult to do a reasonably-detailed application for this project.

Right.

> Therefore, I would like to know a bit about: > what work would this project save? ; what are you doing currently with > udebs, and how would the project change that? would the project save > work to other people?

Currently, the work it'd save is not extremely significant. There is a method with scripts that semi-manually sync udebs of a source package from unstable to testing. It involves invoking a command, which basicly does all the necessary checks, and then confirm it.

I'm currently the only person doing so, mostly excusively on request of fjp, or as triggered by the consistency checking script run from my crontab (output: http://ftp-master.debian.org/~jeroen/d-i.out)

> how much time (a year?) would that save you? > which software other than britney needs to be touched significantly? > do you think this would make an interesting Google SoC project? > particularly, does the time (12 weeks) seem too much or too few?

I think the solution would be pretty simple. Making sure that udebs get synced along with regular debs, by having them fed to britney as input -- britney would already deal with it properly if the udeb package lists would get properly mangled. 12 weeks would really seem (way) too much for that, to be honest -- it's not really that complicated, new, or special, it's "just" a bit of grunt work getting it to work proof-of-concept on your own system, write a proper patch with appropriate shell/python magic, and getting it applied.

Implemented this way, udebs can be controlled by the release team much like (or exactly like) any other source package.

> do you volunteer to mentor this project?

I would, if I'd see something significant to do in this area. Personally, I don't think udeb handling in britney is that, it'd need to be something more. No, I don't have any specific suggestions at the moment.

--Jeroen

-- Jeroen van Wolffelaar Jeroen@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl }}}


Note that this is an open issue from last years summer of code when Fabio Tranchitella worked on Britney that we have decided (for different reasons) to park until after the release of Etch. The intention from Fabio and me is to pick this up then.

  • I agree with Frans: this is the natural follow up for the work I started last year. I do not think that this is a project suitable for SoC. -- Fabio Tranchitella

It is probably not extremely difficult, but still needs very careful implementation as the D-I release manager needs to be able to determine which packages containing udebs are allowed to migrate and which not as udebs have incomplete (versioned) dependency information and thus uncoordinated migrations can break an existing release in testing.

-- Frans Pop

  • Don't the current 'block' stanza's in hints file provide adequate control? What control would you like to have beyond that? Also for lenny, I think in the latter half of the release cylce you'd want to block most if not all udeb stuff, by having britney deal with udebs just like debs, it can be done completely by RM, udebs will always just follow source packages, and britney will make you use force-hints if dependencies wouldn't otherwise allow a migration/the package is out-of-sync on some architectures. --["Jeroen"]

New [http://lists.debian.org/debian-release/2007/05/msg00086.html proposal available] on the debian-release mailing list.

-- Frans Pop