Tim is a great team leader and incredibly skilled with programming and seeing both the trees and forest.
But Tim is only one person.
There are many patches that have been submitted to the bugzilla. Those patches have yet to be merged.
Many of those patches directly affect building packages. Perhaps I'm out in left field, but seems to me that all build related bug reports should be resolved as fast as possible. Any such report with a patch should be merged within a day or two. Granted, often we bypass the bugzilla and resolve build related bugs directly in this list, but I'm addressing those that do get filed in the bugzilla.
Is Tim the only person qualified or allowed to merge patches? He has to sleep too and should not be the only person merging patches. Many of the patches are nominal or trivial. Others should be able merge those types of patches. If Tim is not the only person, is anybody who has GIT access interested in merging those patches?
If Tim is the only person then why don't we have alternates to share the load for when Tim is busy with other life requirements?
All of this leads into an important topic. Where do we stand when Tim has to devote time and energy to other life requirements? Do we have a Plan B to keep the project moving forward? Seems to me that whenever Tim is not merging patches the project grinds to a halt. That's a high compliment to Tim, but an uncomfortable reflection on the project. :(
Darrell
Tim is a great team leader and incredibly skilled with programming and seeing both the trees and forest.
But Tim is only one person.
There are many patches that have been submitted to the bugzilla. Those patches have yet to be merged.
Many of those patches directly affect building packages. Perhaps I'm out in left field, but seems to me that all build related bug reports should be resolved as fast as possible. Any such report with a patch should be merged within a day or two. Granted, often we bypass the bugzilla and resolve build related bugs directly in this list, but I'm addressing those that do get filed in the bugzilla.
Is Tim the only person qualified or allowed to merge patches? He has to sleep too and should not be the only person merging patches. Many of the patches are nominal or trivial. Others should be able merge those types of patches. If Tim is not the only person, is anybody who has GIT access interested in merging those patches?
If Tim is the only person then why don't we have alternates to share the load for when Tim is busy with other life requirements?
All of this leads into an important topic. Where do we stand when Tim has to devote time and energy to other life requirements? Do we have a Plan B to keep the project moving forward? Seems to me that whenever Tim is not merging patches the project grinds to a halt. That's a high compliment to Tim, but an uncomfortable reflection on the project. :(
Darrell
Serghei also has commit access. I have been waiting to merge patches until I can build test the packages, but with recent changes I am waiting on an archive rebuild for Ubuntu.
Tim
Serghei also has commit access. I have been waiting to merge patches until I can build test the packages, but with recent changes I am waiting on an archive rebuild for Ubuntu.
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
Serghei also has commit access. I have been waiting to merge patches until I can build test the packages, but with recent changes I am waiting on an archive rebuild for Ubuntu.
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
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 poeple to agree that they won't "go rogue" and just start pushing unreviewed patches. ;-)
Tim
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@pearsoncomputing.net> wrote:
Serghei also has commit access. I have been waiting to merge patches until I can build test the packages, but with recent changes I am waiting on an archive rebuild for Ubuntu.
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
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 poeple to agree that they won't "go rogue" and just start pushing unreviewed patches. ;-)
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
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 ;)
Having Slackware people involved in this project does ensure packages build correctly for just about all other distros too. Slackware is designed differently from the Debian and RPM based distros to regularly cause build issues. I have pushed poor Tim to the edges sometimes with my troubleshooting and bug reports. :)
Darrell
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
On 17 February 2012 00:59, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Serghei also has commit access. I have been waiting to merge patches until I can build test the packages, but with recent changes I am waiting on an archive rebuild for Ubuntu.
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
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 poeple to agree that they won't "go rogue" and just start pushing unreviewed patches. ;-)
Tim
I would love to review patches. for some time I have been wanting to set up a review board... but I am sure an etherpad could work just as well for now!
again here is where git's branching features come in really really handy. we could pull those changes into a testing branch and then merge them right back into the mainline when everything looks well.
Calvin
On 17 February 2012 00:59, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Serghei also has commit access. I have been waiting to merge patches until I can build test the packages, but with recent changes I am waiting on an archive rebuild for Ubuntu.
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
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 poeple to agree that they won't "go rogue" and just start pushing unreviewed patches. ;-)
Tim
I would love to review patches. for some time I have been wanting to set up a review board... but I am sure an etherpad could work just as well for now!
again here is where git's branching features come in really really handy. we could pull those changes into a testing branch and then merge them right back into the mainline when everything looks well.
Calvin
This still leaves someone having to pick over the patches when they are merged into mainline.
Tim
On 17 February 2012 21:12, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On 17 February 2012 00:59, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
Serghei also has commit access. I have been waiting to merge patches until I can build test the packages, but with recent changes I am waiting on an archive rebuild for Ubuntu.
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
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 poeple to agree that they won't "go rogue" and just start pushing unreviewed patches. ;-)
Tim
I would love to review patches. for some time I have been wanting to set up a review board... but I am sure an etherpad could work just as well for now!
again here is where git's branching features come in really really handy. we could pull those changes into a testing branch and then merge them right back into the mainline when everything looks well.
Calvin
This still leaves someone having to pick over the patches when they are merged into mainline.
Tim
Good point,
I could push sane non critical patches like CMake (which i am rather familiar with) and things regarding renaming, branding, or some other non-critical functions. At any point where I become confused as to the patch, I can just defer the changes to you
Calvin
I would love to review patches. for some time I have been wanting to set up a review board... but I am sure an etherpad could work just as well for now!
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 17 February 2012 22:00, Darrell Anderson humanreadable@yahoo.com wrote:
I would love to review patches. for some time I have been wanting to set up a review board... but I am sure an etherpad could work just as well for now!
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.
Right once marked Patchavail we can automatically assign the bug to reviewers. they can OK it and change the status to "needs merging" (still requires tim having a role) or can push it themselves (easier, but more likely for a bad commit)
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.
Yeah, I was thinking a trinity-bugzilla ML where bugzilla would mail out new bug reports. It's doable with bugzilla's tools. I try and look over new bugs, but getting an email would be good as well.
Calvin
On Thu, 16 Feb 2012 20:13:43 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
Tim is a great team leader and incredibly skilled with programming and seeing both the trees and forest.
But Tim is only one person.
There are many patches that have been submitted to the bugzilla. Those patches have yet to be merged.
Many of those patches directly affect building packages. Perhaps I'm out in left field, but seems to me that all build related bug reports should be resolved as fast as possible. Any such report with a patch should be merged within a day or two. Granted, often we bypass the bugzilla and resolve build related bugs directly in this list, but I'm addressing those that do get filed in the bugzilla.
Is Tim the only person qualified or allowed to merge patches? He has to sleep too and should not be the only person merging patches. Many of the patches are nominal or trivial. Others should be able merge those types of patches. If Tim is not the only person, is anybody who has GIT access interested in merging those patches?
If Tim is the only person then why don't we have alternates to share the load for when Tim is busy with other life requirements?
All of this leads into an important topic. Where do we stand when Tim has to devote time and energy to other life requirements? Do we have a Plan B to keep the project moving forward? Seems to me that whenever Tim is not merging patches the project grinds to a halt. That's a high compliment to Tim, but an uncomfortable reflection on the project. :(
It is an occasion of taking advantage of using git :) You can now clone the Trinity git repository in a public location (for example: gitorious, github, a server you have access on, etc.) and git won't discriminate your repo against Tim's one. So you can have your own git repo you update regularly from Tim's one, apply you own patches to it, and once the patches are applied, you can ask Tim to import your patches from your repo to his.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
It is an occasion of taking advantage of using git :) You can now clone the Trinity git repository in a public location (for example: gitorious, github, a server you have access on, etc.) and git won't discriminate your repo against Tim's one. So you can have your own git repo you update regularly from Tim's one, apply you own patches to it, and once the patches are applied, you can ask Tim to import your patches from your repo to his.
I don't know whether I did not explain myself well or whether your response is intended to be tongue-in-cheek. :)
I'm already patching from my own local GIT repository. I also have submitted many patches upstream. I could do so for a long time, but that does not do anything to the main project GIT repository because I do not have commit access.
Let me rephrase: if Tim became unavailable for a long period or forever, do we have a plan in place to continue the project or does Trinity fizzle away without Tim?
Darrell
On Thu, 16 Feb 2012 21:34:42 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
It is an occasion of taking advantage of using git :) You can now clone the Trinity git repository in a public location (for example: gitorious, github, a server you have access on, etc.) and git won't discriminate your repo against Tim's one. So you can have your own git repo you update regularly from Tim's one, apply you own patches to it, and once the patches are applied, you can ask Tim to import your patches from your repo to his.
I don't know whether I did not explain myself well or whether your response is intended to be tongue-in-cheek. :)
I'm already patching from my own local GIT repository. I also have submitted many patches upstream. I could do so for a long time, but that does not do anything to the main project GIT repository because I do not have commit access.
Let me rephrase: if Tim became unavailable for a long period or forever, do we have a plan in place to continue the project or does Trinity fizzle away without Tim?
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 :)
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
On Thu, 16 Feb 2012 21:34:42 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
Let me rephrase: if Tim became unavailable for a long period or forever, do we have a plan in place to continue the project or does Trinity fizzle away without Tim?
I just did a partial clone of Trinity repositories on my Gitorious account. As of now, the purpose of the repo is to concentrate Slackware-specific (or rather not-Debian-specific ?) development. I have uploaded tdebase and tdelibs, but I won't upload all the repositories because Gitorious' Terms of Service won't let there be more than 500 MB/mo of bandwith without impunity (although I'm not sure there has to be extensive bandwith beyond my initial uploads; perhaps the big downloads can all be made from trinitydesktop.org, but still pure Slackware users/packagers who want to use the repo will just "git clone" from gitorious). Are there other repositories where there are especially many Slackware patches ? Anyway as of now, I did neither attempt to build the repo on Slackware, nor put any patch on it, so it is useless. I just wanted to set up the foundations :) The URL of the repositories (grouped as a "project" in Gitorious terms) is https://www.gitorious.org/trinity-slackware . And I forgot the important part: since I am the admin of these repos I can grant you (or any other Slackware developer :)) commit rights, without wrecking havoc in Tim's official repos.
On 02/16/2012 10:13 PM, Darrell Anderson wrote:
Tim is a great team leader and incredibly skilled with programming and seeing both the trees and forest.
But Tim is only one person.
There are many patches that have been submitted to the bugzilla. Those patches have yet to be merged.
Many of those patches directly affect building packages. Perhaps I'm out in left field, but seems to me that all build related bug reports should be resolved as fast as possible. Any such report with a patch should be merged within a day or two. Granted, often we bypass the bugzilla and resolve build related bugs directly in this list, but I'm addressing those that do get filed in the bugzilla.
Is Tim the only person qualified or allowed to merge patches? He has to sleep too and should not be the only person merging patches.
He is given time allotted to shower on Sunday and Thursday... That should be more than adequate. If we need to crank things up a level, then maybe we could take a vote and cut that back to just 1 on Sunday (He has to look nice for church :)
What else could he possibly want? He is living the dream with his project hitting on all 8 cylinders, what more could he want?
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Jay -
Timothy Pearson