news <news@sea.gmane.org> wrote on 03/05/2006 12:29:51 PM:
> > As they are, for the most part, volunteers I think they pay attention
to
> > the things they find interesting.
>
> So basically you're saying the developers don't find making their
> software usable interesting? That is interesting in of itself.
The Subversion developers do not rely on the votes just because they do
not think the feature really means anything. The Subversion community is
wide and only a small fraction know about the issue tracker. The vote
counts just are not significant in and of themselves. That does not mean
that any given developer might not take a look at the votes to get a sense
as to what people are concerned with. It just means that no one is
willing to make any guarantees that having a high vote count is going to
equal implementation.
I doubt that you would find a single Subversion developer that is against
the basic idea of this feature. The issues are that an acceptable design
for the feature has not surfaced, and developer time is scarce. In the
past there have been issues like locking that seemed more pressing, and
currently the time is being spent on features like merge tracking. That
being said, anyone can be a Subversion developer by simply being motivated
to work on a design for the feature.
> >> Would they even accept a patch if someone went off and implemented
this?
> >
> > Provided it meets the subversion quality standards.
> > Read the HACKING file in the source distribution.
>
>
> Clearly you haven't looked at this in a while, because it says to
look
> at http://subversion.tigris.org/hacking.html. This document is very
> vague as to the process by which a patch is actually accepted. As far
> as it describes, submitting a patch is no more likely to make the
> developers accept it than voting will make them pay attention to an
> outstanding issue.
The HACKING file is about the code standards. You are right, that is only
a small part of what it takes to get a patch committed. The main thing is
that an acceptable design is needed. With a good design that is generally
agreed upon, one of the existing developers might even take up the job of
coding it. What will almost never be accepted is a patch that is dropped
in out of the blue with no written design to validate it against, and no
discussion of the design.
In short, what it comes down to, is that this feature is fairly difficult
to implement within the boundaries of the current working copy design. In
order for it to get implemented, a well thought out design on how to
implement it is going to be needed. The good news is that in the last
couple of releases developers have been optimizing the working copy design
and code, which means there are more developers who have been working in
that area of the code and are feeling more comfortable with it. So if a
design were to emerge, there are developers that should be able to comment
on the proposal and help refine it.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Sun Mar 5 20:00:23 2006