28 Aug
2012
28 Aug
'12
7:26 p.m.
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
28 Aug
28 Aug
7:29 p.m.
New subject: [trinity-devel] A Project Proposal: Trinity 3.5.14
On 28 August 2012 15:26, Darrell Anderson <humanreadable(a)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!
8:59 p.m.
New subject: [trinity-devel] A Project Proposal: Trinity 3.5.14
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
10:22 p.m.
New subject: [trinity-devel] A Project Proposal: Trinity 3.5.14
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. 
29 Aug
29 Aug
4:01 p.m.
New subject: [trinity-devel] A Project Proposal: Trinity 3.5.14
Dne st 29. srpna 2012 Darrell Anderson napsal(a):
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
--
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.
31 Aug
31 Aug
5:25 p.m.
New subject: [trinity-devel] A Project Proposal: Trinity 3.5.14
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
1 Sep
1 Sep
4:20 a.m.
New subject: [trinity-devel] A Project Proposal: Trinity 3.5.14
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(a)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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
8:02 p.m.
New subject: [trinity-devel] A Project Proposal: Trinity 3.5.14
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
8:06 p.m.
New subject: [trinity-devel] A Project Proposal: Trinity 3.5.14
<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
8:32 p.m.
New subject: [trinity-devel] Weekly Status Reports
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.
10:06 p.m.
New subject: [trinity-devel] Weekly Status Reports
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.
4260
days inactive
4264
days old
10 comments
5 participants
participants (5)
-
Calvin Morrison -
Darrell Anderson -
Robert Xu -
Slávek Banko -
Timothy Pearson