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 little
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. Maybe the
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
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 see that
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 guys go ahead
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 queue
that
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
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 guess
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 better
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
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
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
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
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
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
-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
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
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 a
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
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 lots
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 patches, and
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 ones.
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 something
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
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
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.
Hallelujah
[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 be
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 of reviewing them that
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 someone
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 a
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
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 we know in advance of reviewing them
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 need to know
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
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 the latter it
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
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
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 have
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
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 accomplish.
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
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.
I
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
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
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
at
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
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
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 a
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:
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.
--- 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 better management of the project, maybe they
need
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 by now. I
think
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 wannabees
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 that
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 idea
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 be
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 other
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 have
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
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 not
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 that
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 and more rushed
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
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 previously
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:
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 doing a good job
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 chance of
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 to see patches we
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 they'll get
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 with the
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 automatically
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 leaving
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
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 not
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
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
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 commit patches
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, logging the
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
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
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 worse,
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, 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],
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
[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 PROTECTED],
Bruce
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
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
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 can't
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 doing a good job of giving patch writers
feedback and new patch
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 doing a good job of giving patch writers
feedback
On 4/28/07, Simon Riggs [EMAIL PROTECTED] wrote:
I think the community has to come up with ideas on how to accomplish this.
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
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 chance of integrating them
successfully.
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 to see patches we don't are confident enough in
Heikki Linnakangas [EMAIL PROTECTED] writes:
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,
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 they'll get reviewed early in this cycle
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
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 further
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 those
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
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 projects,
1 - 100 of 108 matches
Mail list logo
