On 8 June 2012 15:43, Darrell Anderson <humanreadable@...> wrote: >> 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 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 >> > 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* > > 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 >> > 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. > > 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 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@... > For additional commands, e-mail: trinity-devel-help@... > 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 >