A proposal: We rename 3.5.13.1 to 3.5.14 and release Real Soon Now. We rename R14 to R15.
We do some serious testing with the version changes to ensure our build scripts work. We set a goal to release 3.5.14 within a month. We stop twiddling our thumbs and move forward.
Few people are going to pay attention that 3.5.13.1 is available. Not to mention that after almost a year we release only an SRU version? People will pay more attention that 3.5.14 is available. Basic marketing psychology.
Yes, currently 3.5.14 (3.5.13.1) does not support a HAL-less system. We add Serghei's udisks support and run some serious short term testing. Even if udisks support is incomplete, within the month we advertise that 3.5.14 offers partial support for HAL-less systems and that R15 will provide full support.
The free/libre software world moves fast. Trinity has not been in the news in any meaningful way for almost a year. Users are not going to wait for Trinity. People forget.
The latest challenges with automounting means some serious work ahead before R15 can be released, not to mention that the bug tracker continues to grow with little resolution progress. We are falling behind.
Not a great image. We decide whether Trinity is going to move forward or become a niche piece of software used only by a relatively few people.
The longer we proverbially fiddle while Rome burns, the easier users forget about Trinity. We release 3.5.14 because we need a stable release, which 3.5.13 was not and the current R14 is not, and because we need to get Trinity back into the news.
The current R14 (proposed R15) has too many bugs and build issues to be considered for release in the near future. How long do we keep fiddling? We should release 3.5.14 Real Soon Now.
We get serious about releasing something Real Soon Now to keep Trinity in the news, or accept our fate as a niche project.
We can do this if we get serious. Or we keep picking the lint out of our belly buttons.
Basically, summer vacation needs to end. :-)
Thoughts?
Darrell
On 28 August 2012 15:26, Darrell Anderson humanreadable@yahoo.com wrote:
A proposal: We rename 3.5.13.1 to 3.5.14 and release Real Soon Now. We rename R14 to R15.
We do some serious testing with the version changes to ensure our build scripts work. We set a goal to release 3.5.14 within a month. We stop twiddling our thumbs and move forward.
Few people are going to pay attention that 3.5.13.1 is available. Not to mention that after almost a year we release only an SRU version? People will pay more attention that 3.5.14 is available. Basic marketing psychology.
Yes, currently 3.5.14 (3.5.13.1) does not support a HAL-less system. We add Serghei's udisks support and run some serious short term testing. Even if udisks support is incomplete, within the month we advertise that 3.5.14 offers partial support for HAL-less systems and that R15 will provide full support.
The free/libre software world moves fast. Trinity has not been in the news in any meaningful way for almost a year. Users are not going to wait for Trinity. People forget.
The latest challenges with automounting means some serious work ahead before R15 can be released, not to mention that the bug tracker continues to grow with little resolution progress. We are falling behind.
Not a great image. We decide whether Trinity is going to move forward or become a niche piece of software used only by a relatively few people.
The longer we proverbially fiddle while Rome burns, the easier users forget about Trinity. We release 3.5.14 because we need a stable release, which 3.5.13 was not and the current R14 is not, and because we need to get Trinity back into the news.
The current R14 (proposed R15) has too many bugs and build issues to be considered for release in the near future. How long do we keep fiddling? We should release 3.5.14 Real Soon Now.
We get serious about releasing something Real Soon Now to keep Trinity in the news, or accept our fate as a niche project.
We can do this if we get serious. Or we keep picking the lint out of our belly buttons.
Basically, summer vacation needs to end. :-)
Thoughts?
Darrell
In my mind 3.5.13.1 has been already complete for several months. It's obvious that only a few small patches are making their way in nowadays
Push that as a release asap!
In my mind 3.5.13.1 has been already complete for several months. It's obvious that only a few small patches are making their way in nowadays
Push that as a release asap!
I won't be able to run an official build set from anything other than GIT head, but if Slavek has 3.5.13.1 built for all our supported Debian and Ubuntu versions I can go ahead and release an SRU from that.
Slavek or someone better acquainted with GIT than I am will need to generate source tarballs as well, as I cannot use the normal automation to generate tarballs from an SRU tag in GIT.
You know as well as I do that we're going to get the usual slew of "they still use HAL", "network-manager doesn't work", "where are the new features", etc. from the community if 3.5.13.1 is released as 3.5.14. This would further damage our image and I strongly recommend against it. Releasing an SRU instead indicates that we are concerned about product quality.
Tim
Push that as a release asap!
I won't be able to run an official build set from anything other than GIT head, but if Slavek has 3.5.13.1 built for all our supported Debian and Ubuntu versions I can go ahead and release an SRU from that.
Slavek or someone better acquainted with GIT than I am will need to generate source tarballs as well, as I cannot use the normal automation to generate tarballs from an SRU tag in GIT.
You know as well as I do that we're going to get the usual slew of "they still use HAL", "network-manager doesn't work", "where are the new features", etc. from the community if 3.5.13.1 is released as 3.5.14. This would further damage our image and I strongly recommend against it. Releasing an SRU instead indicates that we are concerned about product quality.
The overall lack of inactivity affects our image.
The growing size of the bug tracker affects our image because resolutions are not forthcoming in equal or higher numbers.
We're going to get the usal slew of comments one way or another. :-)
Darrell
Dne st 29. srpna 2012 Darrell Anderson napsal(a):
Push that as a release asap!
I won't be able to run an official build set from anything other than GIT head, but if Slavek has 3.5.13.1 built for all our supported Debian and Ubuntu versions I can go ahead and release an SRU from that.
Slavek or someone better acquainted with GIT than I am will need to generate source tarballs as well, as I cannot use the normal automation to generate tarballs from an SRU tag in GIT.
You know as well as I do that we're going to get the usual slew of "they still use HAL", "network-manager doesn't work", "where are the new features", etc. from the community if 3.5.13.1 is released as 3.5.14. This would further damage our image and I strongly recommend against it. Releasing an SRU instead indicates that we are concerned about product quality.
The overall lack of inactivity affects our image.
The growing size of the bug tracker affects our image because resolutions are not forthcoming in equal or higher numbers.
We're going to get the usal slew of comments one way or another. :-)
Darrell
It is true that from originally expected "small" update the work has grown greatly. 3.5.13.1 now contains a large number of fixes. If we were release updated versions more often, it could be now for example 3.5.13.5 :)
However, I would suggest to leave the version as it is now == 3.5.13.x and R14.x.x. I believe that the changing version labels now would be for others confusing rather than helpful. For me, from experiences gained by working on the SRU, follows that for future bugfix versions instead of focusing on solving "all" discovered bugs we should prefer to release bugfix versions more often.
My tasklist for 3.5.13.1 contain:
+ fix kstreamripper - bugs #1189, #946 - now I have patch for v3.5.13-sru, but I want to put it to be in accordance with changes in R14
+ fix kde-guidance - bug #1188 - it should be simple - but help is welcome
+ fix kde-style-qtcurve - bug #1109 - I need help with this
+ create v3.5.13-sru branch on meta-project 'tde' - I have almost done - soon I will send a draft modifications to scripts to be applicable for all GIT branches
+ cherry-pick patches to change doc path from kde/HTML to tde/HTML - patches is a lot, but integration should be straightforward - this should be done quickly
Slavek --
It is true that from originally expected "small" update the work has grown greatly. 3.5.13.1 now contains a large number of fixes. If we were release updated versions more often, it could be now for example 3.5.13.5 :)
In that light I'd like to resurrect a recent proposal:
A project goal of regular point releases.
A proven method of discouraging people is to create a to-do list that is too large. Over the summer that happened to us. The bug tracker grew without a respective proportional resolution response. We feel overwhelmed.
A proven method for slow production is a lack of goals.
Seems this summer we adopted a "Yawn, release whenever..." philosophy. The project seems to be stagnating. We seem unable to attract talent. We want to restore our motivation and vigor. We do that with goals and organizing those goals into workable sizes. We use project goals or we get lured into apathy and discouragement.
I prefer a sensible balance between the "release when ready" and "release early, release often" philosophies. We can embrace both philosophies and benefit as well.
For the very near future, we finalize the 3.5.13.1 release. Get that release out the door as soon as practical. Based upon Slavek's reports I believe we are very close to that moment. As soon as tarballs are available we start final testing and prepare a news release for the big day.
We set a project goal to release R14 three months after officially releasing 3.5.13.1.
Presuming 3.5.13.1 is released officially no later than Sept. 30, we release R14.0.0 Dec. 31.
R14 becomes our stable branch with the main GIT being our R15 development branch.
We embrace these goals while avoiding feelings of being overwhelmed.
That means evaluating R14 and the bug tracker in a realistic manner.
For R14 we focus on those bug reports that must be fixed for a stable release. That does not mean all build issues need be resolved when a short-term work-around is known. We can live with build issue work-arounds for the short-term but we can't live with usability breakage. We resolve as many build issues as practical, but we focus on serious usability bugs.
To avoid discouragement we remind ourselves that releasing a stable product does not mean releasing a perfect product. Anyone involved with software development knows that perfect code does not exist. A perfect product is a laudable goal but a stable product is a realistic goal. The point release schedule helps us support both goals.
We support point releases (R14.1.0, R14.2.0, etc.) every 8 weeks, but we don't overwhelm ourselves with biting more than we can chew.
As a small project, only 10 to 12 bug fixes need constitute a point release. That equates to only one to two bug resolutions per week. We can and have been doing that. This slow-but-steady approach helps us resolve certain irritants, such as improving TDEHWLIB to replace HAL; fix unknown libpng, gcc, and glib2/c bugs; building koffice with libwpd >=0.9; etc.
Much of the time bug fix patches will be applied to both the development and stable branches. Yet point releases contain only non ABI/API breaking bug fixes and enhancements, much like the patches that have been backported for 3.5.13.1.
Serious security patches are released as needed (R14.0.1, R14.1.1, etc.), regardless of our schedule. Serious security patches do not modify the normal point release schedule. Most of the time we don't need a special security release --- security patches can be slipstreamed into the regular point release.
With regular point releases we avoid the impossible task of resolving everything all at once. We avoid apathy and discouragement. We instead resolve bugs and enhancements in a steady methodical manner.
Regularly scheduled point releases embraces the "release early, release often" philosophy. Including ABI/API breaking patches only in the development branch embraces the "release when ready" philosophy.
To support R15, which includes ABI/API changes, we maintain a separate GIT development branch. We already do this by supporting R14 and 3.5.13.1. Basically, after we release R14, 3.5.13.1 gets semi-frozen with only the most serious patches being backported, R14 replaces 3.5.13.1 as the stable branch, and the main GIT becomes R15. Serious patches for 3.5.13.1 are released as patches --- we don't release new tarballs.
By releasing point releases every 8 weeks we keep Trinity in the news. We have failed miserably at that. Publicity is a must-have for a project as small as ours. We all admit we are falling behind and starting to drown. Publicity is a great way for us to attract talent. With a point release every 8 weeks, end-users start believing the project is not only alive but active. End-users start believing _in_ the project. This slow-but-steady progress encourages distro maintainers and third-party packagers to include Trinity in their favorite distro. The effect is a proverbial snowball rolling down a hill.
And we do this without overwhelming ourselves.
By embracing these goals we steadily reduce the bug tracker size and avoid discouragement. By doing that we provide a healthy atmosphere and feeling among the community because everybody observes regular progress and hopefully, we read increased online positive reviews. Everybody feels good. Everybody wins. Trinity stays healthy and vibrant.
Darrell
This is a long top-post : sorry in advance:
To be honest, many of these things come not from a lack of communication, but one that is constantly active.
I'm at fault for some of that; school has become quite tedious that I no longer have the time I once had to host meetings every month.
But also, there's no push for information. No "how's the SRU going?" or "What bugs should we try tackling thi week?".
Or even "What changes are planned for this week?"
I know that at Blackboard, where I interned for the past summer, teams had rallies every week. I propose we do the same.
Clearly they can't be live (seriously, some of you guys don't show up at IRC meetings, plus they take forever). So maybe a weekly email sent out to the devel list asking for "what have you done the past week and what are you going to do this week". Replies to that email thread would help us keep track of what's what.
On Aug 31, 2012, at 13:25, Darrell Anderson humanreadable@yahoo.com wrote:
It is true that from originally expected "small" update the work has grown greatly. 3.5.13.1 now contains a large number of fixes. If we were release updated versions more often, it could be now for example 3.5.13.5 :)
In that light I'd like to resurrect a recent proposal:
A project goal of regular point releases.
A proven method of discouraging people is to create a to-do list that is too large. Over the summer that happened to us. The bug tracker grew without a respective proportional resolution response. We feel overwhelmed.
A proven method for slow production is a lack of goals.
Seems this summer we adopted a "Yawn, release whenever..." philosophy. The project seems to be stagnating. We seem unable to attract talent. We want to restore our motivation and vigor. We do that with goals and organizing those goals into workable sizes. We use project goals or we get lured into apathy and discouragement.
I prefer a sensible balance between the "release when ready" and "release early, release often" philosophies. We can embrace both philosophies and benefit as well.
For the very near future, we finalize the 3.5.13.1 release. Get that release out the door as soon as practical. Based upon Slavek's reports I believe we are very close to that moment. As soon as tarballs are available we start final testing and prepare a news release for the big day.
We set a project goal to release R14 three months after officially releasing 3.5.13.1.
Presuming 3.5.13.1 is released officially no later than Sept. 30, we release R14.0.0 Dec. 31.
R14 becomes our stable branch with the main GIT being our R15 development branch.
We embrace these goals while avoiding feelings of being overwhelmed.
That means evaluating R14 and the bug tracker in a realistic manner.
For R14 we focus on those bug reports that must be fixed for a stable release. That does not mean all build issues need be resolved when a short-term work-around is known. We can live with build issue work-arounds for the short-term but we can't live with usability breakage. We resolve as many build issues as practical, but we focus on serious usability bugs.
To avoid discouragement we remind ourselves that releasing a stable product does not mean releasing a perfect product. Anyone involved with software development knows that perfect code does not exist. A perfect product is a laudable goal but a stable product is a realistic goal. The point release schedule helps us support both goals.
We support point releases (R14.1.0, R14.2.0, etc.) every 8 weeks, but we don't overwhelm ourselves with biting more than we can chew.
As a small project, only 10 to 12 bug fixes need constitute a point release. That equates to only one to two bug resolutions per week. We can and have been doing that. This slow-but-steady approach helps us resolve certain irritants, such as improving TDEHWLIB to replace HAL; fix unknown libpng, gcc, and glib2/c bugs; building koffice with libwpd >=0.9; etc.
Much of the time bug fix patches will be applied to both the development and stable branches. Yet point releases contain only non ABI/API breaking bug fixes and enhancements, much like the patches that have been backported for 3.5.13.1.
Serious security patches are released as needed (R14.0.1, R14.1.1, etc.), regardless of our schedule. Serious security patches do not modify the normal point release schedule. Most of the time we don't need a special security release --- security patches can be slipstreamed into the regular point release.
With regular point releases we avoid the impossible task of resolving everything all at once. We avoid apathy and discouragement. We instead resolve bugs and enhancements in a steady methodical manner.
Regularly scheduled point releases embraces the "release early, release often" philosophy. Including ABI/API breaking patches only in the development branch embraces the "release when ready" philosophy.
To support R15, which includes ABI/API changes, we maintain a separate GIT development branch. We already do this by supporting R14 and 3.5.13.1. Basically, after we release R14, 3.5.13.1 gets semi-frozen with only the most serious patches being backported, R14 replaces 3.5.13.1 as the stable branch, and the main GIT becomes R15. Serious patches for 3.5.13.1 are released as patches --- we don't release new tarballs.
By releasing point releases every 8 weeks we keep Trinity in the news. We have failed miserably at that. Publicity is a must-have for a project as small as ours. We all admit we are falling behind and starting to drown. Publicity is a great way for us to attract talent. With a point release every 8 weeks, end-users start believing the project is not only alive but active. End-users start believing _in_ the project. This slow-but-steady progress encourages distro maintainers and third-party packagers to include Trinity in their favorite distro. The effect is a proverbial snowball rolling down a hill.
And we do this without overwhelming ourselves.
By embracing these goals we steadily reduce the bug tracker size and avoid discouragement. By doing that we provide a healthy atmosphere and feeling among the community because everybody observes regular progress and hopefully, we read increased online positive reviews. Everybody feels good. Everybody wins. Trinity stays healthy and vibrant.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
To be honest, many of these things come not from a lack of communication, but one that is constantly active.
I'm at fault for some of that; school has become quite tedious that I no longer have the time I once had to host meetings every month.
But also, there's no push for information. No "how's the SRU going?" or "What bugs should we try tackling this week?".
Or even "What changes are planned for this week?"
I know that at Blackboard, where I interned for the past summer, teams had rallies every week. I propose we do the same.
Clearly they can't be live (seriously, some of you guys don't show up at IRC meetings, plus they take forever). So maybe a weekly email sent out to the devel list asking for "what have you done the past week and what are you going to do this week". Replies to that email thread would help us keep track of what's what.
I am not concerned with assigning fault or blame, which rarely solves problems. :-) I am focused on keeping this project moving forward in a positive manner.
As you noted, communication must be meaningful. I can communicate with the walls in my house any time I want. I pretty much feel that is what I am doing the past few months when I post to this list. :-) I get discouraged when I post to this list and receive no responses.
I get the feeling either there are only a few subscribers remaining on this list or that most of those who are subscribed no longer care. There was a time not long ago when this list was vibrant and responses to posts were common. Not anymore.
We do nothing to show we are a vibrant or active community. :-(
We have no published goals, long-term or short-term. :-(
I like the idea of a weekly "What happened this week" email request to the list. I volunteer to post that email every week. I volunteer to write a weekly status report as I shared examples in a previous email. I already have configured kalarm to remind me.
To keep the entire community informed I believe the summaries should be posted to the RSS feed and to appropriate mail lists.
Will such an effort bear fruit?
Darrell
<snip>
To keep the entire community informed I believe the summaries should be posted to the RSS feed and to appropriate mail lists.
If someone wants to write them, I can ingest them into the Web site manually for now. In the future there should be a "drop box" where the assigned news person/people can upload new articles; much of this is already in place but I don't have access control methods written yet, therefore I cannot yet make the drop box available to the Internet.
Tim
To keep the entire community informed I believe the summaries should be posted to the RSS feed and to appropriate mail lists.
If someone wants to write them, I can ingest them into the Web site manually for now. In the future there should be a "drop box" where the assigned news person/people can upload new articles; much of this is already in place but I don't have access control methods written yet, therefore I cannot yet make the drop box available to the Internet.
Fair enough. We'll see how this goes. :-)
I scheduled my kalarm to remind me to request information every Sunday afternoon, for the previous Sunday -> Saturday week.
I scheduled my kalarm to remind me to post the status report on Tuesday. That provides 48 hours for list members to respond.
I will post the status report to this list. As you will, for the time being, be grabbing those emails to forward to the RSS feed, should I CC the status report emails to trinity-announce and and trinity-users?
Darrell
To keep the entire community informed I believe the summaries should
be
posted to the RSS feed and to appropriate mail lists.
If someone wants to write them, I can ingest them into the Web site manually for now. In the future there should be a "drop box" where the assigned news person/people can upload new articles; much of this is already in place but I don't have access control methods written yet, therefore I cannot yet make the drop box available to the Internet.
Fair enough. We'll see how this goes. :-)
I scheduled my kalarm to remind me to request information every Sunday afternoon, for the previous Sunday -> Saturday week.
I scheduled my kalarm to remind me to post the status report on Tuesday. That provides 48 hours for list members to respond.
I will post the status report to this list. As you will, for the time being, be grabbing those emails to forward to the RSS feed, should I CC the status report emails to trinity-announce and and trinity-users?
Darrell
Send them to trinity-devel and trinity-users, and I'll do the rest. Bear in mind that CCing to two different lists doesn't work very well (users end up replying to the -devel list and vice-versa depending on which one was CCed to), so you should send one Email to each list.
Tim
-
Calvin Morrison -
Darrell Anderson -
Robert Xu -
Slávek Banko -
Timothy Pearson