Re: [Libxmlplusplus-general] resume of one day's work
- From: Stefan Seefeld <seefeld sympatico ca>
- To: libxmlplusplus-general lists sourceforge net
- Subject: Re: [Libxmlplusplus-general] resume of one day's work
- Date: Tue, 04 Feb 2003 09:49:05 -0500
Murray Cumming wrote:
On Tue, 2003-02-04 at 08:21, Stefan Seefeld wrote:
hi there,
I'v just checked in the latest bits and pieces of today's round
of enhancements. Here is a list:
I haven't looked at this yet, but didn't I say that you shouldn't take
cvs access as permission to just check in whatever you like? The need to
revise your patch 6 times should have shown you that you probably need
to go a bit slower. Your arrogance is beginning to astound me.
my WHAT ? Now you calm down a bit, will you ?
I'v sent various mails to the list discussing my different proposed
additions, and got some positive feedback. Are you able to browse the
archives ?
I didn't do *any* backward incompatible changes, beside redefining
the AttributeMap used by the SaxParser.
Further, I fixed quite a number of issues with the old API, and
quite massively enhanced its capabilities (simply by allowing more
calls to be directly mapped to libxml2).
So, in the light of all this, who are you that you call me arrogant ?
* create a 'Document' type
* make 'Attribute' a subclass of 'Node'
* enhance the tree manipulation API, adding a Node::child_iterator
type, as well as new 'insert_child', and 'append_child' methods
(in accordance with the usual STL nomenclature)
* remove more memory leaks (SaxParser now has its own 'AttributeMap',
independent from Node types
* new 'Node::find' and 'Node::get_path' methods for use with xpath lookup
Who gave you permission to make these major API changes? As far as I
know we have not branched yet. Now we will have to do a lot of work to
branch and revert these changes in the 1.0 branch.
What's wrong with these changes going into 1.0 ? What issues do they
generate ? There isn't anything (not in cvs, nor in the mailing list)
hinting at what kind of changes are acceptable before a branch and what
not. My interpretation of the recent discussions here on the list were
that the enhancements / clarifications in the API are well worth to go
into 1.0. And really, what I did yesterday is just a continuation
/wrap-up of the patch that youself checked in.
Again, I agree that developers working on a common project ought to
stick to a common vision. I think I did my best to do that, and I'd like
to continue to do that and contribute to enhance libxml++.
It's *your* attitude that I find quite a bit upsetting. It's your
commanding tone that's turning me off quite a lot. Who are you that you
give me permission or not to do things ?
It's not as if I want to subvert the project. Again, if there were any
clear guidelines telling me that libxml++ is currently in a feature
freeze or something, I obviously would have been more careful.
Could you please at least have a look at the changes before calling
me words ? Did you actually look at the new demo ?
What is the reason for the libxml++ code to be split over a set of subdirs ?
Is that really necessary ?
Yes. It's organisation.
Can you elaborate a bit ?
Now that 'Attribute' is a node, it is also inconsistent.
I would suggest to put all libxml++/nodes/ source files into a single place with the
rest.
Oh, and can we take out the call to './configure' from the autogen.sh script ?
No, I'd rather that we didn't.
*That* is what I call arrogant. I'm trying to enhance libxml++, and you
don't even take the time explaining why you think the current situation
is better than my proposed changes.
You do everything to drive away contributors, at least me. I'm seriously
considering to just roll my own. It isn't that hard, I just hoped we
could reduce the redundancy and work together instead. Your immature
attitude makes that very hard.
What have the others here on the list to say on these issues ?
Does anybody else worry about the project's stability due to my checkins ?
Stefan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]