On Wed, Feb 17, 2010 at 03:28:37PM +0100, Christoph Wickert wrote:
Am Mittwoch, den 17.02.2010, 15:07 +0100 schrieb Till Maas:
> On Wed, Feb 17, 2010 at 02:23:22PM +0100, Christoph Wickert wrote:
> > ...
> Usually when some of mine packages need to be rebuild because of updated
> dependencies, the communication is usually one-way. I get informed that
> the packages needs to be rebuild and then it happens soon afterwards,
You are lucky. In the past people broke my package without further
notice and I had to take care of fixing them. On the other hand there
are maintainers, that announce changes in advance and ask me if I'm fine
with them rebuilding my packages or if I want to take care of this
myself. This is how it should be but only proven packagers will be able
to do this.
I guess a recommended procedure for this is not really documented in the
wiki, but since I was never in the situation to rebuild a bunch of
dependent packages, I do not really know.
Take KDE for example: Although the KDE SIG is doing a great job in
avoiding breakdowns, I doubt that each and every maintainer of a QT or
KDE app is always aware of the changes before they happen. If things
still seem to be working in F-13 or rawhide, he might not even be aware
of the custom tag.
Yes, I know, because I co-maintain a package using qt and I recently
read something from the maintainer that he can not push a bugfix update
to stable, because a qt override is in the buildroot.
> therefore I do not even have to know how the tag is called.
> also scripts that help to do this easily afaik. This is also the
> advantage of using a tag, because then I can still create bugfixes by
> myself without being disturbed my the buildroots. Off course then the
> package also needs to be rebuilt in the staging tag, but this can be
> easily automated and already might be.
Honestly, I don't recall automated updates of my packages except for the
mass rebuilds from rel-eng. If the people that break things and/or
requested the custom tag will take care of this, we are fine, bug FWIW
it's not like this in rawhide. Let's see how it turns out in F-13.
I remember this for python and openssl and I believe the haskell or
ocaml SIG did this for their packages, too.
> and F-13 is now stabilizing and afaik should be treated
> more like it was stable than like it is rawhide. E.g. major updates
> should now break rawhide first and if the fallout is handled, then it
> could be done for F-13.
I think we still need to be able to treat F-13 different than in the
released branches, at least before beta freeze. If we need to do things
in rawhide first and only push these changes to F-13 afterwards, a
feature with a tight schedule like Xfce 4.8 is lost. That's just what I
It would be sad to loose the feature, only because of the schedule, but
I guess there will always be some feature that needs to be postponed
because of missing some deadline shortly. Nevertheless it would be good
to speed up procedures to get as much features as possible. So maybe you
can already request the tag you will need once Xfce 4.8 is released to
start building it as soon as it is released.