trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2012

Re: [trinity-devel] Plan B

From: Darrell Anderson <humanreadable@...>
Date: Fri, 17 Feb 2012 11:00:50 -0800 (PST)
> Probably.  I can't enforce it with technical means, but
> I suppose we could
> use the Etherpad to review patches and if two or more
> non-core devs agree
> that the patch looks sane (and doesn't remove functionality,
> etc.) the
> patch could be pushed.
> 
> That leaves the question of who to grant access to.
> You and Calvin are
> two that come to mind, but I would need people to agree that
> they won't
> "go rogue" and just start pushing unreviewed patches. ;-)

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