8 Jun
2012
8 Jun
'12
5:38 p.m.
We have a small team. Keeping Trinity moving forward is a challenge. Yet I believe we have
a committed and dedicated team, small or not, and somehow we keep moving forward.
I don't expect people to give up their day jobs to support Trinity, but I found this
article interesting:
http://www.h-online.com/open/news/item/Independent-software-developers-go-f…
I don't know what fund raising ideas we can use. Selling shirts and coffee cups
requires serious overhead and personnel. Yet sometimes I wonder what we could do to keep
Trinity moving at a nice speed.
Another idea I had today came from an RSS feed title:
"KDE SC 4.8.4 delivers monthly stabilization update"
After we release R14.0.0, I'm wondering whether we could do something similar. Every
month or so we release a point release for Trinity that includes bug fixes and possibly
one enhancement request.
Even if we push only two or three bug fixes, this monthly release would show the project
is alive and well. A monthly stablization release also is great public relations because
the various news people publish those press releases.
A monthly release does not mean a complete overhaul of the mirrors, etc. We would need
only resync those packages that change. At three or four bug resolutions that likely would
mean only a package or two changes.
A monthly stablization release will be much easier to manage after R14 than trying to
backport patches for 3.5.13 because much changed between R14 and 3.5.13. After R14 we
should be quite stable (ABI/API) and monthly bug patches should be easy to coordinate
among packagers.
Just ideas and thoughts.
Darrell
8 Jun
8 Jun
7:07 p.m.
New subject: [trinity-devel] Ideas and Thoughts
On 8 June 2012 13:38, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
We have a small team. Keeping Trinity moving forward
is a challenge. Yet I believe we have a committed and dedicated team, small or not, and
somehow we keep moving forward.
I don't expect people to give up their day jobs to support Trinity, but I found this
article interesting:
http://www.h-online.com/open/news/item/Independent-software-developers-go-f…
A lot of projects are going that way (monthly donations) for example
Ardour has a full time developer with a 54K goal per year (larger
project though). I wonder if we could setup a monthly pledge project.
I don't know what fund raising ideas we can use.
Selling shirts and coffee cups requires serious overhead and personnel. Yet sometimes I
wonder what we could do to keep Trinity moving at a nice speed.
There are websites that are already setup, that make it relatively
easy to sell stuff for you (like zazzle)
here is the Arch Linux zazzle page: www.zazzle.com/archlinux*
After we release R14.0.0, I'm wondering whether we
could do something similar. Every month or so we release a point release for Trinity that
includes bug fixes and possibly one enhancement request.
So for example, KDE and GNOME are frequently pushing out updates, but
all separately, if gnome-keyring gets an update, bump the version,
push the new package for just gnome-keyring.
Even if we push only two or three bug fixes, this
monthly release would show the project is alive and well. A monthly stablization release
also is great public relations because the various news people publish those press
releases.
A monthly release does not mean a complete overhaul of the mirrors, etc. We would need
only resync those packages that change. At three or four bug resolutions that likely would
mean only a package or two changes.
A monthly stablization release will be much easier to manage after R14 than trying to
backport patches for 3.5.13 because much changed between R14 and 3.5.13. After R14 we
should be quite stable (ABI/API) and monthly bug patches should be easy to coordinate
among packagers.
A monthly or bi-monthly would be good. But I think it should continue
to be based on work by the packagers, who cherry pick patches into a
stable branch from Git. What do you think about that? with a more
stable ABI it should be easier like you said.
Calvin
7:43 p.m.
New subject: [trinity-devel] Ideas and Thoughts
A lot of projects are going that way (monthly
donations) for
example Ardour has a full time developer with a 54K goal per year
(larger project though). I wonder if we could setup a monthly pledge
project.
Tim easily is the foremost developer for the project and unless there was a serious
commitment of pledges I'm guessing he would not surrender his day job. :-) Somebody
working a nominal job while attending school might be persuaded to drop the day job if the
equivalent income was the same or better.
One idea could be to create a reward system. Perhaps a pledge fund could be used to pay
developers to resolve bugs. I'm just guessing wildly, but perhaps $50 for Blocker, $40
for Critical, $30 for Major, $20 for Normal, $10 for Minor and $5 for Trivial. Build
Issues and Regressions are part of the normal ebb and flow and pay nothing. Possibly $25
per enhancement request. We would need a review committe to ensure bugs are provided a
correct status and we'd need some sort of criteria for establishing a bug report
status. Otherwise everybody would post bug as Blocker. :-) Indirectly, a reward system
might motivate a better response to resolving bugs within the developer's mail list.
I don't
know what fund raising ideas we can use.
Selling shirts and coffee cups requires
serious overhead and
personnel. Yet sometimes I wonder what we could do to keep
Trinity moving at a nice speed.
There are websites that are already setup, that make it
relatively easy to sell stuff for you (like zazzle)
here is the Arch Linux zazzle page:
www.zazzle.com/archlinux* After we
release R14.0.0, I'm wondering whether we
could do something similar. Every
month or so we release a
point release for Trinity that includes bug fixes and
possibly one enhancement request.
So for example, KDE and GNOME are frequently pushing out
updates, but all separately, if gnome-keyring gets an update, bump the
version, push the new package for just gnome-keyring. A monthly or bi-monthly would be good. But I think it
should
continue to be based on work by the packagers, who cherry pick
patches into a stable branch from Git. What do you think about that? with a
more stable ABI it should be easier like you said.
I use the phrase "monthly" loosely. If each period varied from one month to 6
weeks to 2 months, then we'd be fine. I think two months is the latest we prolong each
maintenance release. Conversely, we really should have several bug fixes in each
maintenance release. Otherwise we'll be accused of inflating version numbers only for
the public relations perception. Perhaps we set a minimal goal of, say, 6 bug patches
before we consider a maintenance release.
If no patch breaks ABI, then packagers would include all of the latest patches. Only the
ABI-breaking patches would have to sit in the development tree for the next incremental R
<ABI VERSION> release. I don't know enough about source tree management to know
how we handle the distinction for packagers to exclude such patches yet allow developers
to test the ABI-breaking patches too. That is, I would want to build each maintenance
release directly from GIT rather than start a collection of separate patches. Perhaps we
set up different branches of GIT.
Darrell
8:40 p.m.
New subject: [trinity-devel] Ideas and Thoughts
On Fri, 8 Jun 2012 12:43:16 -0700 (PDT)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Fascinating. How to handle the overhead of ordering supplies, maintaining inventory,
etc.? That requires people.
In Zazzle's case, they do it for you--essentially, they print on demand and
then drop-ship the item directly to the person who's ordered it. You-the-designer
set the price point, Zazzle takes a fixed cut in return for its services, and you
get whatever's left over. In other words, you effectively pay a bit more to get the
thing printed in return for them handling the supply, shipping, inventory etc.
hassles for you.
I don't know what fund raising ideas we can use.
Selling shirts and coffee cups requires serious overhead and
personnel. Yet sometimes I wonder what we could do to keep
Trinity moving at a nice speed.
There are websites that are already setup, that make it
relatively easy to sell stuff for you (like zazzle)
here is the Arch Linux zazzle page:
www.zazzle.com/archlinux*
11:26 p.m.
New subject: [trinity-devel] Ideas and Thoughts
Fascinating.
How to handle the overhead of ordering
supplies, maintaining inventory, etc.? That
requires
people.
In Zazzle's case, they do it for you--essentially, they
print on demand and then drop-ship the item directly to the person who's ordered
it. You-the-designer set the price point, Zazzle takes a fixed cut in return for
its services, and you get whatever's left over. In other words, you
effectively pay a bit more to get the thing printed in return for them handling the
supply,
shipping, inventory etc. hassles for you.
8:43 p.m.
New subject: [trinity-devel] Ideas and Thoughts
On 8 June 2012 15:43, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
I can't find the link - but a project did this with _AWESOME_ results
- of course I can't find it. I would put the cash at a lower price
though. 50 for blocker, 40 for critical, 20 for Major and Enhancement
Requests. 5 for trivial and 1 for every branding fix or something.
The project that did it had good results, with like $2000 dollars they
closed a serious amount of bugs, as well as got a lot of people
involved in the project who weren't previously.
That requires another funding campaign but I think it would be awesome
Fascinating. How to handle the overhead of ordering supplies, maintaining inventory,
etc.? That requires people.
They print stuff, they make the t-shirts, the handle the shipping and
billing and hand you a check afaik
From tdeversion.h:
R <ABI VERSION> . <BUGFIX REVISION> . <SECURITY PATCHLEVEL>
Security patchlevel is not present on initial release
It is added on the first security release, starting with ".a"
".a" would correspond to a TDE_VERSION_RELEASE of 1, ".b" would be
2, etc.
A new bugfix revision resets the security level
A new ABI version resets both the bugfix revision and the security level
So even if we push only two or three bug patches in a certain period, the first
stablization release after R14.0.0 would be R14.1.0. We could call each release a
"Maintenance and bug fix release." Nothing fancy.
A lot of
projects are going that way (monthly donations) for
example Ardour has a full time developer with a 54K goal per year
(larger project though). I wonder if we could setup a monthly pledge
project.
Tim easily is the foremost developer for the project and unless there was a serious
commitment of pledges I'm guessing he would not surrender his day job. :-) Somebody
working a nominal job while attending school might be persuaded to drop the day job if the
equivalent income was the same or better.
One idea could be to create a reward system. Perhaps a pledge fund could be used to pay
developers to resolve bugs. I'm just guessing wildly, but perhaps $50 for Blocker, $40
for Critical, $30 for Major, $20 for Normal, $10 for Minor and $5 for Trivial. Build
Issues and Regressions are part of the normal ebb and flow and pay nothing. Possibly $25
per enhancement request. We would need a review committe to ensure bugs are provided a
correct status and we'd need some sort of criteria for establishing a bug report
status. Otherwise everybody would post bug as Blocker. :-) Indirectly, a reward system
might motivate a better response to resolving bugs within the developer's mail list.
I don't know what fund raising ideas we can use..
Selling shirts and coffee cups requires serious overhead and
personnel. Yet sometimes I wonder what we could do to keep
Trinity moving at a nice speed.
There are websites that are already setup, that make it
relatively easy to sell stuff for you (like zazzle)
here is the Arch Linux zazzle page:
www.zazzle.com/archlinux* After we release R14.0.0, I'm wondering whether we
could do something similar. Every month or so we release a
point release for Trinity that includes bug fixes and
possibly one enhancement request.
So for example, KDE and GNOME are frequently pushing out
updates, but all separately, if gnome-keyring gets an update, bump the
version, push the new package for just gnome-keyring. A monthly or bi-monthly would be good. But I
think it should
continue to be based on work by the packagers, who cherry pick
patches into a stable branch from Git. What do you think about that? with a
more stable ABI it should be easier like you said.
I use the phrase "monthly" loosely. If each period varied from one month to 6
weeks to 2 months, then we'd be fine. I think two months is the latest we prolong each
maintenance release. Conversely, we really should have several bug fixes in each
maintenance release. Otherwise we'll be accused of inflating version numbers only for
the public relations perception. Perhaps we set a minimal goal of, say, 6 bug patches
before we consider a maintenance release.
If no patch breaks ABI, then packagers would include all of the latest patches. Only the
ABI-breaking patches would have to sit in the development tree for the next incremental R
<ABI VERSION> release. I don't know enough about source tree management to know
how we handle the distinction for packagers to exclude such patches yet allow developers
to test the ABI-breaking patches too. That is, I would want to build each maintenance
release directly from GIT rather than start a collection of separate patches. Perhaps we
set up different branches of GIT.
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
11:28 p.m.
New subject: [trinity-devel] Ideas and Thoughts
One idea could
be to create a reward system. Perhaps a
pledge fund could be used to pay developers
to resolve bugs.
I'm just guessing wildly, but perhaps $50 for Blocker, $40
for Critical, $30 for Major, $20 for Normal, $10 for Minor
and $5 for Trivial. Build Issues and Regressions are part of
the normal ebb and flow and pay nothing. Possibly $25 per
enhancement request. We would need a review committe to
ensure bugs are provided a correct status and we'd need some
sort of criteria for establishing a bug report status.
Otherwise everybody would post bug as Blocker. :-)
Indirectly, a reward system might motivate a better response
to resolving bugs within the developer's mail list.
I can't find the link - but a project did this with
_AWESOME_ results - of course I can't find it. I would put the cash at a lower
price though. 50 for blocker, 40 for critical, 20 for Major and
Enhancement Requests. 5 for trivial and 1 for every branding fix or
something.
The project that did it had good results, with like $2000
dollars they closed a serious amount of bugs, as well as got a lot of
people involved in the project who weren't previously.
That requires another funding campaign but I think it would
be awesome 
9 Jun
9 Jun
12:01 a.m.
New subject: [trinity-devel] Ideas and Thoughts
On 06/08/2012 12:38 PM, Darrell Anderson wrote:
A monthly release does not mean a complete overhaul of
the mirrors, etc. We would need only resync those packages that change. At three or four
bug resolutions that likely would mean only a package or two changes.
I'm all for showing the progress each month. The nice thing about git is that
for those building, a simple pull shows the progress. Since creating the
tarballs from the git tree is a simple script that takes about 3 minutes, there
is no reason not to provide the snapshots. I think that a monthly updates
summary of bugs fixed, milestones reached would serve the project well.
I can't emphasize enough how well Arch Linux does this directly from the git
repository they use. If you haven't done so, then check out the way Arch
integrates its git project into its main page to keep everyone up to date on
what has changed in the distribution. Just take this example:
http://www.archlinux.org
then in the upper right where the search box is for packages, just type in
'cups' or another package you are interested in. It jumps straight to the
package summary with links in the top right for source/changes, etc.. that links
directly to the git repo.
I'm not pushing Arch, but I am pushing how they have done their site, their
publication of updates, and their wiki -- it is the smartest setup I've seen and
I've looked at a lot....
A monthly stablization release will be much easier to
manage after R14 than trying to backport patches for 3.5.13 because much changed between
R14 and 3.5.13. After R14 we should be quite stable (ABI/API) and monthly bug patches
should be easy to coordinate among packagers.
The cleaner R14 is -- the easier to manage afterwards it will be. I think it is
on the right track and I think you have some good ideas.
Just ideas and thoughts.
Darrell
--
David C. Rankin, J.D.,P.E.
12:09 a.m.
New subject: [trinity-devel] Ideas and Thoughts
I can't emphasize enough how well Arch Linux does
this
directly from the git repository they use. If you haven't done so, then check out
the way Arch integrates its git project into its main page to keep
everyone up to date on what has changed in the distribution. Just take this
example:
http://www.archlinux.org
Would you or another Archer investigate how we can adapt some of those ideas?
The cleaner R14 is -- the easier to manage afterwards
it
will be. I think it is on the right track and I think you have some good ideas.
Yes, I think R14 will leave us in great shape. My vision for after R14 is we use our
computers instead of beating ourselves with bugs. :-) We're getting closer, for sure.
Darrell
12:21 a.m.
New subject: [trinity-devel] Ideas and Thoughts
On 06/08/2012 07:09 PM, Darrell Anderson wrote:
Would you or another Archer investigate how we can
adapt some of those ideas?
Yes,
I'll take a look. I've done it before, but I'll need to take a closer look
at
the packages web interface. Arch uses the 'kiss' philosophy so it is going to be
nothing but simple html, a pinch of js and mediawiki.
--
David C. Rankin, J.D.,P.E.
4580
days inactive
4581
days old
9 comments
4 participants
participants (4)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
E. Liddell