Differences between revisions 1 and 2
Revision 1 as of 2007-03-10 11:41:54
Size: 545
Editor: LukClaes
Comment:
Revision 2 as of 2007-03-22 23:39:13
Size: 3353
Comment:
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
}}}

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 }}}