3 Mar
2014
3 Mar
'14
8:06 a.m.
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
3 Mar
3 Mar
6:27 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
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=…
http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd=…
Darrell
6:45 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
Dne po 3. března 2014 Darrell napsal(a):
pytdeextensions is necessary for tde-guidance. And tde-guidance now FTBFS.
This is not good.
I agree - not good freeze when serious bugs. For example, as of now FTBFS
in kchmviewer and tde-guidance.
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.
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=
Regressions&list_id=237
http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd=
stdout%2Fstderr&list_id=236
Darrell
--
Slavek
7:08 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
On 03/03/2014 12:45 PM, Slávek Banko wrote:
Dne po 3. března 2014 Darrell napsal(a):
pytdeextensions is necessary for tde-guidance. And tde-guidance now FTBFS.
This is not good.
I agree - not good freeze when serious bugs. For example, as of now FTBFS
in kchmviewer and tde-guidance.
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.
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.
--
David C. Rankin, J.D.,P.E.
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=
Regressions&list_id=237
http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedcmd=
stdout%2Fstderr&list_id=236
Darrell
7:20 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
Dne po 3. března 2014 David C. Rankin napsal(a):
On 03/03/2014 12:45 PM, Slávek Banko 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.
--
Slavek
Dne po 3. března 2014 Darrell napsal(a):
pytdeextensions is necessary for tde-guidance. And tde-guidance now
FTBFS. This is not good.
I agree - not good freeze when serious bugs. For example, as of now
FTBFS in kchmviewer and tde-guidance.
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. 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&namedc
md= Regressions&list_id=237
http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedc
md= stdout%2Fstderr&list_id=236
8:18 p.m.
New subject: [trinity-devel] R14.0.0 soft 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_s…
Not in the list: kchmviewer.
Darrell
8:52 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
On Monday 03 of March 2014 21:18:48 Darrell wrote:
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
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
9:14 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
On Monday 03 of March 2014 22:06:46 Darrell wrote:
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
--
Slavek
+ kchmviewer
FTBFS due to commit 3aef1afb
What broke? The package builds fine here.
Darrell
9:22 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
On Monday 03 of March 2014 22:14:36 Slávek Banko wrote:
On Monday 03 of March 2014 22:06:46 Darrell wrote:
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.
--
Slavek
+
kchmviewer FTBFS due to commit 3aef1afb
What broke? The package builds fine here.
Darrell
9:43 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
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:
kchmsetupdialog.h is created dynamically and does not declare
KCHMSetupDialog::slotShowHelp?
Darrell
On Monday 03 of March 2014 22:06:46 Darrell
wrote:
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.
+
kchmviewer FTBFS due to commit 3aef1afb
What broke? The package builds fine here.
Darrell
9:49 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
On Monday 03 of March 2014 22:43:03 Darrell wrote:
On Mon March 3 2014 3:22:38 pm Slávek Banko wrote:
Yes, exactly. Fixed in GIT hash 03824234.
--
Slavek
On Monday 03 of March 2014 22:14:36 Slávek Banko
wrote:
kchmsetupdialog.h is created dynamically and does not declare
KCHMSetupDialog::slotShowHelp?
Darrell
On Monday 03 of March 2014 22:06:46 Darrell
wrote:
I just found the problem and solved - I'll push the fix soon. > + 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
7:37 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
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
4 Mar
4 Mar
3:57 a.m.
New subject: [trinity-devel] R14.0.0 soft freeze
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
3 Mar
3 Mar
6:59 p.m.
New subject: [trinity-devel] R14.0.0 soft freeze
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?
3716
days inactive
3717
days old
15 comments
5 participants
participants (5)
-
Darrell -
David C. Rankin -
James Gholston -
Michele Calgaro -
Slávek Banko