On Monday 03 of March 2014 21:18:48 Darrell wrote:
Yes, David,
you're right. It is not a good idea to freeze when some
applications FTBFS and when going another renaming, which may cause
further FTBFS. This is not a good time to freeze.
Current FTBFS bug reports:
http://bugs.trinitydesktop.org/buglist.cgi?bug_status=UNCONFIRMED&bug_s…
s=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=CONFIRMED&bug_statu
s=NEEDINFO&bug_status=PATCHAVAIL&bug_status=SRUONLY&field0-0-0=product&field
0-0-1=component&field0-0-2=alias&field0-0-3=short_desc&field0-0-4=status_whi
teboard&field0-0-5=content&list_id=246&query_format=advanced&type0-0-0=subst
ring&type0-0-1=substring&type0-0-2=substring&type0-0-3=substring&type0-0-4=s
ubstring&type0-0-5=matches&value0-0-0=FTBFS&value0-0-1=FTBFS&value0-0-2=FTBF
S&value0-0-3=FTBFS&value0-0-4=FTBFS&value0-0-5=%22FTBFS%22&order=bug_id%20DE
SC&limit=0
Not in the list: kchmviewer.
Darrell
A good list. However, not everything is subject to solve now.
Currently I am for soft-freeze differentiate between FTBFS, which are caused
by an external source => fore example due to a new version of the external
library and FTBFS that we have caused by our mistake:
+ kchmviewer FTBFS due to commit 3aef1afb
+ tde-guidance is packaging issue due to commit 3852ddd9 (will be fixed soon)
--
Slavek