For your consideration: Secondary Architectures in Fedora

[Oliver Falk]

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

On 05/31/2007 03:08 PM, Jesse Keating wrote:
[ ... ] < long thread skipped >

Jesse, David, don't want to bug you, but...

Let's break it up into possible scenarios, I hope that helps...

a) Build works fine on primary and sec archs (OK)
b) Build works fine on primary, but fails on sec archs
  1) Filelist wrong (trivial)
  2) missing dep (might be trivial)
  3) compile error (might be hard)
c) Build fails on primary and sec arch (don't need do discuss)


Ad b1) * Inform the maintainer
       * don't push to public automatically - give maintainer a
         button to do so

Ad b2) * Inform the maintainer and the arch-team by mail
      (* Maybe also the maintainer of the missing dep!?)
       * push completed to public

Ad b3) * Inform the arch-team
       * push completed to public


I don't know if koji can provide us with the information in which step
it failed building, but if we can use the above approach and - of course
- - add missing scenarios (my list is maybe far away from being complete).

As far as I understood. Completed primary arch packages will
automatically be available in the buildsys itself, but not pushed to
public... So if you commit a few packages that depend on each other, you
will have a result quite fast on the primary archs - if everything is
fine. If it's a trivial bug you really should be stopped (b1).

Maybe we should also clear, do we speak about *INITIAL* builds or
changes/updates! Initial builds of the lower level packages will fail,
even updates/changes to lower level packages are subject to fail and
maintainer(s) and arch-team have to work together... Many 'normal'
packages will initially also fail - arch-maintainers need to check if
it's 'fixable' in case of compile-errors; In case of dep(s) missing (and
also *uncompileable/unfixable* - ExclusiveArch might be your friend...
Packages that once built fine, shouldn't really fail in case of an
update/change I think... Maybe the initial and update/change thinking
mentioned now should be also included in the above list/work-flow...

Auto-filing of bugs - bad idea. There must be some script that can do it
and has a lot of logic and bz or at least the bz database must be
available - what if not... Argh... Don't want to think about the rest...

I don't know if you like my above approach, but I think if we split it,
it's easier, since we can find a good solution for each 'small problem',
instead of talking about *one* 'huge problem'.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFGXtH/xWN5Ge8lKUMRAoZfAKDFjnMsmUAXJXE3S0k+6Hu/Y/7IpQCfT+Gp
6TTLq2VScsHl3Wl1pOOiXUs=
=0UKI
-----END PGP SIGNATURE-----