Offering to maintain Conduit

It makes sense to keep a separate repository for development, but I'd like to have only one 'official' project; with a single issue queue for tracking development conversations and other discussions. The intent would be to not commit anything without consensus ... but at the same time, not introduce a bottleneck where we've got only one person who can commit changes to the project. Pull requests do represent a clean workflow, but we should be able to survive on issue queues and patches, just like any any other project on d.o.

The testing architecture has always suffered from 'single point of failure' syndrome ... let's not start the next generation code off on the same foot.

The discussion referred to in #1 stated that we would maintain individual feature branches, and merge in changes as they were completed/agreed upon. This, too, represents a clean workflow.

What does NOT make sense is to maintain two seperate repositories ... we only have one (shared!) conduit staging server, and two (shared!) workers. I did not go through the significant effort of creating these with the intention of handing them over to someone else, and not being able to leverage them in testing my own code. It also doesn't make sense for us to go through the effort of pointing them at two different repositories, making it much more complicated to switch back and forth between our own developmental code during testing ... compared to a simple "git checkout maintainer_a/maintainer_b".

You stated today that "the commit stuff to me was one my conditions when giving away my code...but perhaps that was not clear to all". I do not remember you ever stating this condition, and nor would I have promoted your project as the proposed evolution of the architecture under such a limitation. My understanding was that you wanted commit access and full co-maintainership (both of which were no-brainers from my perspective) ... but not exclusivity.

You then quoted all sorts of history on pifr and project_dependency over changes which went into those projects without your agreement or approval. Strangely, my impression is that those changes went in without your 'participation' ... as you withdrew from the community, others stepped in to keep the lights on in your absence. I recognize, of course, that you have a different perspective on this - but please, let's try and focus on how to move forward on THIS project, not speculate on ways that it could potentially go wrong.

It's obvious that you have some lingering resentment over what has happened with your projects in the past. You made a comment about 'watching your project being taken over again' ... Please recognize that the world is NOT out to get you. If it was my intent to simply grab your code and run with it, I would have published my own sandboxes instead of pushing you to create the 'official' project entries and then migrating my existing issue list. I did this as a show of good faith, and respect for all of the work that you put into writing the code ... I've also agreed to work only in feature branches, and not commit anything outside those branches without first getting your blessing. What more do I have to do to convince you that I'm not some rogue cowboy who's trying to pull a fast one on you?

I've evangelized your project to anyone who would listen ... and still, my patches sit un-reviewed and uncommitted, all because you won't let go of a disagreement months ago over the value of job chaining (and won't consider any patch that looks even remotely like it might ever support it).

I didn't throw out the 'fork' word today in order to threaten you ... I only mention it to try and convince you that if you continue to lock down and insist on inserting yourself as a gate in front of every nitpicky little patch that goes into the code, then you're driving me to a postion where I will have no other choice. Conduit has not had a single commit made to the project in nearly three months. For worker, nothing since April. The current implementation is completely broken on anything other than Suse, due to the ssh build-step parameter trying to write to the webserver home directory (i.e. /var/www on Debian/Ubuntu). I've opened issues and solicited your opinion on every change I attempt to make. Generally, I get the months-old 'job chaining' thrown back in my face ... or at best, "Yeah, that'd be nice ... but not now". Frankly, The status quo is not working ... this is nowhere near a 'clean workflow'.

There are two well-known quotes which I believe nicely sum up the current situation:

1. People try to control things based on what they think will happen if we don’t ... control is rooted in fear.
2. It's a result of being attached to a specific outcome ... one that an individual is sure is best, as if that individual always knows what is best.

These two quotes are usually accompanied by a third ... I encourage you to take it to heart ...

3. The energy of surrender accomplishes much more than the energy of control.