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_st... 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)