Re: http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2007-07-11 at 20:57 +0100, David Woodhouse wrote:
> On Wed, 2007-07-11 at 07:02 -0400, Jesse Keating wrote:
> > They stopped because it led to a lot of weird package situations and
> > mixed results.  It was not a very good situation, it only made
> > you /think/ you were moving on correctly when you really weren't and
> > should have rebuilt everything with the new version once it was fixed
> > anyway instead of keeping going.
> 
> You're right to remind us of the problems with this, btw. It's exactly
> the kind of hell that Spot's proposal as-is would have us impose on the
> secondary architectures. If packages are going to be absent on any given
> architecture, that should happen only through a conscious decision on
> the part of the maintainer -- not just automatically after a build
> failure which is probably going to turn out to be a generic issue when
> it's investigated anyway.

So, it would look like this for workflow:

1. Maintainer requests build (make build)
2. Packages build on primary architectures successfully.
3. Build requests get sent out to secondary architectures.
4a. All secondary architectures report success. Primary packages
automatically move into their repository. Secondary packages
automatically move into their repository.
***End of workflow***

OR

4b. At least one secondary architecture fails to build. Maintainer is
notified (say, by email). Notification tells packager that all packages
are being held back from repo for all architectures, pending packager
action.

At this point, the maintainer either has to:

A) Decide that the build is bad, tell koji to let those bits die, don't
push any built packages into their repository.
B) Open an bugzilla against the arch(es) that failed to build, then tell
koji to push the built packages anyway. It might be possible to automate
this step somewhat:

***WARNING: Pseudo-code***

[spot@localhost devel]$ koji push-failed-task 64178
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=64178

This task failed on architecture(sparc). Open a new bug for this package
against the Fedora-sparc tracker? (y/n) y

Bug 123456 filed.

Pushing packages. Task unblocked.
[spot@localhost devel]$

***END Pseudo-code***

Obviously, koji doesn't work _at all_ like this now. I'm still not
convinced this is necessary. I think this puts too much burden on the
maintainer, when this should fall to the secondary architecture team.
The secondary architecture team will get notified when a build fails on
their arch, and we can whip up scripts that show the differences between
a secondary arch repository packagetree and the primaries (they can even
look for ExcludeArch/ExclusiveArch and focus only on the unknowns).

~spot

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux