Ok, so you are waiting to start that big wooshing sound. Fair enough. :) But that does not address the core concern: what happens to Trinity should you become unavailable for a long period or forever? Additionally, Serghei is another sharp person but is fairly busy too. His commit access does not change the picture of either of you being too busy to keep patches merging, especially build related patches. Of the non build related patches, many are small and don't need a rocket scientist to decide that merging probably is safe. Should there be others with commit access? Darrell

Aaah ... I think i get it. Tim isn't some kind of advanced bot/cyborg technology, and he has a life! I think it is good on one hand that Trinity has '*the right person*' controlling the patches. This ensures a type of quality control. On the other hand, i have seen many one man shows come to a sudden halt. If Tim were to face plant into his keyboard we would become one such project. I agree a couple more people (read: not ronin) are needed to push patches and this should be done on a majority vote (more than one in this case). *which could has a purpose such as having a repo that always builds on Slackware ;)* I like this guy/gal !! Jay On Fri, Feb 17, 2012 at 5:59 AM, Timothy Pearson < kb9vqf(a)pearsoncomputing.net&gt; wrote:

Thanks for the vote of confidence. My C++ skills are very much noobie level, but if asked to review patches I would help. Although I am learning C++, I would pass and not review any patch I thought was over my head because of coding complexity. My focus for this discussion is one of stewardship. I don't want to understate your contributions and leadership to this project, but without a plan for your absence I fear the project would wither away. Recently you asked us what desktop we would choose if Trinity disappeared. The simple answer is most of us don't want to consider that day, at least not for several years. On a personal basis I could keep patching to a small degree and keep myself going, but eventually I'd reach a point of no hope. Long term I'm sure many of us here would try to keep things going in your absence. Yet without some increased involvement now by others to learn some of the ropes, most of us would be swimming upstream. Getting people involved now at a nominal level helps everybody keep the project going. Getting others involved now helps lift some of the burden from you too. Even if for now you want to control the actual committing process, having others help with reviewing bug reports and patches will keep things moving. When bug reports are filed there should be one or two people who respond within 24 hours to ensure the report is tagged at the appropriate level. For example, a while ago we discussed that all build related bugs should be tagged as Blocker. We should write some kind of simple criteria for rating bug reports. When a bug report is accompanied with patches, and those patches are minor or trivial, then approve them and have them committed immediately. Reviewers need not have commit access. Rather than using etherpad, perhaps we add an approval option in the bugzilla. That option triggers the attention of those who have commit access. Or, reviewers use the comments section and write "Patch Approved." Those who are provided commit access are also on the distribution mailing list and will see the approval comment or option trigger. When a patch is approved anybody with commit access performs a cursory review and with no disagreement, pushes the patch. I see patches continue to backlog in a holding pattern, waiting for you. That is not fair to you or Trinity users. I have been around technical and engineering projects most of my adult life. I know from experience that backlogs wear people thin. If most of these patches were committed quickly, that would leave more time for you and other C++ experts to focus on bug reports that have no patches --- and there are many of those bugs needing attention before R14. Other than you I don't know whether anybody involved here has the skills to see the trees and forest with respect to the complexity and relationships of the code base. Getting others involved now helps improve those skills. As a technical writer I am only familiar with software control at the fringes. I'm learning a lot by being involved in this project, but I'm not trying to dictate how anything is done. I'm only trying to encourage ideas. I'm looking at the project from a wide perspective. Trinity is important to me and important to everybody who choose Trinity as their desktop environment. To one degree or another we all have a stake in the future of this project. I'm not demanding anything today or tomorrow, but a plan for general work flow and emergencies is good stewardship. I'm not asking you to decide anything right now, but the sooner we develop a plan to keep things moving in a regular fashion the better we will be prepared for emergencies too. Darrell

This still leaves someone having to pick over the patches when they are merged into mainline. Tim

Do we need etherpad? How about 3 to 4 people on a review committee. Each reviewer receives all emails from bugzilla. Two reviewers are needed to approve a patch. All that is needed is for a reviewer to add a comment "Patch Approved." Tim will see those comments through the bugzilla emails and then can push the patch. Similarly for bug reports with no patches. Any reviewer who receives an email for a new bug report and notices the report is build related but not tagged Blocker, can quickly update the bug report. Any of us can now do that but looks much better when a reviewer bumps the report within an hour or two. Just thinking out loud.... Darrell

On Thu, 16 Feb 2012 21:34:42 -0800 (PST) Darrell Anderson &lt;humanreadable(a)yahoo.com&gt; wrote: When you clone a SVN repo, you have a local copy that is subordinated to the remote master. But when you clone a git repo, your clone is technically the same as a git repo, and you can host a public clone of the repo, which could has a purpose such as having a repo that always builds on Slackware ;) (for example https://github.com/torvalds/linux is a public clone of the kernel.org git repository, managed by Linus Torvalds himself) And if the Slackware-related repository is the only active one, it will be the new up-to-date Trinity repository :)