Re: rawhide report: 20060304 changes

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

 



On Sun, 2006-03-05 at 22:01 -0800, Miles Lane wrote:
> On 3/5/06, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote:
> > On Sat, 2006-03-04 at 04:20 -0500, Mike A. Harris wrote:
> > > Ralf Corsepius wrote:
> > > > On Sat, 2006-03-04 at 03:19 -0500, Build System wrote:
> > > >
> > > >
> > > >>xorg-x11-xbitmaps-1.0.1-3
> > > >>-------------------------
> > > >>* Thu Mar 02 2006 Mike A. Harris <mharris@xxxxxxxxxx> 1.0.1-3
> > > >>- Made package arch specific due to pkgconfig files being placed in lib64
> > > >>  if the noarch packages manage to get built on x86_64/ppc64/s390x.
> > > >
> > > >
> > > > What?
> > > >
> > > > Fix the toplevel Makefile.am to install the pkgconfig file to $datadir
> > > > instead of libdir:
> > > >
> > > > -pkgconfigdir = $(libdir)/pkgconfig
> > > > +pkgconfigdir = $(datadir)/pkgconfig
> > > >
> > > > That's what other noarch packages do.
> > > >
> > > >
> > > > Alternatively, fix your spec to use
> > > >
> > > > %configure --libdir=%_datadir
> > > > ...
> > > > %_datadir/share/pkgconfig/*.pc
> > >
> > > For now, the important thing is that FC5 is in a state that everything
> > > builds, and is ready for final release.  Minor trivia like this is not
> > > mission critical to the release of the OS.
> > >
> > > Feel free to submit a patch to X.Org to do this, so it is fixed in
> > > the future.
> >
> > It's always great having to experience the "warm feeling" your responses
> > emit and having to experience your attempts on pushing people around,
> > instead of fixing bugs you are responsible for yourself.
> >
> > Even the time you invested to reply my remark exceeds the time it would
> > have taken you to fix your spec-file.
> >
> > Ralf
> 
> Dude, the freeze policy is pretty understandable.
Did you see a formal code freeze announcement? I haven't.

> That said, I do understand that freezes cause frustration.  If you
> look on the linux-kernel mailing list, you'll see the ongoing tension
> between release management and getting patches in.
I am familiar with code freezes and don't argue on their necessity.

But if a bug prevents function after a code freeze, it qualifies as
"release critical"/"must fix" and showstopper.

However, this shouldn't prevent maintainers from providing proper fixes,
and doesn't justify adding semi-cooked, semi-sought-out emergency hacks
into packages.

Ralf


-- 
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe: 
https://www.redhat.com/mailman/listinfo/fedora-test-list

[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]