You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/07/01 16:17:56 UTC
New release manager needed.
Would anyone like to take over as release manager?
Michael Price has decided to step down (see his mail below). As
everyone knows, he set a high standard; I only hope it doesn't deter
others from trying to wear his shoes...
Michael, thanks for doing such a terrific job! At first I wasn't sure
how having a separate release manager would work out. But now I feel
like saying what the waiter said to the man with a fly in his soup:
"Shhh, don't tell, or soon everyone will want one!"
Bravo, sir.
-Karl
Michael Price <mp...@atl.lmco.com> writes:
> Hey Karl,
>
> Sorry for the weekend of silence -- dropped off of the face of the Net
> again.
>
> I wanted to drop you a line letting you know that I think I need to
> step down as the release manager for subversion. The only reason is a
> big one: I don't have the time necessary to do the job properly. My
> life has always been busy with two kids and work and it looks like its
> just going to get busier. I have to prioritize and my family and job
> are taking the top two spots (and most of my time).
>
> I'm sure there are plenty of other people who have the desire and time
> to fill the role and I'd be glad to help them get started and answer
> questions. I'll continue to be a big subversion fan and silenty cheer
> every time I convert a cvs repo to subversion.
>
> If you still need help with the latest release then let me know. I'm
> probably too busy to update the CHANGES file but I could do a last
> round of testing and roll the actual tarball. Let me know what you
> think.
>
> I don't consider this email to be private so you can feel free to
> disseminate it as you see fit.
>
> Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by mark benedetto king <mb...@lowlatency.com>.
On Wed, Jul 02, 2003 at 01:16:45PM -0400, pll@lanminds.com wrote:
>
> In release.txt it says:
>
> 1. Tweak trunk/CHANGES to contain all the latest changes
>
> How do I know what all the latest changes are? Is that stuff I
> need to gather from an svn diff of the last release or comb through
> the mail archives, etc.?
>
It's essentially a distilled-for-popular-consumption version
of "svn log -r X:Y http://svn.collab.net/repos/svn/trunk", where
X is the rev of the old release and Y is the rev of the new one.
If you have a question about whether or not a particular change
is user-visible or developer-visible, just ask on the list, or #svn.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by "Bruce A. Mah" <bm...@packetdesign.com>.
If memory serves me right, Ben Collins-Sussman wrote:
> pll@lanminds.com writes:
>
> > In release.txt it says:
> >
> > 1. Tweak trunk/CHANGES to contain all the latest changes
> >
> > How do I know what all the latest changes are? Is that stuff I
> > need to gather from an svn diff of the last release or comb through
> > the mail archives, etc.?
>
> Look and see at what point the last release branch was copied from
> trunk. Assume it branched off of /trunk in revision 6000. Then you
> would run
>
> 'svn log -v -r6000:HEAD > logfile'
>
> Then you read 'logfile' very carefully, and try to write a consise
> summary of important events.
I try to do updates to FreeBSD's equivalent of trunk/CHANGES on an
ongoing basis (by reading the commit logs), rather than do everything
right before a release. subversion's release cycle is fairly short, so
it might not make that much of a difference, but on FreeBSD the releases
are so far apart (small number of months) that there's the potential for
a lot of stuff to build up in between.
(A cool thing about subversion is, of course, the fact that you *can*
execute the command line above and get some useful output.)
> > Just curious about what I'm supposed to be putting in there.
>
> This is the toughest "human" part of being a release manager. The
> CHANGES file has a very specific, very terse format. It does not list
> every single change. It only lists the "most important" ones, which
> is a subjective call. How do you make the subjective call? Read
> through the earlier CHANGES entries and try to get a feel for the
> "filter" that people were using, and then try to preserve that filter
> when you start reading commit-logs yourself. It's not an easy thing
> to do. :-)
Almost every release notes-type document will cover something like:
"Things that are critically important to a few users, important to most
people, or interesting to everybody." subversion's trunk/CHANGES file
implements this very well, IMHO.
The fact that this *is* intrinsically hard is why I try to spread the
work out. This is a heck of a good way to learn a little bit about
everything that's happening on a project.
Free advice, worth what you-all paid for it.
Thanks to everyone who's worked on the subversion releases, and good
luck to the new release engineer(s)!
Bruce.
Re: New release manager needed.
Posted by Paul L Lussier <pl...@lanminds.com>.
>>>>> On Wed, 2 Jul 2003, "Robert" == Robert Pluim wrote:
+> * poem - "Dinner is served" by cmpilato (r6313)
Robert> This one was fun, but doesn't really tell me anything about
Robert> the change.
Neither did the log message, I just thought the poem was rather
amusing, and those who don't follow every commit might get a kick out
of it.
Though I really didn't intend for this to be in the final CHANGES
file, it was more or less just see who on the list actually read what
I wrote ;)
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> I think it's a bit extreme not to mention cvs2svn at all, considering
> they're about half the commits in the last two weeks! Maybe just a
> single bullet point
>
> * cvs2svn: lots of work toward branch support, not yet activated
>
> It's certainly a developer-visible change.
Yes, but is it important enough to use up space in CHANGES? Hardly
anyone else works on cvs2svn. Developer-visible changes in the core
libraries should be mentioned because to get anything done in
Subversion, a developer needs to use those libraries... not so with
cvs2svn.
Paul's call, of course. Just IMHO the cvs2svn announcements can wait
till the next release, when they're visible to everyone.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Ben Collins-Sussman <su...@collab.net>.
kfogel@collab.net writes:
> Robert Pluim <rp...@bigfoot.com> writes:
> > > * fixed - problems 2 & 3 mentioned in (r6365)
> >
> > I had no idea what the heck this one was until I read the log message,
> > perhaps an indication that it was about cvs2svn?
>
> It's probably better to summarize the descriptive text from that log
> message, not summarize the references. But in any case, don't include
> any cvs2svn stuff in CHANGES, since I haven't "flipped the switch" yet
> on most of them.
I think it's a bit extreme not to mention cvs2svn at all, considering
they're about half the commits in the last two weeks! Maybe just a
single bullet point
* cvs2svn: lots of work toward branch support, not yet activated
It's certainly a developer-visible change.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by kf...@collab.net.
Robert Pluim <rp...@bigfoot.com> writes:
> > * fixed - problems 2 & 3 mentioned in (r6365)
>
> I had no idea what the heck this one was until I read the log message,
> perhaps an indication that it was about cvs2svn?
It's probably better to summarize the descriptive text from that log
message, not summarize the references. But in any case, don't include
any cvs2svn stuff in CHANGES, since I haven't "flipped the switch" yet
on most of them.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Robert Pluim <rp...@bigfoot.com>.
pll@lanminds.com writes:
>
> Okay, here's my first stab at it. I've got my asbestos undies on :)
>
Hey, you're just starting. The asbestos undies are for 0.26 ;-)
> User-visible changes:
> * fixed - memory bug seen with svn switch
> Developer-visible changes:
> * fixed - sloppy pool usage in various places (r6302)
Both of those would be 'user-visible' in my mind, since they were
resolutions to excessive usage of memory, and the second one isn't
really a major api change.
> * fixed - problems 2 & 3 mentioned in (r6365)
I had no idea what the heck this one was until I read the log message,
perhaps an indication that it was about cvs2svn?
> * fixed - svn switch related memory bug (r6295)
This one is under both user- and developer- (and it's r6296)
> * poem - "Dinner is served" by cmpilato (r6313)
This one was fun, but doesn't really tell me anything about the
change.
> * new - XFail test (r6333)
Which test was this (I admit the log message is pretty terse as well)?
Apart from these minor niggles, I like the {changed,fixed,...}
headings.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Ben Collins-Sussman <su...@collab.net>.
pll@lanminds.com writes:
> >>>>> On 2 Jul 2003, "Ben" == Ben Collins-Sussman wrote:
>
> +> Okay, I'll take a stab at it. Would it be helpful if I sent my
> +> proposed CHANGES additions to the list for comment?
>
> Ben> Sure, that'd be great.
>
> Okay, here's my first stab at it. I've got my asbestos undies on :)
It's good that you can summarize each change in one line. Nice job!
But I think you need to clamp down your filter just a wee bit. It
looks like you documented *every* change in the last two weeks; as a
result, the list is longer than the 0.24 list, which was a six-week
development period! Let me constructively nitpick. :-)
It looks like you tried to create a bullet for each revision... or
something close to that. Way too much! Your job is to *condense*
this stuff... 8 different revisions may all be related to
accomplishing a single task. Make them into a single bullet.
A general note: there's no need to *force* a prefix to the front of
each line. When you forcibly put "fixed -" before everything, it
sometimes makes the idea harder to understand. It's a nice
convention, but not a permanent rule. Don't be constrained by it.
> User-visible changes:
Start with the most important stuff first... the stuff most incredibly
obvious to svn users.
For example, I'd imagine that completely new commands ('svnadmin
archive') or total syntax changes ('svn import') are candidates for
the top of the list.
> * changed - cvs2svn usage() Excessively long output.
As another poster said, "not interesting to the general public". :-)
> * fixed - copyright messages
Huh? Either not interesting, or not explanatory enough.
> * fixed - memory bug seen with svn switch
* fixed - 'svn switch' memory bug
> * fixed - parent-into-child copies provided they are not WC-to-WC. (r6348)
The "fixed -" prefix obfuscates the description. Try something
simpler like "allow parent-into-child copies, provided it's not wc->wc".
The word "allow" is the key idea here, not "fixed".
> * fixed - svn mkdir URL URL/subdir no longer dumps core (r6338)
* fixed - 'svn mkdir' coredump.
No need to describe the exact recipe, unless it's really interesting.
Coredumps, in general, tend to be tiny little booboos with tiny
patches, not large redesigns that affect people.
> * removed - bogus python package
Huh? Why was it bogus? Too little information.
> Developer-visible changes:
> * changed - paths array is now a constant (r6301)
> * changed - renamed strintest to string-test for consistency (r6322)
> * fixed - line wrapping now within 80-columns (r6363)
These things aren't very interesting, even to developers. Screen them out.
> * fixed - copied subtree problem (r6365)
> * fixed - problems 2 & 3 mentioned in (r6365)
> * new - code to emit branch creations to dumpfile (r6336)
> * fixed - branch path creation (r6358)
Huh? I read this and have no idea what you're talking about. I
shouldn't have to go look up revision logs to understand; a quick
glance should at least give a vague overview. You fail to point out
that this is *all* about the cvs2svn repository converter, not svn
itself. That's the "big idea" here. In fact, I'd probably lump all
of the cvs2svn.py commits into one big bullet point, or a bullet point
of the form
* many cvs2svn.py changes:
- work on branches
- blah
- blah
Notice that we have subsections in earlier CHANGES entries.
Indentation/sectioning is very useful for someone just "glancing" over
the list. Many folks will just want to skip over a list of cvs2svn
changes.
> * new - XFail test (r6333)
Test for *what*? Don't make me look up the revision.
> * updated - vcproj generator now works (r6316)
> * changed - code common to dsp & vcproj refactored into gen_win.py (r6328)
> * changed - make swig's generated .c files dependent on headers in .i files
> * fixed - SWIG bindings for Win32 (r6304)
> * new - .vcproj files for svn_config project and APR
Another "category" here. A zillion changes were made to the win32
build system, both for vcproj creation and swig-binding compilation.
Make an indentation, or even better, try to smoosh them together into
fewer bullets. There's no need to document each commit.
> * poem - "Dinner is served" by cmpilato (r6313)
Funny. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by pl...@lanminds.com.
>>>>> On 2 Jul 2003, "Ben" == Ben Collins-Sussman wrote:
+> Okay, I'll take a stab at it. Would it be helpful if I sent my
+> proposed CHANGES additions to the list for comment?
Ben> Sure, that'd be great.
Okay, here's my first stab at it. I've got my asbestos undies on :)
Version 0.25.0 (released 05 July 2003, revision 6387, branches/release-0.25.0)
User-visible changes:
* changed - cvs2svn usage() Excessively long output.
* changed - python bindings now in -tools
* changed: syntax 'svn import [PATH] URL'. (r6288)
* fixed - Run external diff commands using PATH (r6373)
* fixed - compile problems on FreeBSD
* fixed - copyright messages
* fixed - keyword expansion buglet (r6324)
* fixed - memory bug seen with svn switch
* fixed - parent-into-child copies provided they are not WC-to-WC. (r6348)
* fixed - svn mkdir URL URL/subdir no longer dumps core (r6338)
* new - added --force option for svn export (r1296)
* new - added --force-log command-line client option.
* new - svn archive command (r6310)
* removed - bogus python package
Developer-visible changes:
* changed - code common to dsp & vcproj refactored into gen_win.py (r6328)
* changed - mailer.py now uses svn_repos_replay()
* changed - make swig's generated .c files dependent on headers in .i files
* changed - paths array is now a constant (r6301)
* changed - renamed strintest to string-test for consistency (r6322)
* fixed - SEGFAULTers in SWIG bindings
* fixed - SWIG bindings for Win32 (r6304)
* fixed - branch path creation (r6358)
* fixed - copied subtree problem (r6365)
* fixed - line wrapping now within 80-columns (r6363)
* fixed - mod_dav_svn's autoversioning failure on PUT
* fixed - potential segfault in the 'REPORT vcc' backward-compatibility code.
* fixed - problems 2 & 3 mentioned in (r6365)
* fixed - sloppy pool usage in various places (r6302)
* fixed - svn switch related memory bug (r6295)
* new - .vcproj files for svn_config project and APR
* new - XFail test (r6333)
* new - code to emit branch creations to dumpfile (r6336)
* poem - "Dinner is served" by cmpilato (r6313)
* updated - vcproj generator now works (r6316)
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Paul L Lussier <pl...@lanminds.com>.
In a message dated: 02 Jul 2003 13:32:22 CDT
Ben Collins-Sussman said:
>Yup. Or run 'svn log -v' on the 0.24.2 tag URL, and *see* the copy.
Ahhhh, hey, that's rather neat ;)
>> Okay, I'll take a stab at it. Would it be helpful if I sent my
>> proposed CHANGES additions to the list for comment?
>
>Sure, that'd be great.
Great. Working on that now, will send when complete (I have until
Sat. right ?)
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Ben Collins-Sussman <su...@collab.net>.
Paul L Lussier <pl...@lanminds.com> writes:
> Errr, how do I determine when it branched? Is it as simple as as
> looking at the CHANGES file and reading:
>
> Version 0.24.2 (released 18 June 2003, revision 6284, branches/release-0.24.2)
> :)
Yup. Or run 'svn log -v' on the 0.24.2 tag URL, and *see* the copy.
> Okay, I'll take a stab at it. Would it be helpful if I sent my
> proposed CHANGES additions to the list for comment?
Sure, that'd be great.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Paul L Lussier <pl...@lanminds.com>.
>>>>> On 2 Jul 2003, "Ben" == Ben Collins-Sussman wrote:
Ben> Look and see at what point the last release branch was copied
Ben> from trunk. Assume it branched off of /trunk in revision 6000.
Ben> Then you would run
Ben> 'svn log -v -r6000:HEAD > logfile'
Errr, how do I determine when it branched? Is it as simple as as
looking at the CHANGES file and reading:
Version 0.24.2 (released 18 June 2003, revision 6284, branches/release-0.24.2)
:)
+> Just curious about what I'm supposed to be putting in there.
Ben> This is the toughest "human" part of being a release manager.
Ben> The CHANGES file has a very specific, very terse format.
Hmmm, I think I can be terse :)
Ben> It's not an easy thing to do. :-)
Okay, I'll take a stab at it. Would it be helpful if I sent my
proposed CHANGES additions to the list for comment?
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Ben Collins-Sussman <su...@collab.net>.
pll@lanminds.com writes:
> In release.txt it says:
>
> 1. Tweak trunk/CHANGES to contain all the latest changes
>
> How do I know what all the latest changes are? Is that stuff I
> need to gather from an svn diff of the last release or comb through
> the mail archives, etc.?
Look and see at what point the last release branch was copied from
trunk. Assume it branched off of /trunk in revision 6000. Then you
would run
'svn log -v -r6000:HEAD > logfile'
Then you read 'logfile' very carefully, and try to write a consise
summary of important events.
> Just curious about what I'm supposed to be putting in there.
This is the toughest "human" part of being a release manager. The
CHANGES file has a very specific, very terse format. It does not list
every single change. It only lists the "most important" ones, which
is a subjective call. How do you make the subjective call? Read
through the earlier CHANGES entries and try to get a feel for the
"filter" that people were using, and then try to preserve that filter
when you start reading commit-logs yourself. It's not an easy thing
to do. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by pl...@lanminds.com.
In release.txt it says:
1. Tweak trunk/CHANGES to contain all the latest changes
How do I know what all the latest changes are? Is that stuff I
need to gather from an svn diff of the last release or comb through
the mail archives, etc.?
Just curious about what I'm supposed to be putting in there.
Thanks,
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by kf...@collab.net.
pll@lanminds.com writes:
> kfogel> ut that's silly, because even if more people do respond, it
> kfogel> still boils down to a random call, no less random than the
> kfogel> timing of people's email checking, right?
>
> Yup, but it's your call. If you want to wait, that's fine, if not,
> that's fine too. I'm not going anywhere :)
No need to wait -- see Greg Stein's and Sander Striker's mails about
+1 to everyone who wants to help :-).
> Will do. Ahm, should the password I send you be different than my
> existing tigris password?
Only if you want it to be.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by pl...@lanminds.com.
>>>>> On 1 Jul 2003, "kfogel" == kfogel@collab.net wrote:
pll> (unless I can find another job in the near future, I'm going to have
pll> (at the very least) the summer off :(
kfogel> Mmph, sorry to hear that :-(. Hope things improve soon...
Me too. Though I'm not too worried about it. And I'm looking
forward to some time off to play with my daughter (who turns 1
tomorrow :)
kfogel> I was thinking it would be nice to wait a day to see who
kfogel> else responds, so it wouldn't just be about who happened to
kfogel> read their mail first.
That's fine.
kfogel> ut that's silly, because even if more people do respond, it
kfogel> still boils down to a random call, no less random than the
kfogel> timing of people's email checking, right?
Yup, but it's your call. If you want to wait, that's fine, if not,
that's fine too. I'm not going anywhere :)
kfogel> So take a look at notes/releases.txt, and post if you have
kfogel> any questions. If it all looks good, send me your tigris
kfogel> username and a password, and we'll set you up to do 0.25.
Will do. Ahm, should the password I send you be different than my
existing tigris password?
kfogel> (But if you think that you'd have to give up release
kfogel> management when you find a job, then probably we should wait
kfogel> for someone else. It's better if it can be a stable part of
kfogel> someone's routine, rather than dependent on unsustainable
kfogel> amounts of free time! :-) Your call.)
Well, there's no telling until I have a new job. And I'm here for at
least the remainder of July, so, it won't be a burden for at least 5
weeks, more likely much longer.
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> I see no reason that we couldn't have stints of release managers, or even
> doing a round robin. That will only help to clarify the process for all
> involved.
>
> Ideally, a release is a mechanical process, with very little "human
> experience" built in. The more mechanical it is, then the less room for
> error, and releases should be about repeatability. So if we aren't relying
> on human experience, then there is no purpose served by having somebody
> "hold the position" for any extended period of time.
>
> +1 to Paul. And +1 to the next volunteer.
Excellent point! +1 to the above.
All interested in release management: see notes/releases.txt.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: New release manager needed.
Posted by Sander Striker <st...@apache.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Tuesday, July 01, 2003 8:34 PM
> On Tue, Jul 01, 2003 at 12:16:50PM -0500, kfogel@collab.net wrote:
> >...
> > (But if you think that you'd have to give up release management when
> > you find a job, then probably we should wait for someone else. It's
> > better if it can be a stable part of someone's routine, rather than
> > dependent on unsustainable amounts of free time! :-) Your call.)
>
> I see no reason that we couldn't have stints of release managers, or even
> doing a round robin. That will only help to clarify the process for all
> involved.
True. This is kind of how it works with httpd aswell. There is no
one release manager.
> Ideally, a release is a mechanical process, with very little "human
> experience" built in. The more mechanical it is, then the less room for
> error, and releases should be about repeatability. So if we aren't relying
> on human experience, then there is no purpose served by having somebody
> "hold the position" for any extended period of time.
+1 to that. However there is a human part in this process which is the
CHANGES maintenance. This is probably the most time consuming part of
the release process.
> +1 to Paul. And +1 to the next volunteer.
Ditto.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 01, 2003 at 12:16:50PM -0500, kfogel@collab.net wrote:
>...
> (But if you think that you'd have to give up release management when
> you find a job, then probably we should wait for someone else. It's
> better if it can be a stable part of someone's routine, rather than
> dependent on unsustainable amounts of free time! :-) Your call.)
I see no reason that we couldn't have stints of release managers, or even
doing a round robin. That will only help to clarify the process for all
involved.
Ideally, a release is a mechanical process, with very little "human
experience" built in. The more mechanical it is, then the less room for
error, and releases should be about repeatability. So if we aren't relying
on human experience, then there is no purpose served by having somebody
"hold the position" for any extended period of time.
+1 to Paul. And +1 to the next volunteer.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by kf...@collab.net.
Paul L Lussier <pl...@lanminds.com> writes:
> I'll give it a shot provided there are instructions I can follow
> until I come up to speed. Unfortunately, it appears that I'm about
> to have too much free time on my hands (unless I can find another job
> in the near future, I'm going to have (at the very least) the summer
> off :(
Mmph, sorry to hear that :-(. Hope things improve soon...
I was thinking it would be nice to wait a day to see who else
responds, so it wouldn't just be about who happened to read their mail
first. But that's silly, because even if more people do respond, it
still boils down to a random call, no less random than the timing of
people's email checking, right?
So take a look at notes/releases.txt, and post if you have any
questions. If it all looks good, send me your tigris username and a
password, and we'll set you up to do 0.25.
(But if you think that you'd have to give up release management when
you find a job, then probably we should wait for someone else. It's
better if it can be a stable part of someone's routine, rather than
dependent on unsustainable amounts of free time! :-) Your call.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: New release manager needed.
Posted by Paul L Lussier <pl...@lanminds.com>.
In a message dated: 01 Jul 2003 11:17:56 CDT
kfogel@collab.net said:
>Would anyone like to take over as release manager?
>
>Michael Price has decided to step down (see his mail below). As
>everyone knows, he set a high standard; I only hope it doesn't deter
>others from trying to wear his shoes...
I'll give it a shot provided there are instructions I can follow
until I come up to speed. Unfortunately, it appears that I'm about
to have too much free time on my hands (unless I can find another job
in the near future, I'm going to have (at the very least) the summer off :(
--
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853 E808 BB07 9239 53F1 28EE
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org