Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Cantor, Scott
On 2/17/15, 3:01 PM, Boris Kolpackov bo...@codesynthesis.com wrote:

See it from my POV: I have a ton of users that are pretty happy with
3.1.1. Now comes Scott and wants to cut a half-tested release just
to satisfy his immediate needs. Once you do this I will start getting
emails from my users saying why doesn't my stuff (which depends on
Xerces-C++) works in this or that situation. I don't want that.

I don't either, but to be blunt, the branch shouldn't be in the state it's 
in if you think it needs that much testing, because if a security issue 
pops up, you don't have the luxury of taking a lot of time.

I completely understand your point about using the trunk, and I agree with 
it. It's not worth the risk. But any fixes to the branch should be very 
carefully looked at, in which case testing can be fairly pro-forma.

I did review some of, but not all, the branch changes

Nobody is talking about months. Here is what I suggest you do:

1. Prepare the release (with all the updates to docs, new projects,
   etc).

I am not going to add in project files for a compiler I can't test. That 
flies in the face of the exact point you made above. If you think the 
files on trunk work, we can add them. As far as docs go, I obviously need 
specifics.

3. I will test it to the best of my abilities (even though I have
   absolutely zero time for it right now) and report any problems
   (I will also review the changes for any ABI breakage).

Do you think I do have time?

BTW, I am surprised you had to back-port so many bug fixes to the
3.1 branch. Normally anything that is backwards-compatible gets
committed to both head and 3.1. Are you sure you are using 3.1
and not, say, 3.1.1?

After about 2011-2012 or so, the branch simply died. Every fix was applied 
to trunk only, even when it was minor.

The most risky changes are to the transcoder code which saw a large set of 
fixes, mostly not ABI-impacting, that only hit trunk.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I don't either, but to be blunt, the branch shouldn't be in the state it's 
 in if you think it needs that much testing, because if a security issue 
 pops up, you don't have the luxury of taking a lot of time.
 
 I completely understand your point about using the trunk, and I agree with 
 it. It's not worth the risk. But any fixes to the branch should be very 
 carefully looked at, in which case testing can be fairly pro-forma.

It is no so much the changes that I am worried about. It is the fact
that a lot of outside things (platforms, compilers, libraries, etc)
that Xerces-C++ depends on have changed a lot.

But, also, knowing what kind of a rotten mess Xerces-C++ code base
is, it is hard to know what even a trivial change will trip up.


 I am not going to add in project files for a compiler I can't test. That 
 flies in the face of the exact point you made above. If you think the 
 files on trunk work, we can add them.

Add them and I will test.


 As far as docs go, I obviously need specifics.

You will have to go through the website docs and figure what needs
updating. If something specific is unclear, ask and I will try to
help. But don't expect me to provide a step-by-step guide for you.
I unfortunately really don't have the time for that right now.


 Do you think I do have time?

I am not asking you to do anything.


 After about 2011-2012 or so, the branch simply died. Every fix was applied 
 to trunk only, even when it was minor.

Ok, I guess I missed that.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Cantor, Scott
On 2/17/15, 4:00 PM, Boris Kolpackov bo...@codesynthesis.com wrote:

 As far as docs go, I obviously need specifics.

You will have to go through the website docs and figure what needs
updating. If something specific is unclear, ask and I will try to
help. But don't expect me to provide a step-by-step guide for you.
I unfortunately really don't have the time for that right now.

Is this the document mentioned earlier?

http://svn.apache.org/viewvc/xerces/c/admin/release-procedure.txt

If you could at least skim it for any errors, that would be a big help.

-- Scott



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Cantor, Scott
On 2/17/15, 4:41 PM, Cantor, Scott canto...@osu.edu wrote:

Is this the document mentioned earlier?

http://svn.apache.org/viewvc/xerces/c/admin/release-procedure.txt

If you could at least skim it for any errors, that would be a big help.

Never mind, I missed the note at the top, from you in fact.

-- Scott



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Cantor, Scott
On 2/17/15, 9:01 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

What about other platforms?! If this class is defined in a public header
(i.e., a header that is installed) and the function is virtual, then this
is an ABI change.

It's a struct, in an impl/ header marked as do not use, and the struct 
itself isn't embedded in any classes, only pointed to.

It's borderline, I suppose. If the impl/ header wasn't installed, it 
wouldn't even come up.

I can probably do the less efficient patch, but given the other notes on 
this thread, I don't know that it matters much.

-- Scott



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Cantor, Scott
On 2/17/15, 9:10 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

 I've reviewed all the resolved issues against the trunk, and backported 
 15-20 or so to the branch.
 
 Once I have access I'll commit.

Before you do this have someone review your back-ports to double
check there are no ABI breakages.

If somebody is here to do the commits, then I don't have to do them, I'm 
happy to supply a patch with the Jira numbers.

The only change with even a hint of ABI impact is the string pool thing, 
which is a borderline case, and I can change it if need be. Nothing else I 
reviewed is close.

The only reason I assumed the pool change was acceptable is that the impl/ 
headers are marked do not use externally very prominently, and I assumed 
that was to warn people off so that they could change without altering the 
formal ABI in a shared library if they changed in a forward-compatible way.

-- Scott



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Cantor, Scott
On 2/17/15, 9:07 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

 I definitely don't have the cycles for a beta and it wouldn't fit my 
 timeline anway.

Then you shouldn't be making the release.

No, I shouldn't, but I didn't see any real alternative either. If somebody 
else is going to, I can easily step back.

I'm on VC10 for my builds, and I believe those are already there.

What about other users of Xerces-C++? When we publish a new release,
it is presumed that it will work on all commonly-used platforms and
compilers, not only what Scott Cantor needs.

It's been years, Boris. I think you're being very aggressive here with 
somebody trying to help and able to do so only within the limits of his 
own funding and project needs. That's how this stuff works. If you're 
going to set requirements that I can't meet, then there's not much I can 
say.

Bare minimum is to make sure 3.1.2 is as good quality as 3.1.1.

I can't go back and review every commit you all have made. I can be very 
careful with any commits *I* make, and I can test my use cases and allow a 
bit of time beyond that. If you're asking me to wait months, no, I can't 
do that. I have constraints too.

 I don't think you are approaching it with the right attitude. If all
you need is a bug-fix that only has to work for your specific case,
then just provide a patch (or a patched version of Xerces-C++) to
your users.

I probably would consider that, if it weren't for the fact that Red Hat 
and other distros have shipped your code.

And I'm not the only one who needs fixes. A simple review of Jira 
demonstrates that very easily.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 It's been years, Boris. I think you're being very aggressive here with 
 somebody trying to help and able to do so only within the limits of his 
 own funding and project needs. That's how this stuff works. If you're 
 going to set requirements that I can't meet, then there's not much I can 
 say.

See it from my POV: I have a ton of users that are pretty happy with
3.1.1. Now comes Scott and wants to cut a half-tested release just
to satisfy his immediate needs. Once you do this I will start getting
emails from my users saying why doesn't my stuff (which depends on
Xerces-C++) works in this or that situation. I don't want that.



 I can't go back and review every commit you all have made. I can be very 
 careful with any commits *I* make, and I can test my use cases and allow a 
 bit of time beyond that. If you're asking me to wait months, no, I can't 
 do that. I have constraints too.

Nobody is talking about months. Here is what I suggest you do:

1. Prepare the release (with all the updates to docs, new projects,
   etc).
   
2. Publish it as a pre-release for, say, a week (i.e., announce on
   the lists).
   
3. I will test it to the best of my abilities (even though I have
   absolutely zero time for it right now) and report any problems
   (I will also review the changes for any ABI breakage).
   
4. If all looks good, you publish the release.

BTW, I am surprised you had to back-port so many bug fixes to the
3.1 branch. Normally anything that is backwards-compatible gets
committed to both head and 3.1. Are you sure you are using 3.1
and not, say, 3.1.1?

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 Correction, it's not an ABI change, the pool entry class isn't exported on 
 Windows...

What about other platforms?! If this class is defined in a public header
(i.e., a header that is installed) and the function is virtual, then this
is an ABI change.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I definitely don't have the cycles for a beta and it wouldn't fit my 
 timeline anway.

Then you shouldn't be making the release.


 I'm on VC10 for my builds, and I believe those are already there.

What about other users of Xerces-C++? When we publish a new release,
it is presumed that it will work on all commonly-used platforms and
compilers, not only what Scott Cantor needs.


 What's the bare minimum we can do once I have a tarball tested?

Bare minimum is to make sure 3.1.2 is as good quality as 3.1.1. I
don't think you are approaching it with the right attitude. If all
you need is a bug-fix that only has to work for your specific case,
then just provide a patch (or a patched version of Xerces-C++) to
your users.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-17 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 I've reviewed all the resolved issues against the trunk, and backported 
 15-20 or so to the branch.
 
 Once I have access I'll commit.

Before you do this have someone review your back-ports to double
check there are no ABI breakages.

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-16 Thread Cantor, Scott
On 2/16/15, 2:51 PM, Cantor, Scott canto...@osu.edu wrote:



The fix on trunk changes the ABI by adding a length field to the string 
pool entries. I probably can come up with one that doesn't by just doing 
the length checking, at the cost of some efficiency.

Correction, it's not an ABI change, the pool entry class isn't exported on 
Windows, my mistake. So I'll just backport that directly.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-16 Thread Cantor, Scott
I've reviewed all the resolved issues against the trunk, and backported 
15-20 or so to the branch.

Once I have access I'll commit.

I don't have access to Jira either of course. I watched everything I 
backported for now, I can at least note it in a comment, but I can't alter 
the fix versions at the moment.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-16 Thread Cantor, Scott
On 2/16/15, 11:52 AM, Boris Kolpackov bo...@codesynthesis.com wrote:

Unless you are prepared to do a good amount of testing (I can help
somewhat but you will have to take the lead, e.g., package a beta,
announce it, etc, etc), I would strongly suggest that you do the
bug-fix release (i.e., 3.1.2). Simply back-port the fix that is
only on trunk (and maybe check if there are more fixes that haven't
been applied to the 3.1).

The fix on trunk changes the ABI by adding a length field to the string 
pool entries. I probably can come up with one that doesn't by just doing 
the length checking, at the cost of some efficiency.

I definitely don't have the cycles for a beta and it wouldn't fit my 
timeline anway.

 Stillm packaging a beta is probably a
good idea. As is adding new VC++ project/solution files (i have
them in XSD but they use different DLL naming).

I'm on VC10 for my builds, and I believe those are already there.

Also, I must warn you, Xerces-C++ release process is probably
the most brain-dead thing you will ever experience. There is
the admin/ repository with some outdated release information.
I will also try to answer questions if you have any (I've done
the last couple of releases).

You'd have to give me some direction on this. With Santuario, it's a very 
limited process because projects with essentially no resources don't get 
big, elaborate processes in my world.

What's the bare minimum we can do once I have a tarball tested?

-- Scott



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-16 Thread Boris Kolpackov
Hi Scott,

Cantor, Scott canto...@osu.edu writes:

 FWIW, I've done very little testing of trunk other than building it,
 so I don't have a sense of how good a shape it's in or how much has
 changed.

Unless you are prepared to do a good amount of testing (I can help
somewhat but you will have to take the lead, e.g., package a beta,
announce it, etc, etc), I would strongly suggest that you do the
bug-fix release (i.e., 3.1.2). Simply back-port the fix that is
only on trunk (and maybe check if there are more fixes that haven't
been applied to the 3.1). Stillm packaging a beta is probably a
good idea. As is adding new VC++ project/solution files (i have
them in XSD but they use different DLL naming).

Also, I must warn you, Xerces-C++ release process is probably
the most brain-dead thing you will ever experience. There is
the admin/ repository with some outdated release information.
I will also try to answer questions if you have any (I've done
the last couple of releases).

Boris

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



RE: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-15 Thread Cantor, Scott
 Its not very active these days. I don't think we have an official policy on
 Committers from other areas having access. I think it would be great so will
 grant you access if no one objects over the weekend.

I'll stand by. FWIW, I've done very little testing of trunk other than building 
it, so I don't have a sense of how good a shape it's in or how much has 
changed. The autoconf files haven't been updated (they're actually older 
version-wise than the 3.1.x branch).

Based on past practice, it would seem that a 3.2 release will embed a 32 in 
the library name and basically represent a breaking change to the ABI.

-- Scott


-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org



Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))

2015-02-14 Thread Gareth Reakes
Hey Scott,

Its not very active these days. I don't think we have an official policy on 
Committers from other areas having access. I think it would be great so will 
grant you access if no one objects over the weekend.

There is also a security patch we need to sea with (will mail you privately 
later when back at computer) so it's great timing for that as well.

Cheers,

Gareth

Sent from my iPhone

On 13 Feb 2015, at 20:53, Cantor, Scott canto...@osu.edu wrote:

 We need a 3.1.2 release very badly. I'm willing to contribute heavily to that
 process.
 
 Correcting myself, I see that the fix I need was applied to trunk and is part 
 of, I guess,  what would be 3.2, not 3.1.2. I'm not sure if either branch is 
 active at this point, but if not, I probably have to fork, so what is the 
 current chance of seeing a release?
 
 It doesn't seem like me forking is superior to my just preparing a release 
 based on trunk, which seems to build. I'm willing to do that since I'm 
 already an Apache committer, if given access and nobody else is willing.
 
 Thanks,
 -- Scott
 
 
 -
 To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
 For additional commands, e-mail: c-dev-h...@xerces.apache.org
 

-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org