You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Cantor, Scott" <ca...@osu.edu> on 2015/02/13 21:53:04 UTC
Next release (was RE: [jira] [Resolved] (XERCESC-2043))
> 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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 2/17/15, 4:41 PM, "Cantor, Scott" <ca...@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))
Posted by "Cantor, Scott" <ca...@osu.edu>.
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))
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Scott,
Cantor, Scott <ca...@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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Scott,
Cantor, Scott <ca...@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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Scott,
Cantor, Scott <ca...@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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
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))
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Scott,
Cantor, Scott <ca...@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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
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))
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Scott,
Cantor, Scott <ca...@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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 2/16/15, 2:51 PM, "Cantor, Scott" <ca...@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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
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))
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Scott,
Cantor, Scott <ca...@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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by "Cantor, Scott" <ca...@osu.edu>.
> 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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Next release (was RE: [jira] [Resolved] (XERCESC-2043))
Posted by Gareth Reakes <ga...@reakes.com>.
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 <ca...@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-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org