You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2005/04/01 22:46:01 UTC
Soliciting signatures for Subversion 1.1.4
We have tagged Subversion 1.1.4 and are now soliciting signatures from our
committers before we issue the release.
[NOTE THAT 1.1.4 IS NOT OFFICIALLY RELEASED YET!]
Subversion 1.1.4 is the first release that we'll ask for committers to
submit their PGP signatures of the tarballs that we'll include at
announcement-time. Therefore, 1.1.4 isn't released until we receive at
least 3 PGP signatures from committers.
Review and feedback are requested. It is important to know of any
regressions from 1.1.3 as soon as possible.
I've tested this on Darwin, Solaris, and Linux. It looks fine on there.
Darwin has goofiness with javahl due to libtool 1.4.3 - re-running
autogen.sh with libtool 1.5.10+ enables javahl to build on Darwin. This is
not a regression (i.e. broken in 1.1.3 as well), and will be fixed in 1.2.0
as we will upgrade libtool versions for that series.
Once we receive three PGP signatures from committers, then we will start
the announcement process and link to it on tigris.org and send out the
announcement email.
The announcement will happen no earlier than Saturday afternoon Pacific
time - roughly 24 hours from now. I don't really want to send an
announcement on April Fool's Day either...
Committers can reply to this message with their PGP/GPG detached signature
of the tarballs if they approve of the release. An example is:
gpg -b --armor subversion-1.1.4.tar.gz
gpg -b --armor subversion-1.1.4.tar.bz2
gpg -b --armor subversion-1.1.4.zip
We'll somehow update the .asc files as committers sign the release. =)
With all of that out of the way, you can find 1.1.4 at:
<http://subversion.tigris.org/tarballs/subversion-1.1.4.tar.bz2>
<http://subversion.tigris.org/tarballs/subversion-1.1.4.tar.gz>
<http://subversion.tigris.org/tarballs/subversion-1.1.4.zip>
Current PGP signatures at:
<http://subversion.tigris.org/tarballs/subversion-1.1.4.tar.bz2.asc>
<http://subversion.tigris.org/tarballs/subversion-1.1.4.tar.gz.asc>
<http://subversion.tigris.org/tarballs/subversion-1.1.4.zip.asc>
The 1.1.4 release files are currently signed with my PGP key (E2226795).
MD5 signatures:
MD5 (subversion-1.1.4.tar.bz2) = 6e557ae65b6b8d7577cc7704ede85a23
MD5 (subversion-1.1.4.tar.bz2.asc) = 436e90586a81257a7c756a50b2a2b0a6
MD5 (subversion-1.1.4.tar.gz) = 631bf13698e9a62d98c7b2f7eb9ae2b8
MD5 (subversion-1.1.4.tar.gz.asc) = cd55c0812b69b5c4900a76d9d2dafe3d
MD5 (subversion-1.1.4.zip) = 93206819d1fa912e8fecc9a548904e28
MD5 (subversion-1.1.4.zip.asc) = 032f58fb8c74d053273891a05067aff3
Thanks! -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Soliciting signatures for Subversion 1.1.4
Posted by Branko Čibej <br...@xbc.nu>.
Justin Erenkrantz wrote:
> We have tagged Subversion 1.1.4 and are now soliciting signatures from
> our committers before we issue the release.
>
> [NOTE THAT 1.1.4 IS NOT OFFICIALLY RELEASED YET!]
Tested on Win32 SMP (Windows XP SP2)
-- Brane
Re: Soliciting signatures for Subversion 1.1.4
Posted by John Szakmeister <jo...@szakmeister.net>.
On Friday 01 April 2005 18:44, John Szakmeister wrote:
> On Friday 01 April 2005 17:46, Justin Erenkrantz wrote:
> > We have tagged Subversion 1.1.4 and are now soliciting signatures
> > from our committers before we issue the release.
>
> I thought we weren't going start doing this on the 1.2.0 release? Did
> I miss something?
I should read my messages before sending... I thought we were not doing
this for the *1.1.4* release. I thought we were going to start signing
the tarballs for the 1.2.0 release. See:
http://svn.haxx.se/dev/archive-2005-03/1364.shtml
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Soliciting signatures for Subversion 1.1.4
Posted by John Szakmeister <jo...@szakmeister.net>.
On Friday 01 April 2005 17:46, Justin Erenkrantz wrote:
> We have tagged Subversion 1.1.4 and are now soliciting signatures from
> our committers before we issue the release.
I thought we weren't going start doing this on the 1.2.0 release? Did I
miss something?
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by John Szakmeister <jo...@szakmeister.net>.
On Saturday 02 April 2005 23:27, kfogel@collab.net wrote:
> Ben Reser <be...@reser.org> writes:
> > Frankly, I've always wondered why we don't have a "tags" directory
> > and a "releases" directory. It seems cluttered to have release tags
> > mixed with unrelated tags that we might want to use. Plus having a
> > releases directory enhances the communication factor that the tag
> > represents.
>
> Why not just a subdirectory, "/tags/releases/..." ?
Actually, at my work place, we use what Ben suggested. When settled on
having releases off of the root, I think it was primarily
because /tags/release/release-name seemed to far to go. :-)
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> Frankly, I've always wondered why we don't have a "tags" directory and a
> "releases" directory. It seems cluttered to have release tags mixed
> with unrelated tags that we might want to use. Plus having a releases
> directory enhances the communication factor that the tag represents.
Why not just a subdirectory, "/tags/releases/..." ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Sunday, April 3, 2005 4:07 AM -0700 Ben Reser <be...@reser.org> wrote:
> RM's don't decide what the release is, we just manage the process and
> do some of the foot work. The tarball you cut isn't 1.1.4 officially
> until the committers say it is. It's a proposed 1.1.4. That's how I've
> always looked at it.
>
> By what you're saying the RM has a great deal more power than I ever
> felt like I had. Just becuase I generated a tarball didn't mean I'd
> made a given release number. It meant I'd produced something for the
> developers to decide if it was that release number.
No, because the RM has to say, "*This* is 1.1.4." The committers (as a whole)
are then the ones who say, "1.1.4 is a public release" (or not). The
committers can't collectively decide what goes into the release - that's the
RM job, in my view.
The problem with your approach is that there could be multiple "1.1.4"
releases and that could be really confusing. There should only ever be one
"1.1.4" - once the tarball is posted anywhere, the release is done and not
modifiable in anyway. It must stand on its own merits then.
> Why do you think the tag should appear at the point of tarball creation?
> I have regenerated the tarball several times because I found mistakes on
> my part without upping the revision number. As long as I don't post the
> tarball publically anywhere I'd just leave the version number the same.
No, I'm saying that the tag should appear before (or at the same time) it ever
appears publicly in any fashion.
> Granted in the past the timeframe between tarball creation and
> announcement has been much tigheter. But I don't think the tag is all
> that useful. It's just a shorthand way of referring to the specific
> revision and branch we cut the release from. The only extra the tag has
> is that it has a release marked svn_version.h which for testing purposes
> is competely irrelevent anyway.
No, but it modifies the release and the contents of the release. Hence, it
belongs in the tag.
> I'm not sure how you're going to figure that out for the tag. There's
> not going to be anything in the logs saying why it was a failed release.
> The only way you'd know that tag was a failed release was by knowing it
> or by reading it from outside the repo. Further, there might not be
> anything wrong with the tag. A dud 1.1.4 tarball could have an
> identical set of files to a 1.1.5 tarball with only differences made to
> the environment the tarball was produced in.
FWIW, in httpd, the rule is that you could re-roll a release if the
environment is busted (discretion is left to the RM). But, you can not change
the code in *any* fashion. So, re-rolling because of a busted libtool would
be fine for httpd and wouldn't necessitate a version bump. Any typos in a
file or error in compilation would mean that the version has to be bumped.
> Nobody can use the tag as a way of signing off on a release. Becuase
> the tag isn't the entirety of the release or the way the vast majority
> of our users receive our software.
But, the tag must be the authoritative claim that 'this' is the code that
produced the release.
> Honestly, I think part of the difference here is that I think you should
> be able to take the repository and be able to tell what is going on from
> it. But with your tags for things that we don't ever actually treat as
> "offical releases" there's no way of telling that from the repository...
> You're suddenly relying on all kinds of things like mailing list logs
> and IRC logs to figure out what is going on. And in my experience that
> stuff isn't always reliably archived.
Again, we differ as to when the release is created. I view the release as
created once the RM posts a tarball for approval. You view it as created once
it is approved. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Ben Reser <be...@reser.org>.
On Sat, Apr 02, 2005 at 05:34:05PM -0800, Justin Erenkrantz wrote:
> The confusion here is to when is the release created:
>
> - I believe the release is created when the RM posts tarballs for approval.
> At that point, the version number is 'gone' and can't be modified. Nothing
> else can be called that release in any unambiguous manner. For example, we
> should never have two files claiming to be 1.1.4. Therefore, we should
> remove the ambiguity and lay down the tag as soon as the tarballs are
> created by the RM.
RM's don't decide what the release is, we just manage the process and
do some of the foot work. The tarball you cut isn't 1.1.4 officially
until the committers say it is. It's a proposed 1.1.4. That's how I've
always looked at it.
By what you're saying the RM has a great deal more power than I ever
felt like I had. Just becuase I generated a tarball didn't mean I'd
made a given release number. It meant I'd produced something for the
developers to decide if it was that release number.
> - My understanding of your position is that the release isn't created until
> the announcement is sent. At any point until then, the tag can be changed
> by the RM. (If I misstate your position, please correct me. I'm only
> trying to understand your position better.)
The tag wouldn't be made until just before the announcement. That's how
I always did it.
> My concern with your approach is that a tag would not appear when it should
> have otherwise appeared. I believe that the version numbers are cheap and
> that if it fails approval, the release still exists - it just wasn't made
> public.
I don't think it was ever a release if we don't approve it as a release.
If we toss the version number to avoid confusion, that's fine. But if
it isn't signed off on by the other committers, it's not a release. The
official announcement isn't what elevates the tarball to release status
the consensus of the committers does. We've done this very informaly in
the past, we're trying to be more formal now. But I don't think this
has ever really changed.
Why do you think the tag should appear at the point of tarball creation?
I have regenerated the tarball several times because I found mistakes on
my part without upping the revision number. As long as I don't post the
tarball publically anywhere I'd just leave the version number the same.
Granted in the past the timeframe between tarball creation and
announcement has been much tigheter. But I don't think the tag is all
that useful. It's just a shorthand way of referring to the specific
revision and branch we cut the release from. The only extra the tag has
is that it has a release marked svn_version.h which for testing purposes
is competely irrelevent anyway.
> Historically, it's interesting to see why a release failed - this allows
> people (and RMs) to learn from previous mistakes. Therefore, yah, I'm not
> opposed to keeping a record of 'failed' releases - in the hopes that people
> down the road will learn why a release failed and not make the same mistake
> again...
I'm not sure how you're going to figure that out for the tag. There's
not going to be anything in the logs saying why it was a failed release.
The only way you'd know that tag was a failed release was by knowing it
or by reading it from outside the repo. Further, there might not be
anything wrong with the tag. A dud 1.1.4 tarball could have an
identical set of files to a 1.1.5 tarball with only differences made to
the environment the tarball was produced in.
For example if the wrong version of libtool was installed... The
tarball is the definitive thing we need to be approving. Not the tag.
The tag just needs to be a copy of the source of the export that dist.sh
used with the correctly modified svn_version.h.
Nobody can use the tag as a way of signing off on a release. Becuase
the tag isn't the entirety of the release or the way the vast majority
of our users receive our software.
Honestly, I think part of the difference here is that I think you should
be able to take the repository and be able to tell what is going on from
it. But with your tags for things that we don't ever actually treat as
"offical releases" there's no way of telling that from the repository...
You're suddenly relying on all kinds of things like mailing list logs
and IRC logs to figure out what is going on. And in my experience that
stuff isn't always reliably archived.
> >What harm is calling it 1.1.4-test going to be until we refer to it as
> >"official?"
>
> The tarball isn't called subversion-1.1.4-test nor would the svn_version.h
> refer to it as 1.1.4-test. Therefore, I believe that the tag should
> reflect what the tarball reports.
The point here is to use a temporary name to avoid confusion on the part
of people external to the project. When we've decided the tarball is
good or bad we'd rename or remove the 1.1.4-test path. If we didn't
have a separate dir for release tags I'd just delete it, but I'm not
terribly against have a 1.1.4 tag for an unreleased version number
provided that the 1.1.5 exists... I.E. I'd probably leave it as
1.1.4-test until 1.1.5-test was renamed to 1.1.5.
If we have a separate directory for release tags then using this isn't
really necessary. We can just tag 1.1.4 in tags, and then move it to
releases just before the announcement. If we toss the tarball and do
1.1.5 then we just never move it.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, April 4, 2005 12:05 PM -0500 kfogel@collab.net wrote:
> IMHO it was -- thanks for posting.
Agreed.
> I think the big lesson we should draw here is that once a tarball has
> become publicly visible in any way at all -- by appearing in a
> downloads area, whatever -- we must consider it released. We don't
> have a choice about this. People will download it, people will base
> third-party releases on it, people will submit to Freshmeat, etc. It
> is *not* within our power to say "No, that wasn't a real release." We
> can shout it to the wind all we want, but it won't change the way
> people treat the tarball.
I agree that we have to say it's a release once we solicit signatures, but
what others do with it is never anything we can control. Someone could
take branches/1.1.x or trunk and call it a release, too.
> Therefore, I think it would be best to do the pre-release testing and
> signing processes privately, among the full committers, and *then* put
> the thing out where others can see it. If a problem is discovered
> after that, well, then we chuck that release number and make a new
> release with the next available number.
As I've mentioned before, I really disagree with this. I don't like
creating a star chamber where upon releases magically appear.
> This wold lose us a little bit in the "Do Everything Openly"
> department, but not in a major way, and I don't see any other way to
> do it. We want the release to be tested & signed; in order to do
> that, we have to test & sign it before we "release" it. We've learned
> that this verb "release" has a meaning we don't entirely control, so
> we have to be careful about what we make available and when.
I'd point out that other projects don't have this problem. I think it's a
matter of clearly defining what our release process is. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Philip Martin <ph...@codematters.co.uk>.
Sander Striker <st...@apache.org> writes:
> kfogel@collab.net wrote:
>> I think the big lesson we should draw here is that once a tarball has
>> become publicly visible in any way at all -- by appearing in a
>> downloads area, whatever -- we must consider it released. We don't
>> have a choice about this. People will download it, people will base
>> third-party releases on it, people will submit to Freshmeat, etc. It
>> is *not* within our power to say "No, that wasn't a real release." We
>> can shout it to the wind all we want, but it won't change the way
>> people treat the tarball.
>
> It depends on where you put the tarball for testing. It definitely
> doesn't belong in subversion.tigris.org/tarballs/ during testing.
> If you put it in a place like: /testing/tarballs/ or something like
> that, the status of the tarball is a lot clearer.
We can also change the name of the tarball. The name doesn't have to
contain the version number, it doesn't even have to contain the word
"subversion". The tarball can later be renamed and any signatures
will remain valid.
>> Therefore, I think it would be best to do the pre-release testing and
>> signing processes privately, among the full committers, and *then* put
>> the thing out where others can see it. If a problem is discovered
>> after that, well, then we chuck that release number and make a new
>> release with the next available number.
>
> Heck no. We get into the smoke-filled-backroom-where-the-old-boys-decide
> what-is-a-release territory. Or at least the perception. Please keep it
> open.
>
> Also consider that when only allowing full-committers@ to participate,
> and thus to test, you are eliminating a useful group for feedback.
> People who have access to platforms we don't have access to, or maybe
> access to the same platform and actually have cycles to burn to do a
> testrun. Better to have dev@ figure out a release is a dud than to have
> the rest of the world come to that conclusion.
I agree.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Sander Striker <st...@apache.org>.
kfogel@collab.net wrote:
> "Bruce A. Mah" <bm...@acm.org> writes:
>
>>More info on FreeBSD release engineering can be found at:
>>
>>http://www.freebsd.org/releng/
>>
>>Hope this is helpful.
>
>
> IMHO it was -- thanks for posting.
>
> I think the big lesson we should draw here is that once a tarball has
> become publicly visible in any way at all -- by appearing in a
> downloads area, whatever -- we must consider it released. We don't
> have a choice about this. People will download it, people will base
> third-party releases on it, people will submit to Freshmeat, etc. It
> is *not* within our power to say "No, that wasn't a real release." We
> can shout it to the wind all we want, but it won't change the way
> people treat the tarball.
It depends on where you put the tarball for testing. It definitely
doesn't belong in subversion.tigris.org/tarballs/ during testing.
If you put it in a place like: /testing/tarballs/ or something like
that, the status of the tarball is a lot clearer.
> Therefore, I think it would be best to do the pre-release testing and
> signing processes privately, among the full committers, and *then* put
> the thing out where others can see it. If a problem is discovered
> after that, well, then we chuck that release number and make a new
> release with the next available number.
Heck no. We get into the smoke-filled-backroom-where-the-old-boys-decide
what-is-a-release territory. Or at least the perception. Please keep it
open.
Also consider that when only allowing full-committers@ to participate,
and thus to test, you are eliminating a useful group for feedback.
People who have access to platforms we don't have access to, or maybe
access to the same platform and actually have cycles to burn to do a
testrun. Better to have dev@ figure out a release is a dud than to have
the rest of the world come to that conclusion.
> This wold lose us a little bit in the "Do Everything Openly"
> department, but not in a major way, and I don't see any other way to
> do it. We want the release to be tested & signed; in order to do
> that, we have to test & sign it before we "release" it. We've learned
> that this verb "release" has a meaning we don't entirely control, so
> we have to be careful about what we make available and when.
I think we just have to deal with the fact that with doing things in
the open we loose some control over when things are brought into the
spotlight.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by kf...@collab.net.
"Bruce A. Mah" <bm...@acm.org> writes:
> More info on FreeBSD release engineering can be found at:
>
> http://www.freebsd.org/releng/
>
> Hope this is helpful.
IMHO it was -- thanks for posting.
I think the big lesson we should draw here is that once a tarball has
become publicly visible in any way at all -- by appearing in a
downloads area, whatever -- we must consider it released. We don't
have a choice about this. People will download it, people will base
third-party releases on it, people will submit to Freshmeat, etc. It
is *not* within our power to say "No, that wasn't a real release." We
can shout it to the wind all we want, but it won't change the way
people treat the tarball.
Therefore, I think it would be best to do the pre-release testing and
signing processes privately, among the full committers, and *then* put
the thing out where others can see it. If a problem is discovered
after that, well, then we chuck that release number and make a new
release with the next available number.
This wold lose us a little bit in the "Do Everything Openly"
department, but not in a major way, and I don't see any other way to
do it. We want the release to be tested & signed; in order to do
that, we have to test & sign it before we "release" it. We've learned
that this verb "release" has a meaning we don't entirely control, so
we have to be careful about what we make available and when.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by "Bruce A. Mah" <bm...@acm.org>.
If memory serves me right, Ben Reser wrote:
> Now you guys are just throwing out ideas without really thinking about
> how the release process works and it's turned into "How can I change the
> process."
(Picking a random message with the word "process" in it to reply to.)
First, I want to thank all of the Subversion developers for a great
product. I really admire your quality, professionalism, and attention
to detail.
Commentary from an outsider looking in: This discussion reminds me a
some problems I've seen first-hand as a former member of FreeBSD's
release engineering team. Basically, doing release engineering using
publically-visible mechanisms (in our case, CVS and FTP mirrors)
introduces a few pitfalls, some of which you have seen yourselves.
Here's a few lessons we learned, perhaps they might be useful in some
way here.
We had two problems in this general area: One is that we needed to make
tags in CVS (in order to generate release images) but we didn't
necessarily want people using these tags as authoritatively defining the
release Until We Said So. (We occasionally needed to tweak the tag for
last-minute build problems, version strings that didn't get bumped
correctly, and so on.) Over the years we've learned to announce tagging
loudly on relevant mailing lists (along with appropriate disclaimers
that tags can change). This generally works pretty well, although every
release cycle there's one or two people who somehow miss this and get
confused. While annoying, I think this is acceptable.
The other problem (which may or may not be applicable here) is that the
process of pushing out ISOs, etc. to our mirror sites in advance of a
release announcement is fairly "public" and visible. Frequently,
someone will "scoop" us by noting on Slashdot or other forum that "the
new ISOs are out!" before we're ready for an official announcement. For
quite a long time we objected vigorously on the grounds that "we might
need to recall the release before we announce it". We had some fairly
elaborate schemes for munging file permissions of files on the mirrors
too. After awhile, we realized this was like trying to squeeze the
toothpaste back in the tube, and we just came to the conclusion that we
just need to wrap up all of the testing before releasing the
distribution to the mirrors.
Something that I think helped users and developers alike to orient
themselves was to post our release engineering processes and TODO list
(as you have done), and also our current schedule. Basically this gave
people the context to interpret various events they were seeing.
Keeping this information current is important.
More info on FreeBSD release engineering can be found at:
http://www.freebsd.org/releng/
Hope this is helpful.
Best,
Bruce.
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Ben Reser <be...@reser.org>.
On Sun, Apr 03, 2005 at 09:27:52AM -0800, Justin Erenkrantz wrote:
> >Regarding the issues of svn_version.h - how about a "freeze-version"
> >script,
> >which performs the necessary transformation in a publicly defined way.
>
> Sure. I don't like that dist.sh munges the version number.
Ugh this is stupid, and now a complete waste of time. We went round and
round and round about if dist.sh should do this. We beat this issue to
death ages ago. I explained over and over and over why it had to be
done that way.
Now you guys are just throwing out ideas without really thinking about
how the release process works and it's turned into "How can I change the
process."
The process that has existed works just fine. Can it be improved yes.
But you need to explain what is wrong with what exists. Not just "this
is how it should be done" or "this is how Apache does it."
So please before you guys start tossing out new ideas to fix problems
that don't exist at least go read the zillions of threads where we
talked about this before.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Sunday, April 3, 2005 12:26 PM +0100 Max Bowsher <ma...@ukf.net> wrote:
> In order to prevent people jumping the gun, how about naming prerelease
> tarballs something like "subversion-1.1.x-r18000.tar.bz2"? The content is
> exactly specified, and it is clear it is not a "normal" tarball. When
> approved, the tarball simply gets renamed.
I'm hesitant to have two different versions of a file that would otherwise be
identical.
> Regarding the issues of svn_version.h - how about a "freeze-version" script,
> which performs the necessary transformation in a publicly defined way.
Sure. I don't like that dist.sh munges the version number.
> Therefore, I would like to propose that we continue using dev@subversion,
> but carefully never mention an exact version number in a pre-release
> announcement. i.e. instead of "1.1.5", say "the next 1.1.x", or similar.
+1. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Max Bowsher <ma...@ukf.net>.
I'm replying in general, with topic headings in lieu of quoted text.
1) "When to tag"
I think it is correct that "tags/1.1.5" _must_ be identical code to
"subversion-1.1.5.tar.bz2".
Thus, as soon as a tarball with that name is created, the relevant tag
should be present.
In order to prevent people jumping the gun, how about naming prerelease
tarballs something like "subversion-1.1.x-r18000.tar.bz2"? The content is
exactly specified, and it is clear it is not a "normal" tarball. When
approved, the tarball simply gets renamed.
Regarding the issues of svn_version.h - how about a "freeze-version" script,
which performs the necessary transformation in a publicly defined way.
2) "Use of dev@subversion"
I don't think there is any need to carry out releases in secret
(svn-full-committers), but I am concerned that dev@subversion has a somewhat
different "flavour" to dev@httpd - I think we have a higher populations of
users on our dev list.
Therefore, I would like to propose that we continue using dev@subversion,
but carefully never mention an exact version number in a pre-release
announcement. i.e. instead of "1.1.5", say "the next 1.1.x", or similar.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, April 2, 2005 4:52 PM -0800 Ben Reser <be...@reser.org> wrote:
> There should not be a tag for a "release" until it is an "official
> release" as long as we're using a generic "tag" folder because the
> status of the tag is completely ambiguous without digging around
> elsewhere. Your repository shouldn't be ambigious.
The confusion here is to when is the release created:
- I believe the release is created when the RM posts tarballs for approval.
At that point, the version number is 'gone' and can't be modified. Nothing
else can be called that release in any unambiguous manner. For example, we
should never have two files claiming to be 1.1.4. Therefore, we should remove
the ambiguity and lay down the tag as soon as the tarballs are created by the
RM.
- My understanding of your position is that the release isn't created until
the announcement is sent. At any point until then, the tag can be changed by
the RM. (If I misstate your position, please correct me. I'm only trying to
understand your position better.)
My concern with your approach is that a tag would not appear when it should
have otherwise appeared. I believe that the version numbers are cheap and
that if it fails approval, the release still exists - it just wasn't made
public.
Historically, it's interesting to see why a release failed - this allows
people (and RMs) to learn from previous mistakes. Therefore, yah, I'm not
opposed to keeping a record of 'failed' releases - in the hopes that people
down the road will learn why a release failed and not make the same mistake
again...
> What harm is calling it 1.1.4-test going to be until we refer to it as
> "official?"
The tarball isn't called subversion-1.1.4-test nor would the svn_version.h
refer to it as 1.1.4-test. Therefore, I believe that the tag should reflect
what the tarball reports. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Ben Reser <be...@reser.org>.
On Sat, Apr 02, 2005 at 04:36:20PM -0800, Justin Erenkrantz wrote:
> It wasn't done on a mailing list, so the feedback was limited to whomever
> was on IRC at that particular time. Since we want to solicit signatures
> before announcing, we now need to make the announcement more widespread
> (and I believe, necessitating an email).
Well of course, which is why you'd put the revision and the branch in
the email. I'm obviously not saying you just announce it on IRC.
> Therefore, I believe it needs to be clearer where the release originated
> from: rather than just a revision from a directory, an actual directory
> that contains the tag.
What's unclear about giving a revision and path? Could you really
believe that there is a full committer here that couldn't understand
that?
> Once we decide to do a release, then at the point, the release exists. We
> can't (or shouldn't!) change the tag. The only difference is whether we
> make (or, recommend, depending upon your perspective) the release public or
> not: i.e. is it a good release? But, the issue is that the version is
> done...goodness or not is the question.
Sure, and until we're sure it's good we want to discourage people from
using it. The point here is to formalize testing. Not to put the code
in the hands of people faster. We have to remember that no matter what
we do this is going to end up running live on somebody's machine as soon
as we make any public announcements. Even if we strongly urge people
not to.
We've been fortunate and the "bad releases" we've had have been
relatively minor problems. What happens when we have a bad release that
destorys data only on a particular platform that the RM doesn't have
access to?
> The release isn't official until we say it is. =)
> >If you absolutely must have a tag then name it 1.1.4-test or something
> >like that. If the release is okay then mv it to 1.1.4, if it's trashed
> >then we just delete it and never post that tarball and start over with
> >1.1.5.
> >
> >But I really do believe that creating a tag says "this is a release."
>
> Once we soliciting signatures, it means that it is a release. Hence, I
> feel it should be in tags/.
Bahh. Fine let's use your terms.
There should not be a tag for a "release" until it is an "official
release" as long as we're using a generic "tag" folder because the
status of the tag is completely ambiguous without digging around
elsewhere. Your repository shouldn't be ambigious.
What harm is calling it 1.1.4-test going to be until we refer to it as
"official?"
> >Frankly, I've always wondered why we don't have a "tags" directory and a
> >"releases" directory. It seems cluttered to have release tags mixed
> >with unrelated tags that we might want to use. Plus having a releases
> >directory enhances the communication factor that the tag represents.
> >
> >There can be a 1.1.4 in tags, but if we decide to never call it a
> >release for some reason it just wouldn't exist in releases.
>
> That would work fine and would address a lot of your concerns. I'd like to
> hear what others think about it first...
Ok...
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, April 2, 2005 4:18 PM -0800 Ben Reser <be...@reser.org> wrote:
> What's the confusion? I always announced on IRC when I was soliciting
> testing what revision the release was cut from on the branch. The only
> difference that would ever exist between the tag and the branch would be
> the minor differences between the svn_version.h file.
It wasn't done on a mailing list, so the feedback was limited to whomever was
on IRC at that particular time. Since we want to solicit signatures before
announcing, we now need to make the announcement more widespread (and I
believe, necessitating an email).
Therefore, I believe it needs to be clearer where the release originated from:
rather than just a revision from a directory, an actual directory that
contains the tag.
> I have no problem with tossing the revision number if we toss the
> tarball. But I don't think the tag should exist until we decide that it
> is a good release.
Once we decide to do a release, then at the point, the release exists. We
can't (or shouldn't!) change the tag. The only difference is whether we make
(or, recommend, depending upon your perspective) the release public or not:
i.e. is it a good release? But, the issue is that the version is
done...goodness or not is the question.
> I think that's highly optomistic. Our repository is a communication
> medium. Basically if you don't read dev you can't be sure what the
> status of the tag is. When I've done announcements on the weekends
> sometimes the announcement email hasn't been moderated through until
> Monday.
The release isn't official until we say it is. =)
> If you absolutely must have a tag then name it 1.1.4-test or something
> like that. If the release is okay then mv it to 1.1.4, if it's trashed
> then we just delete it and never post that tarball and start over with
> 1.1.5.
>
> But I really do believe that creating a tag says "this is a release."
Once we soliciting signatures, it means that it is a release. Hence, I feel
it should be in tags/.
> Frankly, I've always wondered why we don't have a "tags" directory and a
> "releases" directory. It seems cluttered to have release tags mixed
> with unrelated tags that we might want to use. Plus having a releases
> directory enhances the communication factor that the tag represents.
>
> There can be a 1.1.4 in tags, but if we decide to never call it a
> release for some reason it just wouldn't exist in releases.
That would work fine and would address a lot of your concerns. I'd like to
hear what others think about it first... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Ben Reser <be...@reser.org>.
On Sat, Apr 02, 2005 at 03:37:34PM -0800, Justin Erenkrantz wrote:
> My concern is that once we send a public email to any list, that version is
> gone - hence, the tag should be laid down at that point. There should
> never be any confusion as to, say, what the 1.1.4 release contains.
What's the confusion? I always announced on IRC when I was soliciting
testing what revision the release was cut from on the branch. The only
difference that would ever exist between the tag and the branch would be
the minor differences between the svn_version.h file.
> I'm not comfortable sending anything to any list saying 'this is 1.1.4'
> (including to dev@svn soliciting signatures for approval) without having
> the /tags/1.1.4 created first. If there's a problem with the 1.1.4 tag
> during the signature process, then we would bump to 1.1.5 - not reuse 1.1.4.
I have no problem with tossing the revision number if we toss the
tarball. But I don't think the tag should exist until we decide that it
is a good release.
> Our downstream packagers just need to be aware that a release isn't
> official until we send the announcement.
I think that's highly optomistic. Our repository is a communication
medium. Basically if you don't read dev you can't be sure what the
status of the tag is. When I've done announcements on the weekends
sometimes the announcement email hasn't been moderated through until
Monday.
If you absolutely must have a tag then name it 1.1.4-test or something
like that. If the release is okay then mv it to 1.1.4, if it's trashed
then we just delete it and never post that tarball and start over with
1.1.5.
But I really do believe that creating a tag says "this is a release."
Frankly, I've always wondered why we don't have a "tags" directory and a
"releases" directory. It seems cluttered to have release tags mixed
with unrelated tags that we might want to use. Plus having a releases
directory enhances the communication factor that the tag represents.
There can be a 1.1.4 in tags, but if we decide to never call it a
release for some reason it just wouldn't exist in releases.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, April 2, 2005 4:55 PM -0800 Ben Reser <be...@reser.org> wrote:
> No it's not. It's a committers thing. Only the committers have the
> power to call something a release. I think the benefits of "community"
> input at that stage is minimal compared to the potential risks to the
> people who don't listen that it's only there for testing.
I have concerns with making release decisions in private (except for where
embargoed security issues are present). We should place trust in the
community, and in return, the community should trust us to produce
high-quality releases. Yet, we gain this trust by making almost every
decision in public.
Note that end-users who want to run bleeding edge code or things straight from
trunk are always able to do so - no matter what we do for a release. The key
audience that we need to inform of these policies are the downstream packagers.
The TortoiseSVN folks jumped the gun on 1.1.4, so we need to make this clearer
in the future so this doesn't repeat itself.
(I'm not entirely opposed to having non-committers also sign a release. I
really haven't thought through the implications in depth, but I'm not seeing a
clear downside of opening up who signs a release other than someone
mis-representing themselves as a Subversion committer. The more keys we add,
the more likely someone will have a direct trust path to someone who signed.)
> Well the sigs will obviously be publically published. I'm not sure how
> much additional information you really expect to people to gain from the
> email with the signature on it.
Such a message may include what platforms they tested on, or if they saw any
caveats with the release. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Ben Reser <be...@reser.org>.
On Sat, Apr 02, 2005 at 04:39:16PM -0800, Justin Erenkrantz wrote:
> That's a private list and I'm not comfortable conducting releases in
> private. Creating a release is a community thing - as such, I feel this
> needs to occur openly.
No it's not. It's a committers thing. Only the committers have the
power to call something a release. I think the benefits of "community"
input at that stage is minimal compared to the potential risks to the
people who don't listen that it's only there for testing.
> Also, an additional piece of information that a user can use to decide
> whether to 'like' a release is the public votes (and sigs) on dev@svn.
> This way the sigs don't just appear out of the blue.
Well the sigs will obviously be publically published. I'm not sure how
much additional information you really expect to people to gain from the
email with the signature on it.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, April 2, 2005 4:27 PM -0800 Ben Reser <be...@reser.org> wrote:
> On Sun, Apr 03, 2005 at 01:15:40AM +0100, Max Bowsher wrote:
>> I'm not entirely sure dev@svn is the right place to mention the existence of
>> the waiting-for-test tarballs, but I can't think of anywhere better.
>
> full-committers list. They're the only people we would include
> signatures for anyway.
That's a private list and I'm not comfortable conducting releases in private.
Creating a release is a community thing - as such, I feel this needs to occur
openly.
Also, an additional piece of information that a user can use to decide whether
to 'like' a release is the public votes (and sigs) on dev@svn. This way the
sigs don't just appear out of the blue. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Ben Reser <be...@reser.org>.
On Sun, Apr 03, 2005 at 01:15:40AM +0100, Max Bowsher wrote:
> I'm not entirely sure dev@svn is the right place to mention the existance of
> the waiting-for-test tarballs, but I can't think of anywhere better.
full-committers list. They're the only people we would include
signatures for anyway.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Sunday, April 3, 2005 1:15 AM +0100 Max Bowsher <ma...@ukf.net> wrote:
> HOWEVER, I do think that tarballs should NOT appear at
> http://subversion.tigris.org/tarballs/ until after they are official.
I agree. For httpd releases, they usually appear under:
<http://httpd.apache.org/dev/dist/>
Then, when they are official, they go to:
<http://www.apache.org/dist/httpd/>
For SVN, perhaps:
<http://subversion.tigris.org/pre-release/>
But, I don't know how much control CES gives us to add things under the name
space. I'd prefer that any place doesn't require a committer to put up the
space: i.e. it should somehow be a part of the SVN infrastructure.
> I'm not entirely sure dev@svn is the right place to mention the existance of
> the waiting-for-test tarballs, but I can't think of anywhere better.
I would prefer that any list would be a public list. Doing this on a private
list is something I'd really prefer to avoid: the release process should be
transparent to everyone. I'd prefer to get as much feedback during this
'pre-release' time period as possible. If it's a dud, we would like to know
before we send the public announcement. =)
FWIW, httpd releases seeking approval go to dev@httpd, current-testers@httpd,
and stable-testers@httpd. Any beta releases only go to current-testers@httpd.
However, I think a new mailing list might be overkill for svn. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> --On Saturday, April 2, 2005 11:46 AM -0800 Ben Reser <be...@reser.org>
> wrote:
>> This is one of the reasons why I didn't want to tag 1.1.4 until we
>> approved the tarball. Tagging implies that it's ready to go...
>
> My concern is that once we send a public email to any list, that
> version is gone - hence, the tag should be laid down at that point. There
> should never be any confusion as to, say, what the 1.1.4
> release contains.
> I'm not comfortable sending anything to any list saying 'this is
> 1.1.4' (including to dev@svn soliciting signatures for approval)
> without having the /tags/1.1.4 created first. If there's a problem
> with the 1.1.4 tag during the signature process, then we would bump
> to 1.1.5 - not reuse 1.1.4.
> Our downstream packagers just need to be aware that a release isn't
> official until we send the announcement. -- justin
I agree with most of Justin's quoted comments - tagging just indicates a
release is in progress, not complete, and anyone who thinks otherwise is
being unrealistic.
HOWEVER, I do think that tarballs should NOT appear at
http://subversion.tigris.org/tarballs/ until after they are official.
I'm not entirely sure dev@svn is the right place to mention the existance of
the waiting-for-test tarballs, but I can't think of anywhere better.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
When to tag was Re: Soliciting signatures for Subversion 1.1.4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, April 2, 2005 11:46 AM -0800 Ben Reser <be...@reser.org> wrote:
> This is one of the reasons why I didn't want to tag 1.1.4 until we
> approved the tarball. Tagging implies that it's ready to go...
My concern is that once we send a public email to any list, that version is
gone - hence, the tag should be laid down at that point. There should never
be any confusion as to, say, what the 1.1.4 release contains.
I'm not comfortable sending anything to any list saying 'this is 1.1.4'
(including to dev@svn soliciting signatures for approval) without having the
/tags/1.1.4 created first. If there's a problem with the 1.1.4 tag during the
signature process, then we would bump to 1.1.5 - not reuse 1.1.4.
Our downstream packagers just need to be aware that a release isn't official
until we send the announcement. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Soliciting signatures for Subversion 1.1.4
Posted by Ben Reser <be...@reser.org>.
On Sat, Apr 02, 2005 at 12:44:01PM -0600, Ben Collins-Sussman wrote:
> Hm, how is it that TortoiseSVN 1.1.4 is released, even though svn 1.1.4
> isn't?
>
> (I just downloaded and installed it. Here's the announcement:)
>
> http://tortoisesvn.tigris.org/servlets/NewsItemView?newsItemID=1075
This is one of the reasons why I didn't want to tag 1.1.4 until we
approved the tarball. Tagging implies that it's ready to go...
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Soliciting signatures for Subversion 1.1.4
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 2, 2005, at 12:21 PM, Sander Striker wrote:
> Justin Erenkrantz wrote:
>> We have tagged Subversion 1.1.4 and are now soliciting signatures
>> from our committers before we issue the release.
>> [NOTE THAT 1.1.4 IS NOT OFFICIALLY RELEASED YET!].
>
>
Hm, how is it that TortoiseSVN 1.1.4 is released, even though svn 1.1.4
isn't?
(I just downloaded and installed it. Here's the announcement:)
http://tortoisesvn.tigris.org/servlets/NewsItemView?newsItemID=1075
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Soliciting signatures for Subversion 1.1.4
Posted by Sander Striker <st...@apache.org>.
Justin Erenkrantz wrote:
> We have tagged Subversion 1.1.4 and are now soliciting signatures from
> our committers before we issue the release.
>
> [NOTE THAT 1.1.4 IS NOT OFFICIALLY RELEASED YET!].
Tested on:
- Ubunty (Warty Warthog).
> The announcement will happen no earlier than Saturday afternoon Pacific
> time - roughly 24 hours from now. I don't really want to send an
> announcement on April Fool's Day either...
That's supposed to be a joke right? :)
> Committers can reply to this message with their PGP/GPG detached
> signature of the tarballs if they approve of the release. An example is:
Happy to oblige.
Sander