On Tue, Jan 03, 2012 at 12:53:39PM -0500, Mark Mielke wrote:
> 1) Require a means to reliably determine the AUTHOR of a changeset.
> Reliable here means machine consumable in a standard format which
> all tools are aware of because the standard is documented.
>
> 2) Require all native output from the tool (such as "svn log")
> designed to be read by humans to include a convenient and easily
> readable format.
>
> 3) Provide a standard convention or protocol for 3rd party tools to
> reliably determine either the unique identifier or the humanly
> readable expansion from Subversion. Either provide additional
> information in the commit itself, or provide a mechanism to either
> lookup the information, or a mechanism to lookup how to get the
> information.
That's a good summary of your requirements. It sums up what you've
been explaining so far.
> >You can keep criticising us all you want, it won't change a thing
> >if you don't also explain in detail what needs to be changed.
> >We cannot read your mind to obtain a functional specification.
>
> I know. That's why I wanted to go away and think before coming back.
Then do that. Nobody's stopping you.
I think this is exactly what you'd need to do next.
> I'm probably wrong for being frustrated, and I'm probably wrong for
> how am I approaching this. I should probably just sit back and watch
> again for a while. I'm sure you haven't appreciated my criticism,
I suspect the process seems hard to you because this community works
as a meritocracy and you aren't use to working in this way.
Maybe I'm wrong and you already understand most of what I'm about to
say but I'll write it down anyway in case it helps.
Other projects work differently. It might seem easier for things
to happen quickly and arguments to be decided when there's one benevolent
dictator sitting on top making all the tough decisions, like in the git
project, or with a company where upper management is responsible for
enforcing the direction the project is going (clearcase, perforce).
The Subversion project doesn't use either of these approaches.
I suspect that you're frustrated with the style of development that
happens in a community driven by consensus, because you want to see
stuff get done fast, and are afraid of investing time and effort which
might turn out to be in vain in case the community as a whole doesn't
accept the results of your work.
On top of that, judging reactions from a group of people you've never
physically met and trying to gauge the general opinion that's forming
during discussion within such a group is very hard. It requires a bit
of luck as well as confidence and communication skills.
But remember that just because somebody is objecting to aspects of your
ideas doesn't mean that your ideas won't eventually be accepted.
The purpose of the process is to filter out the good ideas from the bad
ones, and transform good ideas into great ones. That requires time, a thick
skin, and the ability to seriously question ones own motives and ideas
for the merit they will bring to the entire community comprised of users
and developers.
Stuff gets done when one or more people who want to drive change sit
down and do the work. When they get stuck at any point in the development
process (design, implementation, testing...) they consult this list for help.
This also allows them to keep an eye on the community's reaction to
their work. There is no requirement for drivers of change to already be
known members of the development community -- the community simply grows
when this happens. The only requirement is that, eventually, everyone is
happy with the changes being made. In extreme cases, there may be voting.
But in this project voting only happened twice within more than 10 years,
and one of those instances was about whitespace formatting in the code so,
yes, we tend to have long-winded discussions :)
Whenever I make non-trivial changes to Subversion I make two assumptions
that you don't seem to be happy to make. I assume that it will take me
forever to get it done, and I assume my ideas and my code are initially
mostly wrong. I don't start out assuming I know what's right.
I assume I'm wrong, and then slowly try to work towards being less wrong.
I rely on the community to help me be less wrong and move towards being
right. That's one way of eventually getting things done in a meritocracy.
This approach prevents frustration about anyone but myself. If I fail,
I failed because of my own fault, so I need to improve and try again.
I don't fail because I was right and everyone else didn't agree with me.
Received on 2012-01-03 20:19:47 CET