On Sep 22, 2006, at 2:50 PM, Joshua D. Drake wrote:
And how were you planning to tell if a patch cam from a regular?
Hopefully
you weren't planning on blindly trusting the "from" header.
Misuse of the build farm in a way the effects other sites could
get the
project a big black eye, so you w
Jim C. Nasby wrote:
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan <[EMAIL PROTECTED]> wrote:
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regulars could proba
On Fri, Sep 22, 2006 at 11:58:04AM -0500, Bruno Wolff III wrote:
> On Wed, Sep 13, 2006 at 22:22:12 -0700,
> Tom Dunstan <[EMAIL PROTECTED]> wrote:
> >
> > That's a worthwhile point. How many patches come from the general
> > community vs out of the blue? Patches from regulars could probably ge
On Wed, Sep 13, 2006 at 22:22:12 -0700,
Tom Dunstan <[EMAIL PROTECTED]> wrote:
>
> That's a worthwhile point. How many patches come from the general
> community vs out of the blue? Patches from regulars could probably get a
> free pass, which might cut down the review burden substantially.
An
Joachim Wieland <[EMAIL PROTECTED]> writes:
> I have the patch almost ready in the described form, if there is any chance
> it will make it into 8.2 I will clean it up and post it ASAP but Peter wrote
> me that chances are close to zero and so I stopped working on it for now.
If you'd mentioned it
On Mon, Sep 18, 2006 at 01:13:45PM +0200, Peter Eisentraut wrote:
> Joachim Wieland is in the process of reworking the original feature patch
> (resetting commented out parameters) in a much more compact form. But it
> turns out that there are a couple of very tricky situations involving custom
Am Freitag, 15. September 2006 20:32 schrieb Tom Lane:
> I've finally taken a close look at this patch, and I don't like it any
> more than Peter does. The refactoring might or might not be good at its
> core, but as presented it is horrid.
Joachim Wieland is in the process of reworking the origi
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> That does not mean that the patch is bad, and I certainly support the
> feature change. But I can't efficiently review the patch. If someone
> else wants to do it, go ahead.
I've finally taken a close look at this patch, and I don't like it any
mo
Hi, Jeremy,
Jeremy Drake wrote:
>>> Another possibility would be to test these patches in some kind of virtual
>>> machine that gets blown away every X days, so that even if someone did get
>>> something malicious in there it wouldn't last long.
>
> Or just have a snapshot which is reverted afte
Jeremy Drake wrote:
On Wed, 13 Sep 2006, Tom Dunstan wrote:
I was under the impression that most VM products are x86 centric, which
wouldn't lead to huge amounts of diversity in the buildfarm results. At least,
not as far as architecture goes.
I have played with QEmu (www.qemu.org) which is o
On Wed, 13 Sep 2006, Tom Dunstan wrote:
> > Another possibility would be to test these patches in some kind of virtual
> > machine that gets blown away every X days, so that even if someone did get
> > something malicious in there it wouldn't last long.
Or just have a snapshot which is reverted a
Jim Nasby wrote:
That's something I'd be willing to do. And for many people that aren't
committers but are still trusted in the community, we could probably
bypass the checking.
That's a worthwhile point. How many patches come from the general
community vs out of the blue? Patches from regula
On Sep 13, 2006, at 6:56 PM, Tom Dunstan wrote:
Regarding the idea of a list of approved patch authorisers, don't
we have
such a group now? i.e. "committers".
Right, and if committers or others are willing to put in the time
required to verify that patches aren't nasty before going onto the
Jim C. Nasby wrote:
There's been talk in the past of having some kind of system that
automatically attempts to build things that are in the patch queue, both
as an initial sanity-check and as a means to detect when something
bit-rots... perhaps it's becoming worthwhile to set that up.
After wri
Andrew Dunstan wrote:
Tom's idea of making a temp copy of the repo and patching that would work,
but if you're going to do that why do a vpath build anyway?
In this case, the answer is to make sure that your patch works when
*someone else* does a vpath build.
Regarding the idea of a list of
Alvaro Herrera wrote:
>
> Huh, but the patch can be applied with -R to revert it after the
> buildfarm run ... the one problem I can see is if the patch fails for
> some reason; for which I'd suggest running a patch --dry-run as a first
> step, checking that it applies cleanly, and only continue in
Tom Dunstan wrote:
> Alvaro Herrera wrote:
> >>I submitted a patch to Andrew, but it needed a couple of tweaks
> >>(disabling patching on vpath builds, for example) and I don't think I
> >>ever got around to resubmitting it, but if there's more general interest
> >>I'll do so.
> >
> >Huh, why wo
Alvaro Herrera wrote:
I submitted a patch to Andrew, but it needed a couple of tweaks
(disabling patching on vpath builds, for example) and I don't think I
ever got around to resubmitting it, but if there's more general interest
I'll do so.
Huh, why would you disable patching on vpath builds?
Tom Dunstan wrote:
> The idea was that patch authors could either run it manually or stick it
> in a cron so they could get emailed when the patch no longer cleanly
> applied, or when the patched source failed in make, make check etc.
> Obviously my motivation was to keep the enum patch up to d
Jim C. Nasby wrote:
> There's been talk in the past of having some kind of system that
> automatically attempts to build things that are in the patch queue, both
> as an initial sanity-check and as a means to detect when something
> bit-rots... perhaps it's becoming worthwhile to set that up.
Aft
On Sat, Sep 02, 2006 at 09:26:36PM -0700, Joshua D. Drake wrote:
>
> >>>I just spent 1/2 hour fixing the multi-value UPDATE
> >>>patch for the code drift caused by UPDATE/RETURNING. The patch is a
> >>>simple grammar macro. Any coder could have taken that, reviewed it, and
> >>>applied it, but n
On Fri, Sep 01, 2006 at 03:28:36PM -0400, Stephen Frost wrote:
> Overall, I really think 8.2 is going to be an excellent release. I wish
> autovacuum could have been enabled by default and I'd just like to ask,
> now and I'll try to remember again once 8.2 is out, please let's turn it
> on by defa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Well, it's taken us the full month to get this far through the queue, so
> >> I'd sure like to have more people on board reviewing next time. Alvaro
> >> helped but I miss Neil Conway, and some other people have h
Alvaro Herrera wrote:
Joshua D. Drake wrote:
It does not mean all those features are useful, they definitely are. I
am just trying to look at it from at:
WHIZ* BANG* POW* perspective.
Holy crap, Batman! This database can do
INSERT INTO foo VALUES (1,1, 'so long'), (42, 2, 'and tha
Andrew Sullivan wrote:
On Sun, Sep 03, 2006 at 07:42:02PM -0400, Tom Lane wrote:
The hard part of this problem is finding a convenient way to capture
status data out of the community's conversations. I think when you find
a solution to that, you'll notice that email is not the problem.
On Sun, Sep 03, 2006 at 07:42:02PM -0400, Tom Lane wrote:
> The hard part of this problem is finding a convenient way to capture
> status data out of the community's conversations. I think when you find
> a solution to that, you'll notice that email is not the problem.
In private groups (like com
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > How many times do I have to say this: IT IS NOT A REFACTOR PATCH AS
> > REPORTED BY THE AUTHOR, AND PETER HAS NOT REFUTED THAT.
>
> The initial patch was the feature plus some code refactoring included.
> That was what the author said. I asked
Bruce Momjian wrote:
> How many times do I have to say this: IT IS NOT A REFACTOR PATCH AS
> REPORTED BY THE AUTHOR, AND PETER HAS NOT REFUTED THAT.
The initial patch was the feature plus some code refactoring included.
That was what the author said. I asked him to submit the refactoring
and
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Bruce Momjian wrote:
> >> Without a reply from Peter, I have to assume the patch is valid.
>
> > To make it more explicit: I think the patch is stupid, but if someone
> > wants to review it, go ahead. But I am not comfortable wit
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Without a reply from Peter, I have to assume the patch is valid.
> To make it more explicit: I think the patch is stupid, but if someone
> wants to review it, go ahead. But I am not comfortable with the "if no
> one objects,
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of ma
Am Montag, 4. September 2006 04:19 schrieb Bruce Momjian:
> And our email threads wander around quite a bit, with patches, ideas,
> and bugs sometimes all thrown in --- see the interval
> multiplication/division thread as a good example. How do you capture
> that?
It's easy: Those who put in the
Am Montag, 4. September 2006 04:10 schrieb Bruce Momjian:
> Are you saying you don't like the patch,
That's it.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 4: Have you searched our list archives?
Andrew Dunstan wrote:
I spent months on a working party on these and similar issues a few
years back, in a commercial setting. One of the big issues is when you
start tracking something. Bugs are a pretty simple case. Features are
much harder to handle. Someone comes up with an idea. There is
Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can start
t
This is not that far different from the premise upon which you built
the buildfarm: that there were people out there able to provide machine
resources and a certain amount of admin time. The resources this
project requires are not those exactly, but why shouldn't we expect
that some people will
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> Oh, lots of grunt work. I can see that working, but at a high cost.
> I doubt it. Let's just start with bugs, since that's the easy case
> anyway. Our real volume is pretty low, so the cost of maintaining it
> should not be hi
Andrew Dunstan wrote:
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we
Bruce Momjian wrote:
Oh, lots of grunt work. I can see that working, but at a high cost.
I doubt it. Let's just start with bugs, since that's the easy case
anyway. Our real volume is pretty low, so the cost of maintaining it
should not be high. I am assuming we would not be including
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Oh, so the bug is tracked by being part of the email reply list. That
> > is a good idea. Now, how does that get assigned for non-bugs, like
> > patches? Does any email sent to the lists that doesn't already have a
> > bug number ge
Tom Lane wrote:
AFAICS the bottom line here is that we need some intelligent filtering.
In the short run I doubt that we can have that except through human
gruntwork to filter the mail traffic and update a tracker database.
Maybe after we see such a system in operation for awhile, we can start
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Anyway, let me reiterate: bz has at least the start of an email reply
> facility, and making that work if it doesn't already should not be
> beyond us.
I agree that starting from scratch seems like a good way to waste a
lot of time. I don't have a pr
Bruce Momjian wrote:
Oh, so the bug is tracked by being part of the email reply list. That
is a good idea. Now, how does that get assigned for non-bugs, like
patches? Does any email sent to the lists that doesn't already have a
bug number get one? That might be really valuable.
It wou
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Oh, so the bug is tracked by being part of the email reply list. That
> is a good idea. Now, how does that get assigned for non-bugs, like
> patches? Does any email sent to the lists that doesn't already have a
> bug number get one? That might be real
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > As for remarks about old school unix hackers not liking web interfaces,
> > I think Tom's recent remarks relating to the 21st century were more than
> > apposite.
>
> I don't see a big problem with using a web interface to search f
Gregory Stark wrote:
>
> Martijn van Oosterhout writes:
>
> > I assume other bug trackers have a similar feature...
>
> Sadly no. That's precisely why I was pushing debbugs so hard earlier.
Oh. That is bad.
> The weakest of them will send a content-free email saying *something* happened
> t
Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> On Sun, Sep 03, 2006 at 03:40:40PM -0400, Bruce Momjian wrote:
> > This is also an interesting example for a tracker. If we had one, all
> > discussion on the patch would be in one place, but I am thinking that
> > would require all p
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Without a reply from Peter, I have to assume the patch is valid.
>
> To make it more explicit: I think the patch is stupid, but if someone
> wants to review it, go ahead. But I am not comfortable with the "if no
> one objects, I'll just commit
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
in
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
As for remarks about old school unix hackers not liking web interfaces,
I think Tom's recent remarks relating to the 21st century were more than
apposite.
I don't see a big problem with using a web interface to search for
information
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> As for remarks about old school unix hackers not liking web interfaces,
> I think Tom's recent remarks relating to the 21st century were more than
> apposite.
I don't see a big problem with using a web interface to search for
information --- they're g
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> As for remarks about old school unix hackers not liking web interfaces, I
> think Tom's recent remarks relating to the 21st century were more than
> apposite.
I like web interfaces well enough for the things they're good at.
Replacing e-mail is not o
Gregory Stark wrote:
Martijn van Oosterhout writes:
I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
The weakest of them will send a content-free email saying *something* happened
to your issue and you ha
Martijn van Oosterhout writes:
> I assume other bug trackers have a similar feature...
Sadly no. That's precisely why I was pushing debbugs so hard earlier.
The weakest of them will send a content-free email saying *something* happened
to your issue and you have to click a link to find out wh
On Sun, Sep 03, 2006 at 03:40:40PM -0400, Bruce Momjian wrote:
> This is also an interesting example for a tracker. If we had one, all
> discussion on the patch would be in one place, but I am thinking that
> would require all posting to happen in a browser, or somehow have emails
> tagged to atta
Bruce Momjian wrote:
> Without a reply from Peter, I have to assume the patch is valid.
To make it more explicit: I think the patch is stupid, but if someone
wants to review it, go ahead. But I am not comfortable with the "if no
one objects, I'll just commit it" mode that is sometimes going on.
bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Tom Lane wrote:
> > >> Peter has made it pretty clear that he didn't care for the
> > >> refactorization aspect of that patch.
> >
> > > Peter asked why it was done, a good answer was given, and Peter did not
> > >
Joshua D. Drake wrote:
>
> >>> I just spent 1/2 hour fixing the multi-value UPDATE
> >>> patch for the code drift caused by UPDATE/RETURNING. The patch is a
> >>> simple grammar macro. Any coder could have taken that, reviewed it, and
> >>> applied it, but no one did.
> >> Perhaps that's because
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Peter has made it pretty clear that he didn't care for the
> >> refactorization aspect of that patch.
>
> > Peter asked why it was done, a good answer was given, and Peter did not
> > reply.
>
> Au contraire, he'
Tom Lane wrote:
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
For example I have no expertise in coding on Postgres, but I think I
would be able to collect information from this mailinglist (like specs,
url's etc.) and put them in some issue tracker or wiki. I have done
exactly the same f
Bruce Momjian wrote:
> Why aren't more people involved? Is this such a thankless task? I
> am starting to think so.
I can tell you exactly what my problem is. The tools are terrible. In
projects with a useful issue tracking system I can take small chunks
out of my day to contribute to speci
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Peter has made it pretty clear that he didn't care for the
>> refactorization aspect of that patch.
> Peter asked why it was done, a good answer was given, and Peter did not
> reply.
Au contraire, he's reiterated since then that he di
I just spent 1/2 hour fixing the multi-value UPDATE
patch for the code drift caused by UPDATE/RETURNING. The patch is a
simple grammar macro. Any coder could have taken that, reviewed it, and
applied it, but no one did.
Perhaps that's because nobody but you wanted it to go in.
We got tons o
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... The GUC comment/default patch had tons of
> > emails, but no other committers got involved to review or commit the
> > patch. Peter, who knows GUC well, looked at it, but said he didn't
> > review it enough.
>
> Peter has made i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... The GUC comment/default patch had tons of
> emails, but no other committers got involved to review or commit the
> patch. Peter, who knows GUC well, looked at it, but said he didn't
> review it enough.
Peter has made it pretty clear that he didn't
On 2/9/06 20:16, "Martijn van Oosterhout" wrote:
> On Sat, Sep 02, 2006 at 06:38:30PM +0100, Dave Page wrote:
>> The wiki will be going shortly as it's not been setup in the way that was
>> agreed, nor is it being used for it's intended purpose. I'll put it right
>> when I get time from dealin
On Sat, Sep 02, 2006 at 06:38:30PM +0100, Dave Page wrote:
> The wiki will be going shortly as it's not been setup in the way that was
> agreed, nor is it being used for it's intended purpose. I'll put it right
> when I get time from dealing with releases of everything I seem to be
> involved in.
Martijn van Oosterhout wrote:
On Sat, Sep 02, 2006 at 06:18:13PM +0200, Lukas Kahwe Smith wrote:
We have a wiki already:
http://wiki.postgresql.org/
I must have missed the annoucement, oh well...
Now I'm only familiar with twiki so maybe this sounds silly but:
wiki.postgresql.org is dead. :
On 2/9/06 17:18, "Lukas Kahwe Smith" <[EMAIL PROTECTED]> wrote:
> Peter Eisentraut wrote:
>> Martijn van Oosterhout wrote:
>>> I remember something about setting up a wiki for a todo list and pie
>>> in the sky list. I thought it had promise, but until the wiki is
>>> there we won't know...
>>
Bruce Momjian wrote:
It seems that you have been the only busy bee so far, and we definitely
need more for this to work.
Yea, I was afraid that was the answer. :-(
But we have a few volunteers, like me for example.
Now don't say "I was afraid that was the answer" again or I might feel
insu
On Sat, Sep 02, 2006 at 06:18:13PM +0200, Lukas Kahwe Smith wrote:
> We have a wiki already:
> http://wiki.postgresql.org/
I must have missed the annoucement, oh well...
Now I'm only familiar with twiki so maybe this sounds silly but:
Does it support sections? Like can you have a developer secti
Bruce Momjian wrote:
Lukas Kahwe Smith wrote:
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM the
questions we should be asking are who can actually help out with patch re
Lukas Kahwe Smith wrote:
> Bruce Momjian wrote:
> > Lukas Kahwe Smith wrote:
> >> Robert Treat wrote:
> >>
> >>> No offense, a whole lot of this thread seems to be positioned that way,
> >>> but
> >>> the real problem seems to be we do not have enough patch reviewers. ISTM
> >>> the
> >>> ques
Joshua D. Drake wrote:
That wiki is wrong. :) It was set up wrong and configured wrong. It was
supposed to be for developers only.
There is also another wiki that is a trac based that was set up at dave
pages request (for slaves_to_www).
Setup something better, until then we can start using
Lukas Kahwe Smith wrote:
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the wiki is the prerequisite for many ideas about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Holy crap, Batman! This database can do
>
> INSERT INTO foo VALUES (1,1, 'so long'), (42, 2, 'and thanks'),
> (142857, 3, 'for all the fish')
>
> now! We should be talking to more people about that!
>
> That will make some MySQL users happy at le
Lukas Kahwe Smith wrote:
> Robert Treat wrote:
>
> > No offense, a whole lot of this thread seems to be positioned that way, but
> > the real problem seems to be we do not have enough patch reviewers. ISTM
> > the
> > questions we should be asking are who can actually help out with patch
> >
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
I remember something about setting up a wiki for a todo list and pie
in the sky list. I thought it had promise, but until the wiki is
there we won't know...
I think the wiki is the prerequisite for many ideas about alternative
tracking and
Robert Treat wrote:
> On Saturday 02 September 2006 07:14, David Fetter wrote:
> > On Fri, Sep 01, 2006 at 09:46:02PM -0400, Bruce Momjian wrote:
> > > Peter Eisentraut wrote:
> > > > Bruce Momjian wrote:
> > > > > It pulls my a mailbox file I use, and it does instant updates as
> > > > > soon as I
Robert Treat wrote:
No offense, a whole lot of this thread seems to be positioned that way, but
the real problem seems to be we do not have enough patch reviewers. ISTM the
questions we should be asking are who can actually help out with patch review
and then ask those people why they haven't
Tom Lane wrote:
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
Additionally, what problem is accepting incremental patches supposed
to solve?
Keeping the individual patches reviewable is one useful goal.
We may be talking at cross-purposes here. The sort of thing I think
Alvaro is imagining
On Friday 01 September 2006 19:42, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > On Fri, 1 Sep 2006, Tom Lane wrote:
> >> My feeling is that we ought to bounce bitmap indexes and updatable views
> >> as not being ready, accept all the contrib stuff, and try to get the
> >> other it
Theo Schlossnagle <[EMAIL PROTECTED]> writes:
> Additionally, what problem is accepting incremental patches supposed
> to solve?
Keeping the individual patches reviewable is one useful goal.
We may be talking at cross-purposes here. The sort of thing I think
Alvaro is imagining is something li
On Sep 2, 2006, at 11:28 AM, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Here's a completely novel idea: accept incremental patches.
I don't think it's as novel as all that --- personally I've always
preferred to tackle large projects incrementally.
I think that accepting in
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Here's a completely novel idea: accept incremental patches.
I don't think it's as novel as all that --- personally I've always
preferred to tackle large projects incrementally.
> I've been bitten by having stuff rejected because there was no immediate
Lukas Kahwe Smith <[EMAIL PROTECTED]> writes:
>> For example I have no expertise in coding on Postgres, but I think I
>> would be able to collect information from this mailinglist (like specs,
>> url's etc.) and put them in some issue tracker or wiki. I have done
>> exactly the same for PHP [1]
On Saturday 02 September 2006 07:14, David Fetter wrote:
> On Fri, Sep 01, 2006 at 09:46:02PM -0400, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > It pulls my a mailbox file I use, and it does instant updates as
> > > > soon as I change it. It is a URL. Why d
Martijn van Oosterhout wrote:
> I remember something about setting up a wiki for a todo list and pie
> in the sky list. I thought it had promise, but until the wiki is
> there we won't know...
I think the wiki is the prerequisite for many ideas about alternative
tracking and documentation mechani
On Sat, Sep 02, 2006 at 09:00:35AM +0200, Lukas Kahwe Smith wrote:
> Actually I should add that I went ahead and created the PHP todo list on
> my own, without any official blessing and one by one internals developer
> have joined. Now its actively used in the entire release process.
That is the
On Fri, Sep 01, 2006 at 09:46:02PM -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > It pulls my a mailbox file I use, and it does instant updates as
> > > soon as I change it. It is a URL. Why do people care where it
> > > is?
> >
> > The complaint has been th
On Fri, Sep 01, 2006 at 10:13:07PM -0400, Jonah H. Harris wrote:
> On 9/1/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >I pummelled Jonah over the recursive query patch.
>
> He did. Trust me on this... think I still have some bruises too :)
That wasn't productive. Getting it out in public tha
Lukas Kahwe Smith wrote:
For example I have no expertise in coding on Postgres, but I think I
would be able to collect information from this mailinglist (like specs,
url's etc.) and put them in some issue tracker or wiki. I have done
exactly the same for PHP [1] (though there are rarely specs
Andrew Dunstan wrote:
It would make the process more transparent, which is something several
people have expressed a desire for.
Yes, the processes seems to work by having two of the most important
people waste time on getting information anyone else could collect, or
that the developer hims
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > As an extreme example consider the new Linux release cycle. They have a
> > non-freeze period of a couple weeks, followed by months of frozen time.
> > Users
> > who want to try out new features on different hard
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
> > Well, no, it's not. We have told people till we're blue in the face
> > "post early, post often". Now I will plead guilty to not always
> > having spent as much time giving feedback on draft patches as I
> > should've, but the p
Bruce Momjian wrote:
> I see no value in documenting it.
The value in documenting it is that the general awareness about the
progress of development is raised, so more people know where and how to
get involved, as opposed to only three people knowing and the rest
finding out one month after fea
On 9/1/06, Bruce Momjian <[EMAIL PROTECTED]> wrote:
I pummelled Jonah over the recursive query patch.
He did. Trust me on this... think I still have some bruises too :)
Neither effort was very fruitful, but tracking wasn't what made
them fail. I am not saying tracking is wrong, but rather t
Peter Eisentraut wrote:
> Alvaro Herrera wrote:
> > Another novel idea: have a "bugtracker" of sorts where selected
> > people can add "feature requests" and append patches to them. There,
> > people could add "fake" feature requests describing the stuff they
> > are working on, and publish the pa
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Well, you can grab items from there and apply them. I will remove
> > them from the mailbox when I see the commit. You have another
> > system that will not be significantly more work? Any you can apply
> > them right from the email lists so th
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Uh, Tom has been tracking Gavin on the bitmap patch every week for
> > weeks, and I pummelled EnterpriseDB/Jonah over the recursive query
> > patch.
>
> Great, but where is this documented, so others know about this?
I see no value in documenting
1 - 100 of 142 matches
Mail list logo
