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/02/20 06:26:57 UTC
Volunteering to be RM for 1.1.4 was Re: Backport voters required!
On Sat, Feb 19, 2005 at 05:56:36PM -0600, kfogel@collab.net wrote:
> "Max Bowsher" <ma...@ukf.net> writes:
> > Why do you ask?
> >
> > Ben Reser is our current RM, and has been since 1.0.2 - I haven't
> > noticed him say anything about wanting to step down?
>
> I think Justin just meant "Are you counting on Ben to do this release
> at a particular time?"
Partially correct. Unless Max wants to be the RM (which is really why I
asked) or Ben has an issue with it (I'm going to venture not, but he can speak
up if he does), I'd like to volunteer to be RM for 1.1.4 given that the items
in STATUS are relatively minor. So, I think a 1.1.4 release may be a good
time to try to review and clean up some of our release procedures.
As I have previously stated, I think it'd be good for us to try to get more
people knowledgable about the role of RM. Our goal should be that people who
want to see a release out should be able to put the release out without
relying upon anyone else - moving away from a 'dedicated' RM role. Hence,
there should be enough documentation available about the process and involved
steps so that any full committer can create the release.
The initial stabs at this documentation are in notes/releases.txt, but without
any other RMs having done a release recently, we need to test the procedures.
I think the best strategy is to tag an RM who hasn't done it before. =)
/me foolishly raises hand
> But anyway, Ben has never been the bottleneck, voting has been the
> bottleneck. So I think it makes sense for Max to start marshalling
> votes even before Ben has publically committed to doing the RM work
> for a given release.
Based on the last 1.1.2/1.1.3 release, there was a discussion on-list about
how to clean the release process up: namely, subjecting a release to review on
dev@svn with a ~48 hour window before making the release public on tigris.org
(this would have prevented the brown paper bag bug which caused 1.1.3), use of
GPG signatures to 'vote' on a release (so we can track who has voted), etc.
One thing I guess I'll need to know is what timeframe Max was thinking of for
a 1.1.4? In about two or three weeks? Sooner? That would help me plan my
schedule a little bit better. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Volunteering to be RM for 1.1.4 was Re: Backport voters required!
Posted by Ben Reser <be...@reser.org>.
On Sat, Feb 19, 2005 at 10:26:57PM -0800, Justin Erenkrantz wrote:
> Partially correct. Unless Max wants to be the RM (which is really why I
> asked) or Ben has an issue with it (I'm going to venture not, but he can speak
> up if he does), I'd like to volunteer to be RM for 1.1.4 given that the items
> in STATUS are relatively minor. So, I think a 1.1.4 release may be a good
> time to try to review and clean up some of our release procedures.
Fine by me...
--
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: Volunteering to be RM for 1.1.4 was Re: Backport voters required!
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> On Sat, Feb 19, 2005 at 05:56:36PM -0600, kfogel@collab.net wrote:
>> "Max Bowsher" <ma...@ukf.net> writes:
>>> Why do you ask?
>>>
>>> Ben Reser is our current RM, and has been since 1.0.2 - I haven't
>>> noticed him say anything about wanting to step down?
>>
>> I think Justin just meant "Are you counting on Ben to do this release
>> at a particular time?"
>
> Partially correct. Unless Max wants to be the RM (which is really why I
> asked) or Ben has an issue with it (I'm going to venture not, but he can
> speak
> up if he does), I'd like to volunteer to be RM for 1.1.4 given that the
> items
> in STATUS are relatively minor. So, I think a 1.1.4 release may be a good
> time to try to review and clean up some of our release procedures.
>
> As I have previously stated, I think it'd be good for us to try to get
> more
> people knowledgable about the role of RM. Our goal should be that people
> who
> want to see a release out should be able to put the release out without
> relying upon anyone else - moving away from a 'dedicated' RM role. Hence,
> there should be enough documentation available about the process and
> involved
> steps so that any full committer can create the release.
>
> The initial stabs at this documentation are in notes/releases.txt, but
> without
> any other RMs having done a release recently, we need to test the
> procedures.
> I think the best strategy is to tag an RM who hasn't done it before. =)
>
> /me foolishly raises hand
I've no objections - go for it! :-)
>> But anyway, Ben has never been the bottleneck, voting has been the
>> bottleneck. So I think it makes sense for Max to start marshalling
>> votes even before Ben has publically committed to doing the RM work
>> for a given release.
>
> Based on the last 1.1.2/1.1.3 release, there was a discussion on-list
> about
> how to clean the release process up: namely, subjecting a release to
> review on
> dev@svn with a ~48 hour window before making the release public on
> tigris.org
> (this would have prevented the brown paper bag bug which caused 1.1.3),
> use of
> GPG signatures to 'vote' on a release (so we can track who has voted),
> etc.
Hmm, guess this means I ought to actually start using my GPG key.
> One thing I guess I'll need to know is what timeframe Max was thinking of
> for
> a 1.1.4? In about two or three weeks? Sooner? That would help me plan
> my
> schedule a little bit better. -- justin
In about three weeks would be ideal, I think.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Volunteering to be RM for 1.1.4 was Re: Backport voters required!
Posted by Michael Price <ec...@gmail.com>.
On Mon, 21 Feb 2005 10:10:15 -0800 (PST), Justin Erenkrantz
<ju...@erenkrantz.com> wrote:
> Based on my reading of notes/releases.txt, there are a number of implicit
> things that must be understood in order to do a release. That document
> isn't enough on its own for anyone to do a release that we'd consider
> 'good'.
It's been a while since I did any of the releases so take my comments
with a grain of salt. I would counter that we shouldn't have someone
unfamiliar with subversion making a release. Your points about
deficiencies in the existing documents are valid but anyone you would
actually _want_ making a subversion release would have the implicit
knowledge you rightly point out is necessary.
Of course, the documents should still be updated for completeness.
[snip good points]
> These are only some of the things I intend to address. And, by having
> someone go through the release process who hasn't done it before (or
> recently) with an eye on getting these docs right, I think we'll end up
> with a far better document that'll be closer to our ideal. -- justin
That's the same thing I heard before I did my first release. Good luck
making the process better :)
Michael Price
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Volunteering to be RM for 1.1.4 was Re: Backport voters required!
Posted by Ben Reser <be...@reser.org>.
On Mon, Feb 21, 2005 at 10:10:15AM -0800, Justin Erenkrantz wrote:
> Based on my reading of notes/releases.txt, there are a number of implicit
> things that must be understood in order to do a release. That document
> isn't enough on its own for anyone to do a release that we'd consider
> 'good'.
>
> It doesn't describe how to create a release from a branch - only from
> trunk. Nor, does it describe our current policy for summarizing CHANGES
> entries as we now want the RM to do it.
Sure it does, it tells you to skip to step 3. As far as CHANGES, I've
only ever written it once. Every other time, sussman has done it. I'm
not sure how'd you document it anyway. It's straightforward and
obvious. But for what it's worth is included in the steps.
> Where does it say what are the 'good' versions of autoconf or libtool?
> Currently, dist.sh or buildcheck.sh don't enforce that - and that's
> badness, IMHO.
For reference:
libtool-1.4.3
autoconf-2.57 (but it's not required to be these version actually, see
below).
The big requirement here is that these not be hacked on versions by the
distributions. They have to be clean copies from the GNU tarballs. 90%
of the problems we've had have been hacks from distributions to "fix"
things for their own distribution but that don't work on other
platforms.
The libtool requirement is the most restrictive one. 1.4.3 works on the
most platforms without the issues we've had with 1.5.x. 1.5.x fixes the
issues we have with other 1.4.x releases, but introduces the need for a
C++ compiler which we didn't want. Supposedly this has been fixed but
we had agreed to leave well enough alone until 1.2 when we were going to
try 1.5.x on the betas.
That said there isn't a good way to check that people have a good
libtool or autoconf from our scripts. Most of the hacks that break
things are silent changes that we can't detect.
The reason I haven't documented this was because my intention was to
make my chroot environment available that I use to do the builds. I
just haven't gotten around to publishing it. Though it's not going to
really help you since you apparently don't have access to linux i586.
Once we remove the libtool issue at 1.2.x then we'll be down to "Don't
use distribution hacked versions" Which isn't something we can automate
around. Documenting what is needed is good and should be done.
> It also doesn't describe how to create the .zip CRLF source files - which
> is something we've been intending to do since 1.1 came out - although
> dist.sh seems to have the required bits to do this, but it isn't
> documented.
A lot of the dist.sh options I use aren't documented in releases.txt but
90% of them aren't actually needed to cut a release. They exist to
streamline my release process. Someone cutting a release for the first
time isn't probably going to find them that useful. But it's true that
I've never put the zip instructions in the releases.txt file, I suppose
I should. Mostly because it's just a matter of rerunning the same
dist.sh command with -zip and with the Windows APR, APR-util and
instead of the Unix versions and adding in APR-iconv.
If anyone is curious this exactly what I used to build 1.1.3:
./dist.sh -v 1.1.3 -r 12730 -pr branches/1.1.x \
-neon ~/in-tree-libraries/neon-0.24.7 \
-apr ~/in-tree-libraries/httpd-2.0.52/srclib/apr \
-apru ~/in-tree-libraries/httpd-2.0.52/srclib/apr-util/
./dist.sh -v 1.1.3 -r 12730 -pr branches/1.1.x \
-neon ~/in-tree-libraries/neon-0.24.7 \
-apr ~/win32-in-tree-libraries/httpd-2.0.52/srclib/apr \
-apru ~/win32-in-tree-libraries/httpd-2.0.52/srclib/apr-util/ \
-apri ~/win32-in-tree-libraries/httpd-2.0.52/srclib/apr-iconv/ -zip
Rather than copying the various libs into the right place with the right
name for dist.sh to just find them I've added options for me just to
tell it where they are. So I can keep reusing the same files over and
over.
I use the .zip packaging of Apache as the source for the APR files
needed for our .zip packaging and the .tar.gz packaging of Apache as the
source for the Unix files. Neon has no separate packaging so I use the
same files for both...
However, if you're only cutting a single release the old way of just
putting the folders in the wc works just fine. Incidentally, the
instructions tell you to use a wc, but you really don't need it anymore,
you could just download dist.sh with svn cat and cut it without a wc.
> These are only some of the things I intend to address. And, by having
> someone go through the release process who hasn't done it before (or
> recently) with an eye on getting these docs right, I think we'll end up
> with a far better document that'll be closer to our ideal.
Well really I don't think you have to cut a release to address these.
If you really want to I don't really care if you do. Nobody has stopped
anyone from taking the time to try and cut a release and then adjusting
or asking that the documentation be adjusted based on that. These
things don't have to be done by the RM. Other people have made some
adjustments to the instructions and dist.sh in the past.
So what are the other things you intend to address? Let's just talk
about them and address them. The things you've mentioned above are
oversights in the releases.txt documentation that I will be more than
happy to fix.
--
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: Volunteering to be RM for 1.1.4 was Re: Backport voters required!
Posted by Ben Reser <be...@reser.org>.
On Mon, Feb 21, 2005 at 10:10:15AM -0800, Justin Erenkrantz wrote:
> Where does it say what are the 'good' versions of autoconf or libtool?
Fixed in r13122.
> It also doesn't describe how to create the .zip CRLF source files - which
> is something we've been intending to do since 1.1 came out - although
> dist.sh seems to have the required bits to do this, but it isn't
> documented.
Fixed in r13122.
--
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: Volunteering to be RM for 1.1.4 was Re: Backport voters
required!
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
Ben wrote:
> On Feb 20, 2005, at 12:26 AM, Justin Erenkrantz wrote:
>>
>> The initial stabs at this documentation are in notes/releases.txt, but
>> without
>> any other RMs having done a release recently, we need to test the
>> procedures.
>>
>
> Ahem... notes/releases.txt isn't a rough outline or "initial stab".
> It's gone through dozens and dozens of rewrites over N years. It's the
> result of continuous refinement at the hands of different RMs. And Ben
> Reser has refined that document more than anyone else. Take a look at
> it... it's well-written enough that really any committer can follow the
> procedures. And indeed -- excluding 'make check' -- it takes Ben less
> than 30 minutes to do it.
Based on my reading of notes/releases.txt, there are a number of implicit
things that must be understood in order to do a release. That document
isn't enough on its own for anyone to do a release that we'd consider
'good'.
It doesn't describe how to create a release from a branch - only from
trunk. Nor, does it describe our current policy for summarizing CHANGES
entries as we now want the RM to do it.
Where does it say what are the 'good' versions of autoconf or libtool?
Currently, dist.sh or buildcheck.sh don't enforce that - and that's
badness, IMHO.
It also doesn't describe how to create the .zip CRLF source files - which
is something we've been intending to do since 1.1 came out - although
dist.sh seems to have the required bits to do this, but it isn't
documented.
These are only some of the things I intend to address. And, by having
someone go through the release process who hasn't done it before (or
recently) with an eye on getting these docs right, I think we'll end up
with a far better document that'll be closer to our ideal. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Volunteering to be RM for 1.1.4 was Re: Backport voters required!
Posted by Ben Collins-Sussman <su...@collab.net>.
On Feb 20, 2005, at 12:26 AM, Justin Erenkrantz wrote:
>
> The initial stabs at this documentation are in notes/releases.txt, but
> without
> any other RMs having done a release recently, we need to test the
> procedures.
>
Ahem... notes/releases.txt isn't a rough outline or "initial stab".
It's gone through dozens and dozens of rewrites over N years. It's the
result of continuous refinement at the hands of different RMs. And Ben
Reser has refined that document more than anyone else. Take a look at
it... it's well-written enough that really any committer can follow the
procedures. And indeed -- excluding 'make check' -- it takes Ben less
than 30 minutes to do it.
I think what you're talking about, Justin, is the possiblilty of adding
new policies to an already-streamlined set of policies... which is fine
thing.
IIRC, the result of the 1.1.2 "brown paper bag" release was to formally
require that we at least compile all bindings in the RC tarball. While
Ben was typically doing that anyway, it was never formally described in
the releases.txt file. But since then, we've decided that we want to
add some more procedures, emulating httpd's "three +1" signatures/votes
on any RC tarball.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org