[Angstrom-devel] [RFC] promoting 2007.12-r7 to release

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michal Panczyk schreef:
| Hi Koen,
|
|>  From: Koen Kooi
<koen at dominion.kabel.utwente.nl>
|>  Subject: [Angstrom-devel] [RFC] promoting 2007.12-r7 to release
|>
|>  -----BEGIN PGP SIGNED MESSAGE-----
|>  Hash: SHA1
|>
|>  Hi,
|>
|>  The autobuilder is busy building -r7 image and I would like to propose
|>  that mentors test it and promote it to release status (and (re)move the
|>  old release) in the download location.
|>
|>  I kept putting of this RFC till the zaurus people completed their kernel
|>  upgrade, but after a few weeks of absolutely no progress at all we have
|>  to face it and realize it's not going to happen and move forward.
|>  There's no point in idle waiting when other devices have received
|>  serious improvements (simpad, h5000, h2200, etc) and are ready for the
|>  update.
| What does that mean for these devices - dropping down the support or
| moving to some in between state "kind of supported" ? Can we still
| have unstable builds for these devices ?

It means builds for those machines will pile up in unstable/ till one of
us gets annoyed and clears out those dirs. After that the piling up will
start again, etc.
If the mentors don't do anything, support comes to a standstill, that's
how it works. If people care for a certain machine, they should step up
and help out if the mentor(s) go(es) AWOL (which seems the case with
zaurus machines atm).
It isn't that much work; if you think an image works well enough you
move that files from unstable/ to release and send a mail to the lists
and update the website (most likely paste your email into the news
section). If you want to have patches applied, send the diffs to this
list for review.
And if you want things to change, send an RFC and people will comment on
it and will implement the parts agreed on, that's how angstrom works.

|>  After -r7 we can start concentrating on the initramfs-bootmenu stuff and
|>  hopefully do a coordinated test effort.
|
| Concentrated test effort ..... It reminds me Paul S talking about
| formal testing... So could we do it not only in coordinated but also
| in some formal way - knowing what and how to test ? From my experience
| the best way to create "test cases" is before testing and make just
| small corrections to procedures during testing. I also mean written
| down procedures (maybe in wiki), so they can be used in the future.
|
| I tried doing something like that for testing hh-kernel based devices
| (http://www.linuxtogo.org/gowiki/UniversalTestProcedure), but it is
| hard without a number of people working in the tested area... So if
| there is going to be a number of people working on testing inutramfs
| stuff it should not be that hard.

Formal testing is of course the goal, but I'll settle for any form of
testing people want to do. Case in point: my h5550 has a broken lcd, so
I can't do a full formal test ;)

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFHy/ZjMkyGM64RGpERAqrBAKCFQw13P0hBsbd+b9ivbnHsHMb/JQCcDYo6
iRk12NmSrKfIabG0wr2b4t4=
=2XDH
-----END PGP SIGNATURE-----