In light of recent public criticisms about Trinity's stability, do we have a plan or do we allow for sufficient time for usability testing? The focus seems to be about patching, packaging, and releases. Perhaps with the next release we should introduce a fixed time for serious usability testing? Proverbially, we all eat our own dog food before releasing the software?
If a wider window for testing means a shorter window for code hacking then I vote for that. We don't adopt a testing window and code freeze as long as a large project like Debian, :) but we should officially promote a wide enough window to eat our own dog food. :)
We touched upon this topic yesterday but I want to bring the topic to the table in a more "official" manner. :)
Darrell
On Wednesday 16 November 2011 12:20:52 pm Darrell Anderson wrote:
In light of recent public criticisms about Trinity's stability, do we have a plan or do we allow for sufficient time for usability testing? The focus seems to be about patching, packaging, and releases. Perhaps with the next release we should introduce a fixed time for serious usability testing? Proverbially, we all eat our own dog food before releasing the software?
If a wider window for testing means a shorter window for code hacking then I vote for that. We don't adopt a testing window and code freeze as long as a large project like Debian, :) but we should officially promote a wide enough window to eat our own dog food. :)
We touched upon this topic yesterday but I want to bring the topic to the table in a more "official" manner. :)
I'm a fan of the "when it works" release cycle. I don't think having a specific release date is a good idea (though certainly taking a very long time to release is bad too).
I think we should have a QA check list, something like:
-Solicit ideas for the next release -Prioritize new features --Which features are most important for next release? -Solicit testing for: --Usability --Stability --New features -Paper cut bugs
That's just off the top of my head, I don't know that it's complete, but I think it's a start.
On Wed, Nov 16, 2011 at 5:36 PM, Kristopher John Gamrat < chaotickjg@gmail.com> wrote:
On Wednesday 16 November 2011 12:20:52 pm Darrell Anderson wrote:
In light of recent public criticisms about Trinity's stability, do we
have
a plan or do we allow for sufficient time for usability testing? The
focus
seems to be about patching, packaging, and releases. Perhaps with the
next
release we should introduce a fixed time for serious usability testing? Proverbially, we all eat our own dog food before releasing the software?
If a wider window for testing means a shorter window for code hacking
then
I vote for that. We don't adopt a testing window and code freeze as long
as
a large project like Debian, :) but we should officially promote a wide enough window to eat our own dog food. :)
We touched upon this topic yesterday but I want to bring the topic to the table in a more "official" manner. :)
I'm a fan of the "when it works" release cycle. I don't think having a specific release date is a good idea (though certainly taking a very long time to release is bad too).
I think we should have a QA check list, something like:
-Solicit ideas for the next release -Prioritize new features --Which features are most important for next release? -Solicit testing for: --Usability --Stability --New features -Paper cut bugs
That's just off the top of my head, I don't know that it's complete, but I think it's a start.
As I discussed with Timothy close to the release date, doing more QA for the next release seems necessary since there are quite a few bugs not present on the last KDE release but present on Trinity. I'm available to help testing and bug reporting, hopefully also for bug fixing.
Best regards, Tiago
-- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
As I discussed with Timothy close to the release date, doing more QA for the next release seems necessary since there are quite a few bugs not present on the last KDE release but present on Trinity. I'm available to help testing and bug reporting, hopefully also for bug fixing.
Best regards, Tiago
On this topic I would like to announce that R14.0 will be a bugfix release only. No large new features within the core system will be accepted.
However, there are a couple of applications that we should include in R14.0. kvpnc springs to mind due to NetworkManager's recent API change and tendency to fail even with the Gnome nm-applet, and there are more requests for useful applications on the bugtracker.
Tim
On 16 November 2011 14:22, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
As I discussed with Timothy close to the release date, doing more QA for the next release seems necessary since there are quite a few bugs not present on the last KDE release but present on Trinity. I'm available to help testing and bug reporting, hopefully also for bug fixing.
Best regards, Tiago
On this topic I would like to announce that R14.0 will be a bugfix release only. No large new features within the core system will be accepted.
However, there are a couple of applications that we should include in R14.0. kvpnc springs to mind due to NetworkManager's recent API change and tendency to fail even with the Gnome nm-applet, and there are more requests for useful applications on the bugtracker.
Tim
What o
On 16 November 2011 15:59, Calvin Morrison mutantturkey@gmail.com wrote:
On 16 November 2011 14:22, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
As I discussed with Timothy close to the release date, doing more QA for the next release seems necessary since there are quite a few bugs not present on the last KDE release but present on Trinity. I'm available to help testing and bug reporting, hopefully also for bug fixing.
Best regards, Tiago
On this topic I would like to announce that R14.0 will be a bugfix release only. No large new features within the core system will be accepted.
However, there are a couple of applications that we should include in R14.0. kvpnc springs to mind due to NetworkManager's recent API change and tendency to fail even with the Gnome nm-applet, and there are more requests for useful applications on the bugtracker.
Tim
What o
Seems my message was truncated.
What of samelians recent progress regarding UPower, and the HAL replacement?
Calvin Morrison
On 16 November 2011 15:59, Calvin Morrison mutantturkey@gmail.com wrote:
On 16 November 2011 14:22, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
As I discussed with Timothy close to the release date, doing more QA
for
the next release seems necessary since there are quite a few bugs not present on the last KDE release but present on Trinity. I'm available
to
help testing and bug reporting, hopefully also for bug fixing.
Best regards, Tiago
On this topic I would like to announce that R14.0 will be a bugfix release only. No large new features within the core system will be accepted.
However, there are a couple of applications that we should include in R14.0. kvpnc springs to mind due to NetworkManager's recent API change and tendency to fail even with the Gnome nm-applet, and there are more requests for useful applications on the bugtracker.
Tim
What o
Seems my message was truncated.
What of samelians recent progress regarding UPower, and the HAL replacement?
Calvin Morrison
I was unaware of this progress. Link please? :-)
We have to be careful. If HAL is replaced the QA period will be quite long, probably many months, just to make sure that it works 100% in all circumstances. My gut instinct is to wait for R15.0, but I need to see what Serghei has done first.
Tim
On 16 November 2011 16:09, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
On 16 November 2011 15:59, Calvin Morrison mutantturkey@gmail.com
wrote:
On 16 November 2011 14:22, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
As I discussed with Timothy close to the release date, doing more QA
for
the next release seems necessary since there are quite a few bugs not present on the last KDE release but present on Trinity. I'm available
to
help testing and bug reporting, hopefully also for bug fixing.
Best regards, Tiago
On this topic I would like to announce that R14.0 will be a bugfix release only. No large new features within the core system will be accepted.
However, there are a couple of applications that we should include in R14.0. kvpnc springs to mind due to NetworkManager's recent API change and tendency to fail even with the Gnome nm-applet, and there are more requests for useful applications on the bugtracker.
Tim
What o
Seems my message was truncated.
What of samelians recent progress regarding UPower, and the HAL replacement?
Calvin Morrison
I was unaware of this progress. Link please? :-)
We have to be careful. If HAL is replaced the QA period will be quite long, probably many months, just to make sure that it works 100% in all circumstances. My gut instinct is to wait for R15.0, but I need to see what Serghei has done first.
Tim
Do you intend this release to be shorter than 6 months?
Calvin Morrison
On 16 November 2011 16:09, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
On 16 November 2011 15:59, Calvin Morrison mutantturkey@gmail.com
wrote:
On 16 November 2011 14:22, Timothy Pearson kb9vqf@pearsoncomputing.netwrote:
As I discussed with Timothy close to the release date, doing more
QA
for
the next release seems necessary since there are quite a few bugs
not
present on the last KDE release but present on Trinity. I'm
available
to
help testing and bug reporting, hopefully also for bug fixing.
Best regards, Tiago
On this topic I would like to announce that R14.0 will be a bugfix release only. No large new features within the core system will be
accepted.
However, there are a couple of applications that we should include
in
R14.0. kvpnc springs to mind due to NetworkManager's recent API
change
and tendency to fail even with the Gnome nm-applet, and there are
more
requests for useful applications on the bugtracker.
Tim
What o
Seems my message was truncated.
What of samelians recent progress regarding UPower, and the HAL replacement?
Calvin Morrison
I was unaware of this progress. Link please? :-)
We have to be careful. If HAL is replaced the QA period will be quite long, probably many months, just to make sure that it works 100% in all circumstances. My gut instinct is to wait for R15.0, but I need to see what Serghei has done first.
Tim
Do you intend this release to be shorter than 6 months?
No. I intend to have a lot of the bugs fixed; at this point there are well over a hundred bugs open. This will take time to rectify.
Also, I am not allowing another release to be shoved out the door like 3.5.13 was. I am allocating ample QA time so as not to ship another buggy release.
Tim
On Wednesday 16 November 2011 23:09:20 Timothy Pearson wrote:
[...]
What of samelians recent progress regarding UPower, and the HAL replacement?
Calvin Morrison
I was unaware of this progress. Link please? :-)
Hehe, I wanted to do a surprise :)
This is what I did so far: www.thel.ro/upower.tar.gz
This is an abstract layer to upower interface. When will be finished, I will start to develop a replacement for kpowersave based on this layer. I intent to make it as a module for kcontrol (as Power Management or smth like this).
However, this will drop HAL partially, we will need to develop more abstraction layers (udisk, networkmanager, etc).
On Wednesday 16 November 2011 23:28:03 Serghei Amelian wrote:
On Wednesday 16 November 2011 23:09:20 Timothy Pearson wrote:
[...]
What of samelians recent progress regarding UPower, and the HAL replacement?
Calvin Morrison
I was unaware of this progress. Link please? :-)
Hehe, I wanted to do a surprise :)
This is what I did so far: www.thel.ro/upower.tar.gz
Also, I think my work is a good example for keeping binary backward compatibility, using extensively d-pointers.
http://en.wikipedia.org/wiki/Opaque_pointer
On Wednesday 16 November 2011 23:09:20 Timothy Pearson wrote:
[...]
What of samelians recent progress regarding UPower, and the HAL replacement?
Calvin Morrison
I was unaware of this progress. Link please? :-)
Hehe, I wanted to do a surprise :)
This is what I did so far: www.thel.ro/upower.tar.gz
This is an abstract layer to upower interface. When will be finished, I will start to develop a replacement for kpowersave based on this layer. I intent to make it as a module for kcontrol (as Power Management or smth like this).
However, this will drop HAL partially, we will need to develop more abstraction layers (udisk, networkmanager, etc).
Wow! I wasn't expecting that--nice work!
Are you following the proposed API on the Wiki? I only ask because the class names look familiar.
We can always add the new library to R14.0; the only QA-conditional application would be the kpowersave replacement. I'll wait for you to finish that portion and then take a look at it.
Keep up the good work!
Tim
On Wednesday 16 November 2011 23:40:49 Timothy Pearson wrote:
On Wednesday 16 November 2011 23:09:20 Timothy Pearson wrote:
[...]
What of samelians recent progress regarding UPower, and the HAL replacement?
Calvin Morrison
I was unaware of this progress. Link please? :-)
Hehe, I wanted to do a surprise :)
This is what I did so far: www.thel.ro/upower.tar.gz
This is an abstract layer to upower interface. When will be finished, I will start to develop a replacement for kpowersave based on this layer. I intent to make it as a module for kcontrol (as Power Management or smth like this).
However, this will drop HAL partially, we will need to develop more abstraction layers (udisk, networkmanager, etc).
Wow! I wasn't expecting that--nice work!
Hehe, thanks.
Are you following the proposed API on the Wiki?
Not exactly, I choose to follow DBus UPower specifications very closely.
I only ask because the class names look familiar.
We talk about it few months ago and I followed some of ideas (namespacing, templates for replies from DBus, etc). However, these are low level clases (mostly for speaking with DBus), we can use it to create more abstractized layers, if is needed.
We can always add the new library to R14.0; the only QA-conditional application would be the kpowersave replacement. I'll wait for you to finish that portion and then take a look at it.
No problem, for first release we can provide it as an extra-application (but I'm pretty sure that will work as expected).
-
Calvin Morrison -
Darrell Anderson -
Kristopher John Gamrat -
Serghei Amelian -
Tiago Marques -
Timothy Pearson