> People aren't willing to hel pme in even a simple task of maintaining
an
> 8.3 patches status page, so why would they want to help with something
> larger. I am not going to make my job harder only to find out no one
> wants to help.
I thought about volunteering to do this, but:
1. I am a litt
Josh Berkus wrote:
> Bruce,
>
> > Get rid of gborg and let's talk.
>
> Touche'.
>
> Actually, AFAICT, the only active thing left on GBorg is WWW. If we move
> that, we can shut it down. Any objections?
>
> > Why am I having to spend hours in Syndey saying the same thing? ?Why
> > don't you g
Csaba Nagy wrote:
> On Thu, 2007-05-03 at 13:51, Bruce Momjian wrote:
> > I believe the problem is not that there isn't enough information, but
> > not enough people able to do the work. Seeking solutions in areas that
> > aren't helping was the illustration.
>
> Yes Bruce, but you're failing to
I think this is the apprach joshua tried the first time and it backfired... I
think we need a more personal approach. I'm willing to put time into this if
people want a new point man (I don't think Joshua will mind, lmk if you do)
but it will have to wait untill after pgcon.
On Thursday 03 Ma
On Wednesday 02 May 2007 01:19, Tom Lane wrote:
> Josh Berkus <[EMAIL PROTECTED]> writes:
> > Actually, that can happen with the current system. The real blocker there
> > is that some people, particularly Tom, work so fast that there's no
> > chance for a new reviewer to tackle the easy stuff. Ma
I was just getting ready to suggest such an approach. We could
email all the project admins for the reamaining projects with the
dead-line. Backup the information and tell people who to contact in
order to claim whatever information they want. Once the dead-line is
past you can simply shutdown
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Why not just send a notice out stated that Gborg will be shutdown as of June
1st ... give a finite deadline to move things over to pgfoundry ... just
because we 'shut down' the site on June 1st, it doesn't mean we are going to
wipe it all out, we c
Josh Berkus wrote:
Bruce,
Get rid of gborg and let's talk.
Touche'.
Actually, AFAICT, the only active thing left on GBorg is WWW. If we move
that, we can shut it down. Any objections?
This should be a different thread *but* to my knowledge there is more
than WWW active on Gborg. Or at
Bruce,
> Get rid of gborg and let's talk.
Touche'.
Actually, AFAICT, the only active thing left on GBorg is WWW. If we move
that, we can shut it down. Any objections?
> Why am I having to spend hours in Syndey saying the same thing? Why
> don't you guys go ahead and change things, and when
Bruce Momjian wrote:
Csaba Nagy wrote:
We have _ample_ evidence that the problem is lack of people able to
review patches, and yet there is this discussion to track patches
better. It reminds me of someone who has lost their keys in an alley,
but is looking for them in the street because the li
Bruce Momjian wrote:
Csaba Nagy wrote:
We have _ample_ evidence that the problem is lack of people able to
review patches, and yet there is this discussion to track patches
better. It reminds me of someone who has lost their keys in an alley,
but is looking for them in the street because t
Bruce Momjian wrote:
Csaba Nagy wrote:
We have _ample_ evidence that the problem is lack of people able to
review patches, and yet there is this discussion to track patches
better. It reminds me of someone who has lost their keys in an alley,
but is looking for them in the street because the li
On Thu, 2007-05-03 at 13:51, Bruce Momjian wrote:
> I believe the problem is not that there isn't enough information, but
> not enough people able to do the work. Seeking solutions in areas that
> aren't helping was the illustration.
Yes Bruce, but you're failing to see that a more structured inf
Csaba Nagy wrote:
> > We have _ample_ evidence that the problem is lack of people able to
> > review patches, and yet there is this discussion to track patches
> > better. It reminds me of someone who has lost their keys in an alley,
> > but is looking for them in the street because the light is b
> We have _ample_ evidence that the problem is lack of people able to
> review patches, and yet there is this discussion to track patches
> better. It reminds me of someone who has lost their keys in an alley,
> but is looking for them in the street because the light is better there.
Bruce, I gue
Josh Berkus wrote:
> Bruce, all,
>
> > No, my point is that 100% information is already available by looking at
> > email archives. What we need is a short description of where we are on
> > each patch --- that is a manual process, not something that can be
> > automated.
> >
> > Tom has posted i
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> You keep saying that but I think it's wrong. There are trivial patches that
>> were submitted last year that are still sitting in the queue.
>
> Um ... which ones exactly? I don't see *anything* in the current
Gregory Stark <[EMAIL PROTECTED]> writes:
> You keep saying that but I think it's wrong. There are trivial patches that
> were submitted last year that are still sitting in the queue.
Um ... which ones exactly? I don't see *anything* in the current queue
that is utterly without issues, other than
Chris Browne wrote:
> [EMAIL PROTECTED] (Andrew Dunstan) writes:
>> Tom Lane wrote:
>>> So in a roundabout way we come back
>>> to the idea that we need a bug tracker (NOT a patch tracker), plus
>>> people putting in the effort to make sure it stays a valid source
>>> of up-to-date info. Without t
Joshua D. Drake wrote:
Well according to himself the last time this came up:
http://archives.postgresql.org/pgsql-hackers/2006-08/msg01253.php
No, he isn't.
The last paragraph of
http://archives.postgresql.org/pgsql-hackers/2007-04/msg01258.php is
somewhat more positive regarding a patch t
Marc Munro <[EMAIL PROTECTED]> writes:
> On Wed, 2007-02-05 at 08:27 -0400, Andrew Dunstan wrote:
>> The question was rhetorical ... there is no list of "certified sane but
>> unapplied" patches. You are proceeding on the basis of a faulty
>> understanding of how our processes work.
> Why do we ne
Marc Munro wrote:
> On Wed, 2007-02-05 at 08:27 -0400, Andrew Dunstan wrote:
>>
>> Naz Gassiep wrote:
>> > Andrew Dunstan wrote:
>> >
>> >> Naz Gassiep wrote:
>> >>
>> >>> I believe the suggestion was to have an automated process that only
>> ran
>> >>> on known, sane patches.
>> >>>
>> >> How do w
Josh Berkus wrote:
Bruce, all,
No, my point is that 100% information is already available by looking at
email archives. What we need is a short description of where we are on
each patch --- that is a manual process, not something that can be
automated.
Tom has posted it --- tell me how we wil
Bruce, all,
> No, my point is that 100% information is already available by looking at
> email archives. What we need is a short description of where we are on
> each patch --- that is a manual process, not something that can be
> automated.
>
> Tom has posted it --- tell me how we will get such
On Wed, May 02, 2007 at 06:44:12AM -0400, Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > As an example, how is patch information going to help us review HOT or
> > > group-item-index? There is frankly more information about these in the
> > > archives than someone could reasonable read. What
On Wed, 2007-02-05 at 08:27 -0400, Andrew Dunstan wrote:
>
> Naz Gassiep wrote:
> > Andrew Dunstan wrote:
> >
> >> Naz Gassiep wrote:
> >>
> >>> I believe the suggestion was to have an automated process that only ran
> >>> on known, sane patches.
> >>>
> >> How do we know in advance
[EMAIL PROTECTED] (Andrew Dunstan) writes:
> Tom Lane wrote:
>> So in a roundabout way we come back
>> to the idea that we need a bug tracker (NOT a patch tracker), plus
>> people putting in the effort to make sure it stays a valid source
>> of up-to-date info. Without the latter it won't really b
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> >So in a roundabout way we come back
> >to the idea that we need a bug tracker (NOT a patch tracker), plus
> >people putting in the effort to make sure it stays a valid source
> >of up-to-date info. Without the latter it won't really be useful.
>
>
Tom Lane wrote:
So in a roundabout way we come back
to the idea that we need a bug tracker (NOT a patch tracker), plus
people putting in the effort to make sure it stays a valid source
of up-to-date info. Without the latter it won't really be useful.
Hallelujah Brother!
BTW, a bug trac
Naz Gassiep wrote:
Andrew Dunstan wrote:
Naz Gassiep wrote:
I believe the suggestion was to have an automated process that only ran
on known, sane patches.
How do we know in advance of reviewing them that they are sane?
Same way as happens now.
The question was rhet
Gregory Stark wrote:
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > We seem to handle trivial patches just fine.
>
> You keep saying that but I think it's wrong. There are trivial patches that
> were submitted last year that are still sitting in the queue.
You seem to be looking at som
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> We seem to handle trivial patches just fine.
You keep saying that but I think it's wrong. There are trivial patches that
were submitted last year that are still sitting in the queue.
In fact I claim we handle complex patches better than trivial on
Josh Berkus wrote:
> Bruce,
>
> > As an example, how is patch information going to help us review HOT or
> > group-item-index? There is frankly more information about these in the
> > archives than someone could reasonable read. What someone needs is a
> > summary of where we are now on the patc
Magnus Hagander wrote:
> > As an example, how is patch information going to help us review HOT or
> > group-item-index? There is frankly more information about these in the
> > archives than someone could reasonable read. What someone needs is a
> > summary of where we are now on the patches, and
Tom Lane wrote:
Josh Berkus <[EMAIL PROTECTED]> writes:
Actually, that can happen with the current system. The real blocker there is
that some people, particularly Tom, work so fast that there's no chance for a
new reviewer to tackle the easy stuff. Maybe the real solution is to
encourage some
On Tue, May 01, 2007 at 07:09:24PM -0400, Bruce Momjian wrote:
> > The current patch-queue process is failing to scale with the project: every
> > release it gets to be more work for you & Tom to integrate the patches. We
> > need to think of new approaches to make the review process scale. As
> What is "approved to contrib"?
>
> The problem here is that having reasonable certainty that a patch is
> not malicious requires having gone over it in some detail; at which
> point you might as well apply the thing. Or if you didn't apply it,
> you bounced it for reasons that are unlikely to h
Josh Berkus <[EMAIL PROTECTED]> writes:
> Actually, that can happen with the current system. The real blocker there is
> that some people, particularly Tom, work so fast that there's no chance for a
> new reviewer to tackle the easy stuff. Maybe the real solution is to
> encourage some of our ot
Naz Gassiep <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> How do we know in advance of reviewing them that they are sane?
> Same way as happens now. I would assume this mechanism would only be
> applied to patches that had already been approved to contrib, or some
> other measure that can
Bruce,
> As an example, how is patch information going to help us review HOT or
> group-item-index? There is frankly more information about these in the
> archives than someone could reasonable read. What someone needs is a
> summary of where we are now on the patches, and lots of time.
The ide
Andrew Dunstan wrote:
> Naz Gassiep wrote:
>> I believe the suggestion was to have an automated process that only ran
>> on known, sane patches.
> How do we know in advance of reviewing them that they are sane?
Same way as happens now. I would assume this mechanism would only be
applied to patches
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Jim Nasby) wrote:
> Two more ideas for the manager, now that we seem to have consensus to
> build one.
>
One other thing a webapp would allow that would help grow the community.
If the patches are all in a public place then reviewer wannabe
Andrew Dunstan wrote:
>
>
> Josh Berkus wrote:
> > Andrew,
> >
> >
> >> So if the commercial
> >> backers of PostgreSQL want better management of the project, maybe they
> >> need to find some resources to help out.
> >>
> >
> > I don't think they really care, or we'd have heard something
Josh Berkus wrote:
> Bruce,
>
> > > The bottom line is if you had a system that was 100% perfect in
> > > capturing all information about a patch, it only helps us 2% toward
> > > reviewing the patch, and what is the cost of keeping 100% information?
> >
> > 2% for you or Tom reviewing a recently
> --- Original Message ---
> From: Andrew Dunstan <[EMAIL PROTECTED]>
> To: Josh Berkus <[EMAIL PROTECTED]>
> Sent: 01/05/07, 21:10:07
> Subject: Re: [HACKERS] Feature freeze progress report
>
> So if the commercial
> backers of PostgreSQL want bet
Josh Berkus wrote:
Andrew,
So if the commercial
backers of PostgreSQL want better management of the project, maybe they
need to find some resources to help out.
I don't think they really care, or we'd have heard something by now. I
think this is up to us PG developers.
Well
Andrew,
> So if the commercial
> backers of PostgreSQL want better management of the project, maybe they
> need to find some resources to help out.
I don't think they really care, or we'd have heard something by now. I
think this is up to us PG developers.
--
--Josh
Josh Berkus
PostgreSQL @
Josh Berkus wrote:
> Dave,
>
>> The reason for basing the system on email is simply that it minimises
>> the changes required in the community process. If it were entirely web
>> based, we'd have to change the way we all work to discuss patches in a
>> forum style, rather than a list style. I have
Josh Berkus wrote:
If many people are going to block on using a web tool for submitting new
versions of a patch, claiming responsibility for review, etc., though, then
we should probably abandon this discussion right here. No new tool is going
to work if we have people who won't make any chan
On Tue, 2007-05-01 at 09:43 -0700, Josh Berkus wrote:
> The current patch-queue process is failing to scale with the project: every
> release it gets to be more work for you & Tom to integrate the patches. We
> need to think of new approaches to make the review process scale. As a
> pointed e
Dave,
> The reason for basing the system on email is simply that it minimises
> the changes required in the community process. If it were entirely web
> based, we'd have to change the way we all work to discuss patches in a
> forum style, rather than a list style. I have a sneaking suspicion that
Josh,
Josh Berkus wrote:
Is there a reason why the system needs to be primarily based on e-mail? I was
thinking that the patch manager would be entirely a web tool, with people
submitting and modifying a patch directly through a web interface. This
would be lots easier to build than an e-mai
Two more ideas for the manager, now that we seem to have consensus to
build one.
On Apr 30, 2007, at 6:04 PM, Josh Berkus wrote:
-- We could save the patches by applied date and index them, and
then have a
place to point users when they ask: "When was X fixed? Do I *have* to
upgrade to 8.1
Bruce,
> > The bottom line is if you had a system that was 100% perfect in
> > capturing all information about a patch, it only helps us 2% toward
> > reviewing the patch, and what is the cost of keeping 100% information?
>
> 2% for you or Tom reviewing a recently discussed, run-of-the mill patch
Bruce Momjian wrote:
The bottom line is if you had a system that was 100% perfect in
capturing all information about a patch, it only helps us 2% toward
reviewing the patch, and what is the cost of keeping 100% information?
2% for you or Tom reviewing a recently discussed, run-of-the mill patch
On Tue, 2007-01-05 at 02:54 +0100, Gregory Stark wrote:
> "Naz Gassiep" <[EMAIL PROTECTED]> writes:
>
> > Even if the patch inventory wasn't kept right up to date, this system
> > could potentially help many regression issues or bugs to surface sooner,
>
> I just don't understand what this would
Naz Gassiep wrote:
I believe the suggestion was to have an automated process that only ran
on known, sane patches.
How do we know in advance of reviewing them that they are sane?
What is more, we often run into situations where patch a will require
changes in patch b, so testing them indi
Dave Page wrote:
> > The bottom line is that there is a lot of thinking that the patch queue
> > is so large because no one knows what to do. "Oh, if we were better
> > communicators, more would be done". The patch queue is large because we
> > have lots of March 31 patches, and because we don't
Bruce Momjian wrote:
>
> Sounds interesting, but I am not sure how that is going to track
> multiple versions of the patch,
They could easily be submitted through the web interface as revisions to
the original version.
> or changes in the email subject.
We'd need to keep the reference number in
"Naz Gassiep" <[EMAIL PROTECTED]> writes:
> Even if the patch inventory wasn't kept right up to date, this system
> could potentially help many regression issues or bugs to surface sooner,
I just don't understand what this would accomplish. People run regressions
before submitting anyways. They c
I believe the suggestion was to have an automated process that only ran
on known, sane patches. I don't think he was suggesting a mechanism for
the great unwashed masses to dump arbitrary code into and have it
applied in the buildfarm. You'd have an inventory of patches (you could
use a hash to ens
Dave Page wrote:
> In my original message I described my thinking:
>
> - Developer submits patch, with additional info through a web interface.
>
> - The web interface formats an email containing the patch description,
> patch and any other info entered, assigns it a patch number, and
> forwards
[EMAIL PROTECTED] (Marc Munro) writes:
> On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
>> Date: Mon, 30 Apr 2007 09:18:36 +0100
>> From: Heikki Linnakangas <[EMAIL PROTECTED]>
>> To: Tom Lane <[EMAIL PROTECTED]>
>> Cc: Dave Page <[EMAIL PROTECTED]>, Simon Riggs
>> <[EMAIL PROTEC
Marc Munro wrote:
On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
Date: Mon, 30 Apr 2007 09:18:36 +0100
From: Heikki Linnakangas <[EMAIL PROTECTED]>
To: Tom Lane <[EMAIL PROTECTED]>
Cc: Dave Page <[EMAIL PROTECTED]>, Simon Riggs
<[EMAIL PROTECTED]>,
Bruce Momjian <[EMAIL P
On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
> Date: Mon, 30 Apr 2007 09:18:36 +0100
> From: Heikki Linnakangas <[EMAIL PROTECTED]>
> To: Tom Lane <[EMAIL PROTECTED]>
> Cc: Dave Page <[EMAIL PROTECTED]>, Simon Riggs
> <[EMAIL PROTECTED]>,
> Bruce Momjian <[EMAIL PROTECTED]>,
Heikki,
> We're having a short 8.3 cycle because we wanted to shift our release
> schedule from Autumn to Spring. That would get us back to releasing in
> Autumn.
Er, no. We wanted to change the cycle to avoid having Feature Freeze occur at
midsummer (N. hemisphere) when many of our committers
On Mon, Apr 30, 2007 at 07:27:10AM -0400, Bruce Momjian wrote:
> Dave Page wrote:
> > I'm not specifically talking about complex patches (nor am I talking at
> > all about bug tracking) - there are a variety of patches in the queue,
> > of varying complexity. Some have been there for months, and wo
Dave Page wrote:
Stefan Kaltenbrunner wrote:
This means that there is a huge rush of new code in pgAdmin's
development cycle, right at the time when we should be testing - making
the release process more and more rushed as each release of PostgreSQL
gets more efficient and adds more and more new
Dave Page wrote:
In my original message I described my thinking:
- Developer submits patch, with additional info through a web interface.
- The web interface formats an email containing the patch description,
patch and any other info entered, assigns it a patch number, and
forwards it to the
Bruce Momjian wrote:
> Dave Page wrote:
>> 2) Introduce a new patch management system. I suggest a web interface
>> through which patches be submitted. This would assign them an ID number,
>> and forward them to the patches list. The system would track any
>> responses to the initial email, logg
Bruce Momjian wrote:
> Tom Lane wrote:
>> Dave Page <[EMAIL PROTECTED]> writes:
>>> I like the idea of having a sync point mid cycle, however, what I'd like
>>> to see even more is an improved system in which we put less pressure on
>>> the few committers we have, and give them more freedom to co
Marc G. Fournier wrote
patches held over from feature freeze from the previous
release will be reviewed within two months of the tree re-opening
a. why 2 months? shouldn't they be given priority, period?
Yes, but they don't always seem to get it.
b. what happens after 2 months
Every patch in the queue is ready for review. If we have bounced
something back for the author to fix, it gets removed from the queue.
As far as adding comments, again, this wasn't meant to be a community
resource, just my tracking system, and I have given feedback on the
status to any committe
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
> > I like the idea of having a sync point mid cycle, however, what I'd like
> > to see even more is an improved system in which we put less pressure on
> > the few committers we have, and give them more freedom to commit patches
> > they m
Andrew Dunstan wrote:
> I don't think we need a sync point. I think we need to get better at
> setting expectations and at managing the patch queue so that it gets
> drained better all the time. Nothing can be more frustrating for patch
> authors than to have patches in the queue for a very long
Dave Page wrote:
> I'm not specifically talking about complex patches (nor am I talking at
> all about bug tracking) - there are a variety of patches in the queue,
> of varying complexity. Some have been there for months, and worse, some
> of them recieved little or no feedback when submitted leavi
Dave Page wrote:
> 2) Introduce a new patch management system. I suggest a web interface
> through which patches be submitted. This would assign them an ID number,
> and forward them to the patches list. The system would track any
> responses to the initial email, logging the thread automaticall
Lukas Kahwe Smith wrote:
> Alvaro Herrera wrote:
>
> > Yeah; the agreement we had was that 8.3 would be a short release. So if
> > we're going to take too long to review and apply the outstanding patches
> > we have, we should rather push them to 8.4, get 8.3 released quickly and
> > then go on w
Gregory Stark wrote:
>
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>
> > The postponed patches can be reviewed and committed early in 8.4, instead of
> > at the last minute in 8.3.
>
> Given that some of those patches have been in the queue since last September
> is there any reason to think
Alvaro Herrera wrote:
> Stefan Kaltenbrunner wrote:
> > Simon Riggs wrote:
>
> > > I would also suggest that 8.3 be labelled a dev release. We have a
> > > reasonable number of fairly invasive patches, so we need a mechanism to
> > > integrate them with reduced risk.
> >
> > I would rather like t
Heikki Linnakangas wrote:
> Simon Riggs wrote:
> > My thinking is to move to a two stage release process: Do one
> > "production" release annually, and one "dev" release at the 6 month
> > mid-point. That way each new release contains a manageable number of new
> > features and we have a realistic
Stefan Kaltenbrunner wrote:
> Simon Riggs wrote:
> > On Thu, 2007-04-26 at 23:13 -0400, Bruce Momjian wrote:
> >
> >> Our community could probably handle a few of these complex patches, but
> >> the volume for this release is significantly higher than previous
> >> releases. The community is doin
Tom Lane wrote:
[ thinks for a bit... ] What we need to expand is not so much the pool
of committers as the pool of reviewers. If a patch had been signed off
on by X number of reasonably-qualified people then it'd be fair to
consider that it could be committed. The tracking system you suggest
Stefan Kaltenbrunner wrote:
>> No, but it's exactly the reason why we release with/just before
>> PostgreSQL. If we were offset by six months, we might find ourselves
>> having to do compatibility releases mid-cycle for the latest PostgreSQL
>> release. A change in pg_database such as we had previo
Dave Page wrote:
Stefan Kaltenbrunner wrote:
Interesting ... so if you have a new feature (or a number of them) -
that is not directly depending on some sort of new backend feature - in
pgadmin you "delay" it until the next postgresql mjor release ?
It's not so much that we delay the new featu
On Mon, Apr 30, 2007 at 08:01:04AM +0200, Stefan Kaltenbrunner wrote:
> Dave Page wrote:
> > Stefan Kaltenbrunner wrote:
> >>> This means that there is a huge rush of new code in pgAdmin's
> >>> development cycle, right at the time when we should be testing - making
> >>> the release process more a
Stefan Kaltenbrunner wrote:
> Interesting ... so if you have a new feature (or a number of them) -
> that is not directly depending on some sort of new backend feature - in
> pgadmin you "delay" it until the next postgresql mjor release ?
It's not so much that we delay the new features, it's just
Tom Lane wrote:
> Dave Page <[EMAIL PROTECTED]> writes:
>> I like the idea of having a sync point mid cycle, however, what I'd like
>> to see even more is an improved system in which we put less pressure on
>> the few committers we have, and give them more freedom to commit patches
>> they may n
Dave Page wrote:
> Stefan Kaltenbrunner wrote:
>>> This means that there is a huge rush of new code in pgAdmin's
>>> development cycle, right at the time when we should be testing - making
>>> the release process more and more rushed as each release of PostgreSQL
>>> gets more efficient and adds mo
Dave Page <[EMAIL PROTECTED]> writes:
> I like the idea of having a sync point mid cycle, however, what I'd like
> to see even more is an improved system in which we put less pressure on
> the few committers we have, and give them more freedom to commit patches
> they may not understand fully th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Sunday, April 29, 2007 19:38:21 -0400 Andrew Dunstan
<[EMAIL PROTECTED]>
wrote:
> patches held over from feature freeze from the previous
> release will be reviewed within two months of the tree re-opening
a. why 2 months? shouldn't they b
Dave Page wrote:
But I don't like the idea of making a release out of it. Who would
use such a release? No one in production. Making a release comes with
a cost, even if it's just a dev release.
Agreed. That would have the opposite effect of what should happen.
I like the idea of having a
Stefan Kaltenbrunner wrote:
2) Introduce a new patch management system. I suggest a web interface
through which patches be submitted. This would assign them an ID number,
and forward them to the patches list. The system would track any
responses to the initial email, logging the thread automatic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --On Sunday, April 29, 2007 21:30:36 +0200 Stefan Kaltenbrunner
<[EMAIL PROTECTED]> wrote:
> not sure I fully agree here - I think we could do a bit better on the
> "bug tracking front" but it is a bit unclear if we cn honestly sy that
> "the cur
Stefan Kaltenbrunner wrote:
>> This means that there is a huge rush of new code in pgAdmin's
>> development cycle, right at the time when we should be testing - making
>> the release process more and more rushed as each release of PostgreSQL
>> gets more efficient and adds more and more new feature
Dave Page wrote:
> Heikki Linnakangas wrote:
>> I like the idea of draining the patch queue mid-way through the
>> release cycle. That'll hopefully encourage people to submit patches
>> earlier in the release cycle, knowing they will be reviewed. It'll
>> also give people working on external projec
Heikki Linnakangas wrote:
I like the idea of draining the patch queue mid-way through the release
cycle. That'll hopefully encourage people to submit patches earlier in
the release cycle, knowing they will be reviewed. It'll also give people
working on external projects, drivers and tools, a ch
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
> Hmm, I do not have an overview on this, but like Alvaro mentions, the
> shorter release cycles for 8.3 was done because we felt that a number of
> patches that were originally slated for 8.2 were almost but not quite
> ready for 8.2. So are all of
Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> My thinking is to move to a two stage release process: Do one
>> "production" release annually, and one "dev" release at the 6 month
>> mid-point.
> I'm not really convinced that this is good idea at all - it would lead
> to
Alvaro Herrera wrote:
Yeah; the agreement we had was that 8.3 would be a short release. So if
we're going to take too long to review and apply the outstanding patches
we have, we should rather push them to 8.4, get 8.3 released quickly and
then go on with the regular annual release. The postpo
1 - 100 of 109 matches
Mail list logo
