Extras Rebuild?

[Michael Schwendt]

On Sun, 22 May 2005 19:57:58 -0400, Toshio wrote:

> > [...] whatever failed to rebuild on April 7th exists in the repository as a
> > copied FC3 binary.
> 
> Based on this, I should be able to write a script that tells if a
> package is in an unknown state:
> 1) Compare date of packages.  If April 7th or older, then check if
> there's a bugzilla entry for build failure.  If not, open a bugzilla
> ticket that says not-built for FC4 devel.

That would not be entirely correct. A package may have been built one or
two weeks earlier or is noarch and doesn't need another rebuild.

> > Right. But notice that we imported Seth's build failure report into the
> > Wiki for tracking purposes, and later on I filed a bug report about every
> > package on that list. The FE4Target tracker depends on all those bugs
> > plus other issues, such as crashes.
> > [...]
> > Or let me ask a question: what other packages should be added to
> > bug 157183?
> > 
> scorched3d is my only example ATM.  It has no bugzilla entry.

It was rebuilt on April 11th for i386, but the x86_64 binary is still from
Jan 25th, the ppc binary is non-existant. It was not reported as failing
for those two archs, so some information was lost. See list archives,
April 11th, subject "Fedora Extras Development Package Report".

> Also, how is "bump,tag,build" superior to a targeted automated rebuild
> that dropped build failures into bugzilla? 

 * maintainer is the one to decide whether to rebuild or whether to
   apply an upstream update and/or other fixes first
 * maintainer gets notified whether the build was successful
 * maintainer can take action and fix reported build failures without
   the overhead of opening/closing bugzilla tickets

> Isn't your argument against
> automated rebuilds that a maintainer needs to check buildrequires
> against the new FC and run tests to see if there's any change in runtime
> behaviour?  In other words, do things above and beyond, bump, tag,
> build?

It's rather pointless, so close to FC4, to keep rebuilding and using
existing Extras src.rpms in an automated way only to get a version upgrade
from the package owner after FC4 is released.

An early mass rebuild, e.g. to fill a publicly accessible repository or to
make a C++ ABI jump, is something different. It can make sense as a
quickstart. Later on during a development cycle, package maintainers would
do further preparations. Well, that's my point of view. YMMV.
 
> > The thing here is, bugzilla tickets are _assigned to_ the package owner
> > and _mailed to_ the package owner. So, that is a way already to address
> > the package owner. Assume that package owners do see your bug report and
> > your attachments (if any) and could add a comment like "go ahead with
> > the fix" or set status to ASSIGNED to give you some feedback.
> > 
> And when the package maintainer does not respond to bugzilla mail a
> direct email that explains the patch and asks for permission to apply
> will often get a response.  Perhaps we need to change our culture to
> promote rapid responses to bugzilla mail and slower responses to
> personal mail :-)

Well, communication in bugzilla should just work. Imagine a ticket is
marked "security" or "blocker". Every packager would want to not miss
bugzilla e-mail, whereas private mail may be subject to accidental spam
filtering.

-- 
Fedora Core release Rawhide (Rawhide) - Linux 2.6.11-1.1329_FC4
loadavg: 1.40 1.25 0.89