Jean T. Anderson wrote:
Rick Hillegas wrote:
Jean T. Anderson wrote:
Rick Hillegas wrote:
Jean T. Anderson wrote:
Kathey Marsden wrote:
Rick Hillegas wrote:
As a test of this, I have updated the description of 10.4.2.1.
You can see this by clicking on the link you forwarded. Does
this format look reasonable to you?
I think we cannot include an url to the Sun build in Jira.
According to:
http://www.apache.org/dev/release.html
"Do not include any links on the project website that might
encourage non-developers to download and use nightly builds,
snapshots, release candidates, or any other similar package.
...
Under no circumstances are unapproved builds a substitute for
releases. If this policy seems inconvenient, then release more
often. Proper release management is a key aspect of Apache
software development.
That www.apache.org/dev/release.html policy governs distribution
of software produced by an Apache project and made available for
download from an Apache website.
Why are we concerned about tracking releases produced by
non-Apache entities, such as Sun?
And IBM. And anyone else who wants to build a distribution from the
community branches. We're talking about tracking and fixing bugs
which are logged against commit points on a community codeline,
whether that is the development mainline or one of our stable
branches. This is useful to everyone who drinks out of the common
well.
but it doesn't make sense for an apache project to reference
somebody else's external (non-Apache) build or distribution.
--That's a slippery slope that would then need to accommodate
anybody who comes along. And we should never bump the Derby release
number to accommodate an external project.
Hi Jean,
If you need to fix bugs in the metadata queries, then you have to
bump the last digit of the release id in order to coax Derby into
recompiling the queries. This is what IBM did to fix DERBY-3919.
Committers fix bugs all the time in order to accommodate external
projects. Do you believe that the community has agreed to a
limitation on updates to the last digit of the release id, and if so,
what are those limitations?
I think I'm not quite understanding the fundamental issue here. I
have no problem with Sun tech support finding a problem, doing the
fix, and committing it to Apache. Or IBM doing the same thing. Or Joe
WhomEver from Company X.
The issue is if any external entity fixes something in their own
distro that hasn't been contributed back to apache yet, they're on
their own. I don't think we should accommodate that. But rereading
this, I don't think this is what you intended and I misunderstood. I'm
sorry.
No need to apologize. I think the issues are still a bit tangled and
we're all muddling through this together.
Sun effectively released from the 10.4.2 branch to include a fix that
is in that branch at Apache, but "10.4.2" isn't specific enough to
identify what comprises that release. Is this right? :-)
That's right. We're talking about bugs that were fixed in the open and
patches that were checked into the community codeline..
In this case, I agree that we might want to consider bumping the digit
on a per-request basis, but I want to make sure that we do this in a
way that makes general sense. And I also realize that this might
conceivably leave us open to criticism that we are enabling support
for unofficial releases.
A couple more thoughts:
1) It helps me to separate the version id in the branch from the version
id in JIRA. I would have no problem with bumping the 4th digit of the
branch id every time someone checked a bugfix into the branch. I'm not
saying I want to do this, I'm just saying that it wouldn't bother me.
2) It would seem simpler to me if we had generic release ids in JIRA,
like "10.3.next" and "10.4.next". The meaning of these ids is "the next
release vehicle created from that branch". We don't really know what the
release id will be until we've generated a couple release candidates and
at that point, the release manager has to bulk-reassign the "fixed-in"
field anyway.
3) Then there is the question of how to mark issues whose fixes appear
in distributions which were created outside the community even though
the distributions were created from community codelines. Is this
information which the community should track?
4) There's also the question of how to log bugs which surface in one of
these external distributions. These are bugs in the community code and
everyone benefits from knowing about these bugs and from their fixes.
What should we put in the "affects version" field? How do we signal what
the subversion commit-stamp is--the bug-fixer may need this information.
It seems to me that the main sources of bug reports are:
a) Bugs arising in official Derby releases which users have downloaded
from the Apache website
b) Bugs arising in Cloudscape releases. If I understand correctly, these
releases roll up additional bug fixes on top of what appear in the
community distributions. That is, these distributions represent a
subversion commit-stamp further along the branch than the corresponding
community release.
c) Bugs arising in Java DB releases whose bits are identical to official
Derby releases and whose subversion commit-stamps are identical to
community releases.
d) Bugs arising in Java DB releases which roll up additional bug fixes,
like the Cloudscape releases.
My actual preference here is if there's a need for release with, let's
say, 2 bug fixes, go ahead and release officially. :-) I would think
that a branch + 2 fixes (or however many) would be an easy shoe-in for
a release vote because all the heavy lifting was done on that release
for that branch.
This would be a way forward if our release process were simpler. I think
that our procedures are improving, but as Myrna points out in a later
message, producing a Derby release takes a fair amount of time. The
community process adds a minimum of 2 weeks to the production of a patch
release. That's too long for someone who needs to get an emergency patch
to a customer.
Thanks,
-Rick
-jean
