Dear all, this is to remind everybody that as of today, R14.0.0 has been declared feature-frozen (soft-freeze). No new apps, kde->tde renames, major enhancement will be included in R14.0.0 and they will have to wait for the next release. KXMLEditor and Katesort plugin will be included given the amount of work done on them in the last few days.
I am working on a list of bugs that will have to be addressed in order to release R14.0.0. I should be able to complete the list within Wednesday and after that Tim, Slavek and Darrell will review it. When this is done, the list will be published for users/developers review and changes/additions to the list will be allowed as long as they are pertinent to R14.0.0. Once the list is fully completed and agreed upon, we should make it the official list and IMO we should declare R14.0.0 as hard-frozen.
In the meantime, feel free to suggest what bugs you would like to see fixed in R14.0.0 and if you are willing to work on any of them. Please keep in mind that we want to keep the list as short as possible, in order to release R14.0.0 in a timely manner. Therefore bugs should fit in one of the next categories (in order of priority): - blockers - criticals - cause major loss of functionality to the system or to the user - results in loss of functionality that could affect R14 release reviews negatively (such as help buttons not working for example)
Please do not suggest bugs that do not fit in one of these categories.
Cheers Michele
this is to remind everybody that as of today, R14.0.0 has been declared feature-frozen (soft-freeze). No new apps, kde->tde renames, major enhancement will be included in R14.0.0 and they will have to wait for the next release.
I have a pytdeextensions patch I finished yesterday that does nothing but kde->tde and qt->tqt renames. I can push or open a bug report. Based upon everything I saw , I suspect nobody uses pytdeextensions anyway.
Once the list is fully completed and agreed upon, we should make it the official list and IMO we should declare R14.0.0 as hard-frozen.
I think we ought to play wack-o-mole and get a nice hunk of bugs resolved before moving to hard freeze.
In the meantime, feel free to suggest what bugs you would like to see fixed in R14.0.0 and if you are willing to work on any of them. Please keep in mind that we want to keep the list as short as possible, in order to release R14.0.0 in a timely manner. Therefore bugs should fit in one of the next categories (in order of priority):
- blockers
- criticals
- cause major loss of functionality to the system or to the user
- results in loss of functionality that could affect R14 release reviews negatively (such as help buttons not working for example)
Please do not suggest bugs that do not fit in one of these categories.
Every time this kind of discussion arises I am the lone voice that is ignored. Everybody focuses on Blocker and Critical bugs. The bug list needs to include paper cut issues.
http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd=R... http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd=s...
Darrell
Dne po 3. března 2014 Darrell napsal(a):
this is to remind everybody that as of today, R14.0.0 has been declared feature-frozen (soft-freeze). No new apps, kde->tde renames, major enhancement will be included in R14.0.0 and they will have to wait for the next release.
I have a pytdeextensions patch I finished yesterday that does nothing but kde->tde and qt->tqt renames. I can push or open a bug report. Based upon everything I saw , I suspect nobody uses pytdeextensions anyway.
pytdeextensions is necessary for tde-guidance. And tde-guidance now FTBFS. This is not good.
Once the list is fully completed and agreed upon, we should make it the official list and IMO we should declare R14.0.0 as hard-frozen.
I think we ought to play wack-o-mole and get a nice hunk of bugs resolved before moving to hard freeze.
I agree - not good freeze when serious bugs. For example, as of now FTBFS in kchmviewer and tde-guidance.
In the meantime, feel free to suggest what bugs you would like to see fixed in R14.0.0 and if you are willing to work on any of them. Please keep in mind that we want to keep the list as short as possible, in order to release R14.0.0 in a timely manner. Therefore bugs should fit in one of the next categories (in order of priority):
- blockers
- criticals
- cause major loss of functionality to the system or to the user
- results in loss of functionality that could affect R14 release
reviews negatively (such as help buttons not working for example)
Please do not suggest bugs that do not fit in one of these categories.
Every time this kind of discussion arises I am the lone voice that is ignored. Everybody focuses on Blocker and Critical bugs. The bug list needs to include paper cut issues.
http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd= Regressions&list_id=237 http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd= stdout%2Fstderr&list_id=236
For this reason, I'm not sure if just now he have to deal with KXMLEditor and Katesort plugin. There are several other applications on which François worked hard, and which also waiting for inclusion into GIT. The only difference is that around them at present is not such a stir.
For example, for me, is critical twinkle. Francois on it did a lot of effort, but because it is a complicated application, its integration I've had to postpone - regardless of the fact that "for me" is critical.
Darrell
On 03/03/2014 12:45 PM, Slávek Banko wrote:
Dne po 3. března 2014 Darrell napsal(a):
this is to remind everybody that as of today, R14.0.0 has been declared feature-frozen (soft-freeze). No new apps, kde->tde renames, major enhancement will be included in R14.0.0 and they will have to wait for the next release.
I have a pytdeextensions patch I finished yesterday that does nothing but kde->tde and qt->tqt renames. I can push or open a bug report. Based upon everything I saw , I suspect nobody uses pytdeextensions anyway.
pytdeextensions is necessary for tde-guidance. And tde-guidance now FTBFS. This is not good.
Once the list is fully completed and agreed upon, we should make it the official list and IMO we should declare R14.0.0 as hard-frozen.
I think we ought to play wack-o-mole and get a nice hunk of bugs resolved before moving to hard freeze.
I agree - not good freeze when serious bugs. For example, as of now FTBFS in kchmviewer and tde-guidance.
In the meantime, feel free to suggest what bugs you would like to see fixed in R14.0.0 and if you are willing to work on any of them. Please keep in mind that we want to keep the list as short as possible, in order to release R14.0.0 in a timely manner. Therefore bugs should fit in one of the next categories (in order of priority):
- blockers
- criticals
- cause major loss of functionality to the system or to the user
- results in loss of functionality that could affect R14 release
reviews negatively (such as help buttons not working for example)
Please do not suggest bugs that do not fit in one of these categories.
Every time this kind of discussion arises I am the lone voice that is ignored. Everybody focuses on Blocker and Critical bugs. The bug list needs to include paper cut issues.
http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd= Regressions&list_id=237 http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd= stdout%2Fstderr&list_id=236
For this reason, I'm not sure if just now he have to deal with KXMLEditor and Katesort plugin. There are several other applications on which François worked hard, and which also waiting for inclusion into GIT. The only difference is that around them at present is not such a stir.
For example, for me, is critical twinkle. Francois on it did a lot of effort, but because it is a complicated application, its integration I've had to postpone - regardless of the fact that "for me" is critical.
Darrell
Then it looks like we are freezing too soon. If we do not even have time to include things that are already complete and simply need to be added, DO NOT FREEZE ANYTHING.
SECOND -- as long as renaming continues DO NOT FREEZE. Renaming is guaranteed to BREAK things intended or not.
Solution - Until renaming is complete DO NOT FREEZE -- it is pointless while renaming continues. Nobody can give any type of educated "it's ready to freeze" when nobody has had a chance to build the code that is to be frozen.
If we must continue to rename, then set the soft freeze date 3 days after renaming is complete -- otherwise we are setting ourselves up for failure and we are pushing off functional additions to TDE for sake of renaming.
We should not be in this position on the proposed soft-freeze date.
Dne po 3. března 2014 David C. Rankin napsal(a):
On 03/03/2014 12:45 PM, Slávek Banko wrote:
Dne po 3. března 2014 Darrell napsal(a):
this is to remind everybody that as of today, R14.0.0 has been declared feature-frozen (soft-freeze). No new apps, kde->tde renames, major enhancement will be included in R14.0.0 and they will have to wait for the next release.
I have a pytdeextensions patch I finished yesterday that does nothing but kde->tde and qt->tqt renames. I can push or open a bug report. Based upon everything I saw , I suspect nobody uses pytdeextensions anyway.
pytdeextensions is necessary for tde-guidance. And tde-guidance now FTBFS. This is not good.
Once the list is fully completed and agreed upon, we should make it the official list and IMO we should declare R14.0.0 as hard-frozen.
I think we ought to play wack-o-mole and get a nice hunk of bugs resolved before moving to hard freeze.
I agree - not good freeze when serious bugs. For example, as of now FTBFS in kchmviewer and tde-guidance.
In the meantime, feel free to suggest what bugs you would like to see fixed in R14.0.0 and if you are willing to work on any of them. Please keep in mind that we want to keep the list as short as possible, in order to release R14.0.0 in a timely manner. Therefore bugs should fit in one of the next categories (in order of priority): - blockers
- criticals
- cause major loss of functionality to the system or to the user
- results in loss of functionality that could affect R14 release
reviews negatively (such as help buttons not working for example)
Please do not suggest bugs that do not fit in one of these categories.
Every time this kind of discussion arises I am the lone voice that is ignored. Everybody focuses on Blocker and Critical bugs. The bug list needs to include paper cut issues.
http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedc md= Regressions&list_id=237 http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedc md= stdout%2Fstderr&list_id=236
For this reason, I'm not sure if just now he have to deal with KXMLEditor and Katesort plugin. There are several other applications on which François worked hard, and which also waiting for inclusion into GIT. The only difference is that around them at present is not such a stir.
For example, for me, is critical twinkle. Francois on it did a lot of effort, but because it is a complicated application, its integration I've had to postpone - regardless of the fact that "for me" is critical.
Darrell
Then it looks like we are freezing too soon. If we do not even have time to include things that are already complete and simply need to be added, DO NOT FREEZE ANYTHING.
SECOND -- as long as renaming continues DO NOT FREEZE. Renaming is guaranteed to BREAK things intended or not.
Solution - Until renaming is complete DO NOT FREEZE -- it is pointless while renaming continues. Nobody can give any type of educated "it's ready to freeze" when nobody has had a chance to build the code that is to be frozen.
If we must continue to rename, then set the soft freeze date 3 days after renaming is complete -- otherwise we are setting ourselves up for failure and we are pushing off functional additions to TDE for sake of renaming.
We should not be in this position on the proposed soft-freeze date.
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.
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...
Not in the list: kchmviewer.
Darrell
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)
On Monday 03 of March 2014 22:06:46 Darrell wrote:
- kchmviewer FTBFS due to commit 3aef1afb
What broke? The package builds fine here.
Darrell
Causes FTBFS on all supported versions and platforms of Debian and Ubuntu:
i686-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../src -I/usr/share/tqt3/include -include tqt.h -I/opt/trinity/include -I../../lib/libchmfile -I../../src -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT kchmsetupdialog.o -MD -MP -MF .deps/kchmsetupdialog.Tpo -c -o kchmsetupdialog.o ../../src/kchmsetupdialog.cpp ../../src/kchmsetupdialog.cpp:316:36: error: no 'void KCHMSetupDialog::slotShowHelp()' member function declared in class 'KCHMSetupDialog' make[4]: *** [kchmsetupdialog.o] Error 1
On Monday 03 of March 2014 22:14:36 Slávek Banko wrote:
On Monday 03 of March 2014 22:06:46 Darrell wrote:
- kchmviewer FTBFS due to commit 3aef1afb
What broke? The package builds fine here.
Darrell
Causes FTBFS on all supported versions and platforms of Debian and Ubuntu:
i686-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../src -I/usr/share/tqt3/include -include tqt.h -I/opt/trinity/include -I../../lib/libchmfile -I../../src -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT kchmsetupdialog.o -MD -MP -MF .deps/kchmsetupdialog.Tpo -c -o kchmsetupdialog.o ../../src/kchmsetupdialog.cpp ../../src/kchmsetupdialog.cpp:316:36: error: no 'void KCHMSetupDialog::slotShowHelp()' member function declared in class 'KCHMSetupDialog' make[4]: *** [kchmsetupdialog.o] Error 1
I just found the problem and solved - I'll push the fix soon.
On Mon March 3 2014 3:22:38 pm Slávek Banko wrote:
On Monday 03 of March 2014 22:14:36 Slávek Banko wrote:
On Monday 03 of March 2014 22:06:46 Darrell wrote:
- kchmviewer FTBFS due to commit 3aef1afb
What broke? The package builds fine here.
Darrell
Causes FTBFS on all supported versions and platforms of Debian and Ubuntu:
i686-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../src -I/usr/share/tqt3/include -include tqt.h -I/opt/trinity/include -I../../lib/libchmfile -I../../src -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT kchmsetupdialog.o -MD -MP -MF .deps/kchmsetupdialog.Tpo -c -o kchmsetupdialog.o ../../src/kchmsetupdialog.cpp ../../src/kchmsetupdialog.cpp:316:36: error: no 'void KCHMSetupDialog::slotShowHelp()' member function declared in class 'KCHMSetupDialog' make[4]: *** [kchmsetupdialog.o] Error 1
I just found the problem and solved - I'll push the fix soon.
kchmsetupdialog.h is created dynamically and does not declare KCHMSetupDialog::slotShowHelp?
Darrell
On Monday 03 of March 2014 22:43:03 Darrell wrote:
On Mon March 3 2014 3:22:38 pm Slávek Banko wrote:
On Monday 03 of March 2014 22:14:36 Slávek Banko wrote:
On Monday 03 of March 2014 22:06:46 Darrell wrote:
- kchmviewer FTBFS due to commit 3aef1afb
What broke? The package builds fine here.
Darrell
Causes FTBFS on all supported versions and platforms of Debian and Ubuntu:
i686-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../src -I/usr/share/tqt3/include -include tqt.h -I/opt/trinity/include -I../../lib/libchmfile -I../../src -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -g -O2 -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt -MT kchmsetupdialog.o -MD -MP -MF .deps/kchmsetupdialog.Tpo -c -o kchmsetupdialog.o ../../src/kchmsetupdialog.cpp ../../src/kchmsetupdialog.cpp:316:36: error: no 'void KCHMSetupDialog::slotShowHelp()' member function declared in class 'KCHMSetupDialog' make[4]: *** [kchmsetupdialog.o] Error 1
I just found the problem and solved - I'll push the fix soon.
kchmsetupdialog.h is created dynamically and does not declare KCHMSetupDialog::slotShowHelp?
Darrell
Yes, exactly. Fixed in GIT hash 03824234.
Then it looks like we are freezing too soon. If we do not even have time to include things that are already complete and simply need to be added, DO NOT FREEZE ANYTHING.
SECOND -- as long as renaming continues DO NOT FREEZE. Renaming is guaranteed to BREAK things intended or not.
Solution - Until renaming is complete DO NOT FREEZE -- it is pointless while renaming continues. Nobody can give any type of educated "it's ready to freeze" when nobody has had a chance to build the code that is to be frozen.
If we must continue to rename, then set the soft freeze date 3 days after renaming is complete -- otherwise we are setting ourselves up for failure and we are pushing off functional additions to TDE for sake of renaming.
We should not be in this position on the proposed soft-freeze date.
A soft freeze is just that: soft. A soft freeze is the signal for the trainers to walk the horses toward the starting gate. The horses still get to pee and poop if they need to while they walk toward the gate and if they do, somebody is standing by with shovels and buckets. The hard freeze occurs when the back gates are closed.
Renaming will continue for a long time. Renaming halts duration the freeze but continues after the official release.
Breakage? Welcome to free/libre software. Breakage occurs daily. Just wait for the next upstream release of libpng or gcc. Or systemd that the RedHat folks have snookered most everybody into embracing hook, line, and sinker. Or the next time you update bleeding edge Arch and you start whining about build failures. People upstream are like the honey badger --- they don't give a shit about breakage downstream.
That said, perhaps we ought to consider when to invoke the soft freeze. What is utterly critical right now? Slavek mentions some FTBFS issues. There are several more FTBFS bug reports. Should we at least agree to resolve FTBFS issues before moving to the soft freeze?
And of course, nobody talks about paper cut issues, which drive away users faster than a wacked hornet's nest.
Darrell
My 2 cents on various topics.
1) On hard freeze Perhaps I used the wrong term or I didn't explain it clearly enough. What I meant was that once we finalize the list of bugs for v14.0.0, we need to create a milestone that says "this is what is going to be in v14.0.0". Obviously new FTBFS created by distro package upgrades will have to be addressed, but the point is to try to stop introducing new FTBFS/bugs due to source changes.
2) On not freezing until all renames are done If we want to release v14.0.0, at some point we need to stop making major changes and we need to focus on closing the outstanding bugs. I know that new apps, new renames, new features... are all nice things to have, but we need to avoid going through the same process that happened last year after the soft and hard freeze was declared in July.
3) On KXMLEditor and Katesort Personally I agree with Slavek, it would make more sense to add them after v14.0.0 (perhaps in v14.0.1) together with other new apps already available
4) On paper cut issues The question is the same as point 2). If we want to focus on v14.0.0 release, then we can not address all paper cut issues now (they would simply require too much time). Paper cut issues are a nice topic for maintenance releases (v14.0.x)
IMO we should finalize a plan for releasing v14.0.0 and then stick to it. If we don't or if we start making exceptions to it, in 6 months time we will still be discussing about the soft freeze.
Cheers Michele
On 03/03/2014 12:27 PM, Darrell wrote:
I have a pytdeextensions patch I finished yesterday that does nothing
but kde->tde and qt->tqt renames. I can push or open a bug report. <
I think we ought to play wack-o-mole and get a nice hunk of bugs
resolved before moving to hard freeze.<
Every time this kind of discussion arises I am the lone voice that is
ignored. Everybody focuses on Blocker and Critical bugs. The bug list needs to include paper cut issues. <
If these were the primary foci of R15.0.0, how long would be needed?
-
Darrell -
David C. Rankin -
James Gholston -
Michele Calgaro -
Slávek Banko