Thread: Let's create a release team
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/
"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
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, Pennsylvania19073
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/
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
"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
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/
"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
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/
Dan Langille writes:> On 10 Dec 2002 at 9:34, Tom Lane wrote:> > Anyone running cvsup would have a complete copy of the sourceCVS, I> > believe. It would be more troubling to reconstruct the mailing list> > archives; I'm not sure that thoseare mirrored anywhere> Do you mean the repository, or the source. The repository is the ,v > files.... The sourceisn'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.
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.
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
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, Pennsylvania19073