Abdelrazak Younes wrote:
Pavel Sanda wrote:
that will be my last commit.
that is the best solution if you cannot live with compromise.
i guess he could live if people start to flame embedding philosophy
when he
asked in start of implementing. i fully understand the frustration of
reverting
it back after months of development when nobody raised a single
voice. so its
not only Bo's strong opinion but inattention of the rest of us in the
beginning.
Very true.
interesting question is if we can minimize or prevent such troubles
in the
future, because its pity to lose devs in this way. one idea coming to
my mind
is to change the way how main features are proposed or planned in the
beginning
of the release cycle. maybe to get one oponent or revision of general
construction (details can be flamed always, but not the general
things.) thats
just idea, maybe its just too much burden, don't know.
Actually, I remember some discussion before and during the
implementation (at least with Jose IIRC). So the procedure was OK in
this case. It is just that this feature is particularly difficult to
grasp.
Let me second all of this. Pavel is right that "major features" should
be discussed openly and not committed until we have some kind of
agreement. And sometimes that works. But it's also true, as many of us,
I think, have experienced, that it isn't always easy to get feedback.
For example, Andre recently criticized some of the changes I made to
InsetCommandParams. In fact, I think he was right to do so and that
there is a better way, but: (a) The ideas I implemented were ones that
had originally been suggested to me on the list and discussed openly;
(b) before proceeding, I posted several messages concerning general
design questions and got almost no response (silence is assent); and (c)
I posted at least many of the patches on the list before committing
them. Now, to be sure, we can't all read everything, but it is
frustrating to try to get feedback, not get it, and then later be
criticized.
I'd have to go back and look at the emails, but I also remember that
there was some discussion of how this should be implemented. I think
that Jose raised objections way back then that were not very different
form the ones he raised just recently, and I don't think there really
was a resolution, but I guess Bo felt he could proceed, and did. But
then just a month or so ago, he completely changed the implementation,
in ways that intruded significantly on the inset code, and there was NO
discussion of that. And I was just too busy then to be paying much
attention to the cvs logs that were going by, as I guess were lots of
other people. That should have been discussed.
In any event, the "nail in the coffin" for Bo's approach ended up being
security issues that were first raised by Andre. These can be hard to
foresee. It wasn't that these issues couldn't be addressed within Bo's
approach. It was, rather, that once you'd addressed them, you couldn't
have true "reversibility" any longer, and then the motivation for his
approach kind of evaporated, because that was the guiding idea.
Richard
