Thread

  1. Let's create a release team

    Dan Langille <dan@langille.org> — 2002-12-08T03:03:48Z

    Hi folks,
    
    Let's create a release team.  This strategy is one well established 
    in other projects and in industry.  For lack of a better starting 
    reference, let me suggest http://www.freebsd.org/releng/charter.html 
    as a starting point for consideration.  See also 
    http://www.freebsd.org/releng/index.html.  
    
    This will also lighten the load on the core team allowing them to 
    focus on development and such.  
    
    cheers
    
    
    
    -- 
    Dan Langille : http://www.langille.org/
    
    
    
  2. Re: Let's create a release team

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-09T16:38:47Z

    "Dan Langille" <dan@langille.org> writes:
    > Let's create a release team.  This strategy is one well established 
    > in other projects and in industry.  For lack of a better starting 
    > reference, let me suggest http://www.freebsd.org/releng/charter.html 
    > as a starting point for consideration.  See also 
    > http://www.freebsd.org/releng/index.html.  
    
    > This will also lighten the load on the core team allowing them to 
    > focus on development and such.  
    
    I don't really see any value-added here.  The core committee's only
    routinely-exercised function is to organize releases; separating that
    out would leave core with nothing to do.  Also, to the extent that
    core has any real or perceived authority in the project, I think it
    comes from having control of the release process --- there's surely
    no other reason for people to defer to the core team as a group (as
    opposed to whatever respect might be accorded to individual people
    as a result of their individual contributions).  So ISTM such a
    reorganization would leave the core committee as a figurehead and make
    the release team into the effective new core.
    
    			regards, tom lane
    
    
  3. Re: Let's create a release team

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-12-09T21:28:12Z

    Tom Lane wrote:
    > as a result of their individual contributions).  So ISTM such a
    > reorganization would leave the core committee as a figurehead and make
    > the release team into the effective new core.
    
    I thought we were already only figureheads?  ;-)
    
    -- 
      Bruce Momjian                        |  http://candle.pha.pa.us
      pgman@candle.pha.pa.us               |  (610) 359-1001
      +  If your life is a hard drive,     |  13 Roberts Road
      +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
    
    
  4. Re: Let's create a release team

    Dan Langille <dan@langille.org> — 2002-12-10T04:51:07Z

    On 9 Dec 2002 at 11:38, Tom Lane wrote:
    
    > "Dan Langille" <dan@langille.org> writes:
    > > Let's create a release team.  This strategy is one well established
    > > in other projects and in industry.  For lack of a better starting
    > > reference, let me suggest http://www.freebsd.org/releng/charter.html
    > > as a starting point for consideration.  See also
    > > http://www.freebsd.org/releng/index.html.  
    > 
    > > This will also lighten the load on the core team allowing them to
    > > focus on development and such.  
    > 
    > I don't really see any value-added here.  The core committee's only
    > routinely-exercised function is to organize releases; separating that
    > out would leave core with nothing to do.  
    
    So we already have a release team, but not titled as such.
    
    > Also, to the extent that
    > core has any real or perceived authority in the project, I think it
    > comes from having control of the release process --- there's surely no
    > other reason for people to defer to the core team as a group (as
    > opposed to whatever respect might be accorded to individual people as
    > a result of their individual contributions).
    
    Is the process documented?  Any set procedure?  Who knows how to do 
    it?
    
    > So ISTM such a
    > reorganization would leave the core committee as a figurehead and make
    > the release team into the effective new core.
    
    Is 'core' the same as 'steering'?  I couldn't find any reference to 
    "core committe" or "core team" via google.  At 
    http://developer.postgresql.org/bios.php I see the group of people 
    referred to as "Steering".  Is their function defined anywhere?
    
    If these things are not documented, they should be.  Where do I 
    start?
    -- 
    Dan Langille : http://www.langille.org/
    
    
    
  5. Re: [HACKERS] Let's create a release team

    Justin Clift <justin@postgresql.org> — 2002-12-10T05:24:13Z

    Hi Dan,
    
    It's been mentioned a few times on the Advocacy and Marketing list that 
    we should put together a process for ensuring that all the parts 
    necessary for a release occur properly and smoothly.
    
    ***********
    
    Source code
    
      - Initial packaging of the new releases' source code
    
    
    Docs
    
      - Confirm with Peter that the Docs are 100% correct in the new source 
    archive
    
    
    RPM's & SRPM's
    
      - Co-ordinate with Lamar to have these ready before the general 
    announcement?
    
    
    Press Releases for the General Public (multiple languages)
    
      - Advocacy and Marketing guys should put together a Press Release 
    intended for the General Public, and have it reviewed/confirmed by the 
    Hackers before getting it ready
    
      - Robert (?) should arrange translation of this "confirmed good" Press 
    Release into multiple languages
    
    
    Press Release for the Technically Minded (?)
    
      - Advocacy and Marketing guys (?) should put together a Press Release 
    intended for the Hackers and other Technically Minded folk.  Should 
    definitely be reviewed for accuracy by the Hackers before releasing it
    
    
    Websites
    
      - Ensure all of the required documentation mentions, links, release 
    info, etc is put in place on the website
    
    
    Mailout
    
      - Email the appropriate Press Releases to the General Public, and to 
    the Technically Minded groups
    
    
    Feedback
    
      - Find out what could have been done better, and figure out how to 
    make it so for the next one if appropriate
    
    ***********
    
    That was just what came to mind and there's probably more.  Each part 
    should probably be something that can be broken down into the necessary 
    parts so that everyone can take care of the bits they're into.  I 
    suppose it would be good to have this listed somewhere so that people 
    can make suggestions.
    
    Just whipped up a page listing these main points here, and everyone has 
    the ability to make suggestions/edits directly onto that page:
    
    http://advocacy.postgresql.org/documents/ReleaseProcess
    
    Hopefully that's helpful.
    
    :-)
    
    Regards and best wishes,
    
    Justin Clift
    
    -- 
    "My grandfather once told me that there are two kinds of people: those
    who work and those who take the credit. He told me to try to be in the
    first group; there was less competition there."
    - Indira Gandhi
    
    
    
  6. Re: Let's create a release team

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-10T05:56:22Z

    "Dan Langille" <dan@langille.org> writes:
    > Is the process documented?  Any set procedure?  Who knows how to do 
    > it?
    
    Er ... nope, nope, the core bunch ...
    
    > Is 'core' the same as 'steering'?
    
    Yes, the webpage takes some license here.  'core' is the most common
    terminology for the-usual-suspects.  I'm not sure where 'steering'
    came from, but it's the same suspects...
    
    > If these things are not documented, they should be.
    
    Most of the undocumented details of the release process are in the heads
    of Marc Fournier and Bruce Momjian.  If either of them falls off the end
    of the earth, we have worse troubles than whether we remember how to do
    a release --- for example: Marc owns, runs, and pays for the
    postgresql.org servers.  (Me, I just hack code, so I'm replaceable.)
    But if you want to try to document the process better, there are some
    details written down already (eg, src/tools/RELEASE_CHANGES) and I'm
    sure Marc and Bruce would cooperate in writing down more.
    
    			regards, tom lane
    
    
  7. Re: Let's create a release team

    Dan Langille <dan@langille.org> — 2002-12-10T14:04:49Z

    On 10 Dec 2002 at 0:56, Tom Lane wrote:
    
    > "Dan Langille" <dan@langille.org> writes:
    > > Is the process documented?  Any set procedure?  Who knows how to do
    > > it?
    > 
    > Er ... nope, nope, the core bunch ...
    
    Sounds like we need to do a brain dump then.  I just happen to have 
    some equipment left over from "The Matrix"....
    
    > > If these things are not documented, they should be.
    > 
    > Most of the undocumented details of the release process are in the
    > heads of Marc Fournier and Bruce Momjian.  If either of them falls off
    > the end of the earth, we have worse troubles than whether we remember
    > how to do a release
    
    On a project, anyone is replaceable.  And anyone might leave for any 
    number of reasons.  If they do, the affect upon the project will be 
    minimized by having the major processes documented.
    
    > --- for example: Marc owns, runs, and pays for the
    > postgresql.org servers.
    
    Is the cvs repo mirrored?
    
    > (Me, I just hack code, so I'm replaceable.)
    
    Yeah, yeah, stop being humble... ;)
    
    > But if you want to try to document the process better, there are some
    > details written down already (eg, src/tools/RELEASE_CHANGES) and I'm
    > sure Marc and Bruce would cooperate in writing down more.
    
    That's a good start. It looks like a list of things easily forgotten 
    but if forgotten, make us look bad.
    -- 
    Dan Langille : http://www.langille.org/
    
    
    
  8. Re: Let's create a release team

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-12-10T14:34:40Z

    "Dan Langille" <dan@langille.org> writes:
    >> --- for example: Marc owns, runs, and pays for the
    >> postgresql.org servers.
    
    > Is the cvs repo mirrored?
    
    Anyone running cvsup would have a complete copy of the source CVS,
    I believe.  It would be more troubling to reconstruct the mailing list
    archives; I'm not sure that those are mirrored anywhere.  (Marc?)
    
    			regards, tom lane
    
    
  9. Re: Let's create a release team

    Dan Langille <dan@langille.org> — 2002-12-10T14:37:20Z

    On 10 Dec 2002 at 9:34, Tom Lane wrote:
    
    > "Dan Langille" <dan@langille.org> writes:
    > >> --- for example: Marc owns, runs, and pays for the
    > >> postgresql.org servers.
    > 
    > > Is the cvs repo mirrored?
    > 
    > Anyone running cvsup would have a complete copy of the source CVS, I
    > believe.  It would be more troubling to reconstruct the mailing list
    > archives; I'm not sure that those are mirrored anywhere
    
    Do you mean the repository, or the source.  The repository is the ,v 
    files....  The source isn't.  Most developers would have the source, 
    but not necessarily the repo.
    -- 
    Dan Langille : http://www.langille.org/
    
    
    
  10. Re: Let's create a release team

    Lee Kindness <lkindness@csl.co.uk> — 2002-12-10T14:53:53Z

    Dan Langille writes:
     > On 10 Dec 2002 at 9:34, Tom Lane wrote:
     > > Anyone running cvsup would have a complete copy of the source CVS, I
     > > believe.  It would be more troubling to reconstruct the mailing list
     > > archives; I'm not sure that those are mirrored anywhere
     > Do you mean the repository, or the source.  The repository is the ,v 
     > files....  The source isn't.  Most developers would have the source, 
     > but not necessarily the repo.
    
    See:
    
     http://www.cvsup.org/
    
    It mirrors the repository and some of the PostgreSQL developers use
    this...
    
    Lee.
    
    
  11. Re: Let's create a release team

    Vince Vielhaber <vev@michvhf.com> — 2002-12-10T15:09:18Z

    On Tue, 10 Dec 2002, Tom Lane wrote:
    
    > "Dan Langille" <dan@langille.org> writes:
    > >> --- for example: Marc owns, runs, and pays for the
    > >> postgresql.org servers.
    >
    > > Is the cvs repo mirrored?
    >
    > Anyone running cvsup would have a complete copy of the source CVS,
    > I believe.  It would be more troubling to reconstruct the mailing list
    > archives; I'm not sure that those are mirrored anywhere.  (Marc?)
    
    Archives are mirrored at a number of sites.  There was a time when all
    web mirrors also mirrored them but that was split off about a year ago.
    
    Vince.
    -- 
     Fast, inexpensive internet service 56k and beyond!  http://www.pop4.net/
       http://www.meanstreamradio.com       http://www.unknown-artists.com
             Internet radio: It's not file sharing, it's just radio.
    
    
    
  12. Re: [HACKERS] Let's create a release team

    Lamar Owen <lamar.owen@wgcr.org> — 2002-12-10T16:06:55Z

    On Tuesday 10 December 2002 00:24, Justin Clift wrote:
    > RPM's & SRPM's
    
    >   - Co-ordinate with Lamar to have these ready before the general
    > announcement?
    
    As I am merely a volunteer in this, the availability of RPMs is directly 
    impacted by my workload.  There are several times during the year that my 
    workload goes from being just difficult to absolutely swamping.  These times 
    are typically during mid February through early March; late August through 
    late September; and November through January.
    
    See, not only am I the 'Chief Engineer' for several radio stations, but I am 
    also the 'IT Director' for WGCR, and the 'Network Administrator' for PARI.  
    The Chief Engineer duties include generator work, transmitter work, and 
    studio work -- and in winter there is alot of the generator/transmitter work 
    in the mix.  The 'IT Director' hat includes eradicating virus infections, 
    unlicensed software, etc.  This is currently my busiest area, as we try to 
    put our entire fundraising system on our intranet (backed by PostgreSQL, of 
    course).  While I say 'we,' I really should say 'I,' as I am the entirety of 
    the programming team in this project.  Fortunately I have access to an 
    interface design consultant and a good web designer.
    
    I was able to get the RPMs out when I did almost entirely due to the ice storm 
    that paralyzed the Carolinas last week -- our particular area did not get hit 
    hard with ice, but got mostly snow, which then changed to mostly rain later 
    in the day.  So we didn't lose power -- and so I was able to get them done, 
    since I was unable to travel to work.
    
    Typically, I would try to track the betas and release candidates (like I did 
    with previous releases, to varying degrees), and with the 24 hour notice we 
    all get on this list I can have a general release RPM ready.  During this 
    cycle I found myself excessively swamped by work -- so I was unable to 
    generate RPM's until the general release.  For that I apologize.  I cannot 
    guarantee that it won't happen again; but I will try to prevent its 
    recurrence.
    
    For the 7.0 cycle, during the maintenance releases, I was retained by Great 
    Bridge to produce RPMs -- that ensured that I spent time on them for that 
    cycle.
    -- 
    Lamar Owen
    WGCR Internet Radio
    1 Peter 4:11
    
    
  13. Re: Let's create a release team

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-12-10T18:58:02Z

    Dan Langille wrote:
    > > But if you want to try to document the process better, there are some
    > > details written down already (eg, src/tools/RELEASE_CHANGES) and I'm
    > > sure Marc and Bruce would cooperate in writing down more.
    > 
    > That's a good start. It looks like a list of things easily forgotten 
    > but if forgotten, make us look bad.
    
    There's not much I can add to that list.  It is everything I normally
    check.  Of course, Marc does a whole bunch of other things, but I am not
    involved in that.
    
    -- 
      Bruce Momjian                        |  http://candle.pha.pa.us
      pgman@candle.pha.pa.us               |  (610) 359-1001
      +  If your life is a hard drive,     |  13 Roberts Road
      +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073