How can I check the treatment of bug fixes?

[Magnus Hagander-2]

On Tue, May 31, 2011 at 07:08, Stefan Kaltenbrunner
<[hidden email]> wrote:

> On 05/31/2011 05:42 AM, Tom Lane wrote:
>> Kim Bisgaard <[hidden email]> writes:
>>> On 2011-05-30 04:26, Greg Stark wrote:
>>>> My biggest gripe about bugzilla was that it sent you an email with updates to the bug but you couldn't respond to that email.
>>
>>> Just checked bugzilla's list of features and they *now* lists that as supported:
>>
>>>> File/Modify Bugs By Email
>>>>
>>>> In addition to the web interface, you can send Bugzilla an email that will create a new bug, or will modify an existing bug. You can also
>>>> very easily attach files to bugs this way.
>>
>> The claim is there all right, but the feature seems spectacularly
>> undocumented otherwise.  I wanted to see if it worked like debbugs
>> (ie, you just cc: some mail to the bug tracker), but there's no
>> information about exactly how to use it.
>
> Depends on what exactly you are looking for...
>
> * that feature relies on finding a valid bugid in the subject, if it
> finds one it will add the email ass a comment
> * if you would prefer something like [hidden email]
> for adding to existing bugs, that would be a trivial thing to add as a
> feature(have the MTA split the localpart and pass it as a parameter in
> the pipe-transport to the email_in.pl script)
> * the challenge is more about creating "new" bugs, because for that you
> need a bz account (or maybe a community account in our case) by default.
> We could certainly modify the feature so that it will autocreate bz
> accounts as soon as we see a new emailaddress sending email in but that
> will be fairly hard to control spamwise.

Yikes. (On the very last point there)


But.

I get the feeling we're approaching this backwards. Wouldn't the
normal way to do it be to define the workflow we *want*, and then
figure out which bugtracker works for that or requires the least
changes for that, rather than to try to figure out which bugtracker we
want and then see how much we have to change our workflow to match?
The previous way is kind of what we did with the CF app, and while I
have some things I want fixed in that one they are details - the
process seems to work fine.

So in order to start a brand new bikeshed to paint on, have we even
considered a very trivial workflow like letting the bugtracker
actually *only* track our existing lists and archives. That would
mean:

* Mailing lists are *primary*, and the mailing list archives are
*primary* (yes, this probably requires a fix to the archives, but that
really is a different issue)
* New bugs are added by simply saying "this messageid represents a
thread that has this bug in it", and all the actual contents are
pulled from the archives
* On top of this, the bug just tracks metadata - such as open/closed
more or less. It does *not* track the actual contents at all.
* Bugs registered through the bugs form would of course automatically
add such a messageid into the tracker.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Peter Eisentraut-2]

On mån, 2011-05-30 at 22:17 -0400, Tom Lane wrote:

> Christopher Browne <[hidden email]> writes:
> > On 2011-05-30 4:31 PM, "Peter Eisentraut" <[hidden email]> wrote:
> >> Based on that, and past discussions, and things we've tried in the past,
> >> and gut feeling, and so on, it looks like Request Tracker would appear
> >> to be the next best thing to consider trying out.  What do people think
> >> about that?
>
> > I'd be more optimistic that debbugs, or an adaption thereof, might more
> > nearly fit into the workflow.
>
> Yeah, that's my impression as well.

I'm very familiar with debbugs, so if we'd use that, I would hit the
ground running.

But a few things to consider:

      * You would probably need a lot of manpower to customize and
        maintain this thing.  And you'd be dealing with lots of
        unfamiliar technology.
      * Only very few people in Debian know the internals of this thing,
        so don't expect much timely help.
      * The actual workflow in Debian doesn't only consist of debbugs,
        but a bunch of ad hoc add-ons, additional web interfaces, and
        scripts.  You'd have to adapt or port or replace some of these
        as well.
      * It's not a system set up for easy searching and aggregating, the
        sort of thing an SQL-savvy crowd might expect.  One of the
        better ways nowadays to search for bugs in Debian is actually
        the UDD, which is a dump of the bug database imported into a
        PostgreSQL instance.  See previous point.
      * Actually, a number of teams in Debian use Request Tracker as
        well (see http://wiki.debian.org/rt.debian.org).  I don't know
        why, just saying.



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Peter Eisentraut-2]

On mån, 2011-05-30 at 01:30 -0400, Greg Smith wrote:
> Greg Stark is right that Debbugs has a lot of interesting features
> similar to the desired workflow here.  It's not tied to just Debian
> anymore; the GNU project is also using it now.

For the benefit of others, I suppose you are referring to this:
http://debbugs.gnu.org/

This is actually pretty exciting news, as it alleviates the main concern
with debbugs, that's is in practice impossible to use outside of Debian.
(The other nice thing is that those GNU projects have also been lacking
a good bug tracker in the past.)

Should we find the people behind this project and ask them to share some
experiences?



--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Peter Eisentraut-2]

On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander wrote:
> I get the feeling we're approaching this backwards. Wouldn't the
> normal way to do it be to define the workflow we *want*, and then
> figure out which bugtracker works for that or requires the least
> changes for that, rather than to try to figure out which bugtracker we
> want and then see how much we have to change our workflow to match?

Maybe you are assuming that there is a single workflow that everyone
wants.  So far we know that most people want to work by email and want
to know that a bug is closed.  Is there more detail than that that we
can extract?

> So in order to start a brand new bikeshed to paint on, have we even
> considered a very trivial workflow like letting the bugtracker
> actually *only* track our existing lists and archives. That would
> mean:
>
> * Mailing lists are *primary*, and the mailing list archives are
> *primary* (yes, this probably requires a fix to the archives, but that
> really is a different issue)
> * New bugs are added by simply saying "this messageid represents a
> thread that has this bug in it", and all the actual contents are
> pulled from the archives
> * On top of this, the bug just tracks metadata - such as open/closed
> more or less. It does *not* track the actual contents at all.
> * Bugs registered through the bugs form would of course automatically
> add such a messageid into the tracker.

Well, that is not a workflow either, it's approaching the issue by
proposing an implementation.  Nothing says that an existing or new
system doesn't work exactly like that.  I would be concerned about the
search capabilities of such a system, however.


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Magnus Hagander-2]

On Tue, May 31, 2011 at 11:47, Peter Eisentraut <[hidden email]> wrote:

> On tis, 2011-05-31 at 10:36 +0200, Magnus Hagander wrote:
>> I get the feeling we're approaching this backwards. Wouldn't the
>> normal way to do it be to define the workflow we *want*, and then
>> figure out which bugtracker works for that or requires the least
>> changes for that, rather than to try to figure out which bugtracker we
>> want and then see how much we have to change our workflow to match?
>
> Maybe you are assuming that there is a single workflow that everyone
> wants.  So far we know that most people want to work by email and want
> to know that a bug is closed.  Is there more detail than that that we
> can extract?

Yeah, there might definitely be more than one.

>> So in order to start a brand new bikeshed to paint on, have we even
>> considered a very trivial workflow like letting the bugtracker
>> actually *only* track our existing lists and archives. That would
>> mean:
>>
>> * Mailing lists are *primary*, and the mailing list archives are
>> *primary* (yes, this probably requires a fix to the archives, but that
>> really is a different issue)
>> * New bugs are added by simply saying "this messageid represents a
>> thread that has this bug in it", and all the actual contents are
>> pulled from the archives
>> * On top of this, the bug just tracks metadata - such as open/closed
>> more or less. It does *not* track the actual contents at all.
>> * Bugs registered through the bugs form would of course automatically
>> add such a messageid into the tracker.
>
> Well, that is not a workflow either, it's approaching the issue by
> proposing an implementation.  Nothing says that an existing or new

Um, good point. I still stand by my argument though, even if I'm
arguing against myself :-)

> system doesn't work exactly like that.  I would be concerned about the
> search capabilities of such a system, however.

We already have a search system that works reasonably well for the archives...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[MauMau]

From: "Robert Haas" <[hidden email]>
> It might be useful, in this situation, for the OP to add this patch to
> the CommitFest application.
>
> https://commitfest.postgresql.org/action/commitfest_view/open

"Greg Smith" <[hidden email]> wrote in message
news:[hidden email]...

> Discussion here seems to have wandered far away from useful suggestions
> for you, let's see if that's possible to return to that. Best way to
> confirm when a bug is resolved is to subscribe to the pgsql-committers
> mailing list. If a commit for this fix appears, odds are good the
> original bug number will be referenced. Even if it isn't, you may
> recognize it via its description. Until you see that, the bug is almost
> certainly still open.
>
> Bugs that are considered to impact the current version under development
> are sometimes listed at http://wiki.postgresql.org/wiki/Open_Items
> Adding a bug to there that's not really specific to the new version may
> not be considered good form by some. It is the closest thing to an open
> bug tracker around though, and adding items to there means they won't be
> forgotten about; it's checked regularly by developers considering when
> it's a good time to release another alpha or beta.

Thank you. I understood that it's the best and perhaps only way to search
the pgsql-committers mail archive periodically. I would be happy if some
bug/issue tracker could kindly notify the issuer of status changes via
email.

I'll add my patch to either of CommitFest or Open Items list a few days
later. (But I'm reluctant to pollute those pages with bug fixes which apply
to previous versions. That can't be helped.)

Regards
MauMau


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Andrew Dunstan]

On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> We already have a search system that works reasonably well for the archives...
>

I trust this weas a piece of sarcasm. I spoke to more than a few people
at pgcon and nobody had a good word to say about the search system on
the archives.

cheers

andrew

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Magnus Hagander-2]

On Tue, May 31, 2011 at 14:44, Andrew Dunstan <[hidden email]> wrote:

>
>
> On 05/31/2011 06:41 AM, Magnus Hagander wrote:
>>
>> We already have a search system that works reasonably well for the
>> archives...
>>
>
> I trust this weas a piece of sarcasm. I spoke to more than a few people at
> pgcon and nobody had a good word to say about the search system on the
> archives.

Well, it's tsearch. And I've heard nobody say anything else than that
it's *a lot* better than what we had before.

But sure, it can probably be improved. But what people are then
basically asying is that tsearch isn't good enough for searching.
Which is too bad, but may be so, and in that case we need to fix
*that*, rather than build Yet Another Service To Do The Same Thing
Slightly Differently.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Andrew Dunstan]

On 05/31/2011 04:01 AM, Peter Eisentraut wrote:
> On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote:
>> One of the conclusions the study group came to was that there should
>> be good integration between the tracker system and the SCM. That was
>> in the days before distributed SCMs were common, and in a commercial
>> context, so I'm not sure how well our reasoning would stand up for the
>> current context, but I see it's been mentioned elsewhere and I think
>> it's a significant consideration, at least.
> What kind of functionality would (good) SCM integration provide?
>


Well, the most obvious one is that when a commit (or merge or push) is
made  that fixes a bug, the bug is annotated and its status updated. I
know I've wasted plenty of time in the past first hunting for bugs and
then hunting for the fixes, which aren't always clear from the commit
messages.

In a more centralized system you can also have fairly tightly integrated
workflow (e.g. you can have the tracker open a branch when a bug is
assigned, and you can prevent one being created without an issue being
assigned) but that doesn't seem like such a good fit for us, nor for
anyone using a distributed system like git. You could also argue that
it's a bad thing for commercial organizations, but that's a debate for
another place. The reason we wanted such a thing is that we were
spending significant time managing the workflow issues, and doing tidy up.

cheers

andrew

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Peter Eisentraut-2]

On tis, 2011-05-31 at 08:44 -0400, Andrew Dunstan wrote:
>
> On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> > We already have a search system that works reasonably well for the archives...
> >
>
> I trust this weas a piece of sarcasm. I spoke to more than a few people
> at pgcon and nobody had a good word to say about the search system on
> the archives.

To some degree, the lack of a good search for the archives is half the
problem.  Not that a better search would be a replacement for a bug
tracker, but it would go a long way.


--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Magnus Hagander-2]

On Tue, May 31, 2011 at 15:07, Andrew Dunstan <[hidden email]> wrote:

>
>
> On 05/31/2011 04:01 AM, Peter Eisentraut wrote:
>>
>> On mån, 2011-05-30 at 22:43 -0400, Andrew Dunstan wrote:
>>>
>>> One of the conclusions the study group came to was that there should
>>> be good integration between the tracker system and the SCM. That was
>>> in the days before distributed SCMs were common, and in a commercial
>>> context, so I'm not sure how well our reasoning would stand up for the
>>> current context, but I see it's been mentioned elsewhere and I think
>>> it's a significant consideration, at least.
>>
>> What kind of functionality would (good) SCM integration provide?
>>
>
>
> Well, the most obvious one is that when a commit (or merge or push) is made
>  that fixes a bug, the bug is annotated and its status updated. I know I've
> wasted plenty of time in the past first hunting for bugs and then hunting
> for the fixes, which aren't always clear from the commit messages.

As long as we properly track email, we don't actually need a direct
integration with the SCM for this - since we send the commit message
out to the -committers list anyway, we just need to pick it up there.


> In a more centralized system you can also have fairly tightly integrated
> workflow (e.g. you can have the tracker open a branch when a bug is
> assigned, and you can prevent one being created without an issue being
> assigned) but that doesn't seem like such a good fit for us, nor for anyone
> using a distributed system like git. You could also argue that it's a bad
> thing for commercial organizations, but that's a debate for another place.
> The reason we wanted such a thing is that we were spending significant time
> managing the workflow issues, and doing tidy up.

Yeah, that does sound like a very bad idea *for us*.


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, May 31, 2011 at 02:58:02PM +0200, Magnus Hagander wrote:

> On Tue, May 31, 2011 at 14:44, Andrew Dunstan <[hidden email]> wrote:
> >
> >
> > On 05/31/2011 06:41 AM, Magnus Hagander wrote:
> >>
> >> We already have a search system that works reasonably well for the
> >> archives...
> >>
> >
> > I trust this weas a piece of sarcasm. I spoke to more than a few people at
> > pgcon and nobody had a good word to say about the search system on the
> > archives.
>
> Well, it's tsearch. And I've heard nobody say anything else than that
> it's *a lot* better than what we had before.
>
> But sure, it can probably be improved. But what people are then
> basically asying is that tsearch isn't good enough for searching.
> Which is too bad, but may be so, and in that case we need to fix
> *that*, rather than build Yet Another Service To Do The Same Thing
> Slightly Differently.
>
> --
>  Magnus Hagander
>  Me: http://www.hagander.net/
>  Work: http://www.redpill-linpro.com/
>

I do agree that the current archive search is much, much better than
the searching before the upgrade. I would be interested in taking a
look at some open source projects with a "good" search engine. Most
projects have search engines that are true exercises in frustration
by pulling either apparently everything or next to nothing and nothing
in between. If there is a good one to look at maybe we can do some
tweaking our search engine to improve it.

Regards,
Ken

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Robert Haas]

On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut <[hidden email]> wrote:

> On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote:
>> I have used RT and I found that the
>> web interface was both difficult to use and unwieldly for tickets
>> containing large numbers of messages.  Maybe those those things have
>> been improved, but frankly if RT or Bugzilla is the best we can come
>> up with then I'd rather not have a bug tracker at all.
>
> Given that you have been one of the people calling for a bug tracker,
> and these are the two most widely used systems available, what's wrong
> with them and what else would you suggest?

IIRC, both of them think that you should log into the web interface to
send emails (which, in the case of Bugzilla, don't permit replies),
rather than sending emails that show up in the web interface.  But the
web interface is, at least in RT, also seems to be pretty rudimentary.

Suppose you have a thread with 40 emails in it.  View that thread in
Gmail.  Now view it in RT.  In RT, you will notice that there's no way
to unexpand emails, and all of the data is loaded with the page, so
you sit there for half a minute waiting for everything to load.
There's also no suppression of duplicated or quoted meterial, as Gmail
does.  It's usable, I guess, but it's a long way from
state-of-the-art.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Robert Haas]

On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <[hidden email]> wrote:

> I get the feeling we're approaching this backwards. Wouldn't the
> normal way to do it be to define the workflow we *want*, and then
> figure out which bugtracker works for that or requires the least
> changes for that, rather than to try to figure out which bugtracker we
> want and then see how much we have to change our workflow to match?
> The previous way is kind of what we did with the CF app, and while I
> have some things I want fixed in that one they are details - the
> process seems to work fine.
>
> So in order to start a brand new bikeshed to paint on, have we even
> considered a very trivial workflow like letting the bugtracker
> actually *only* track our existing lists and archives. That would
> mean:
>
> * Mailing lists are *primary*, and the mailing list archives are
> *primary* (yes, this probably requires a fix to the archives, but that
> really is a different issue)
> * New bugs are added by simply saying "this messageid represents a
> thread that has this bug in it", and all the actual contents are
> pulled from the archives
> * On top of this, the bug just tracks metadata - such as open/closed
> more or less. It does *not* track the actual contents at all.
> * Bugs registered through the bugs form would of course automatically
> add such a messageid into the tracker.

That's pretty much exactly what I think would be most useful.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

Andrew Dunstan <[hidden email]> writes:
> On 05/31/2011 06:41 AM, Magnus Hagander wrote:
>> We already have a search system that works reasonably well for the archives...

> I trust this weas a piece of sarcasm. I spoke to more than a few people
> at pgcon and nobody had a good word to say about the search system on
> the archives.

Please note, though, that there is no bug tracker anywhere whose search
mechanism doesn't suck as much or more.  If you're unhappy with the
search stuff the solution is to improve it, not bring in another bad
mechanism.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, May 31, 2011 at 09:33:33AM -0400, Robert Haas wrote:

> On Tue, May 31, 2011 at 4:12 AM, Peter Eisentraut <[hidden email]> wrote:
> > On mån, 2011-05-30 at 21:52 -0400, Robert Haas wrote:
> >> I have used RT and I found that the
> >> web interface was both difficult to use and unwieldly for tickets
> >> containing large numbers of messages.  Maybe those those things have
> >> been improved, but frankly if RT or Bugzilla is the best we can come
> >> up with then I'd rather not have a bug tracker at all.
> >
> > Given that you have been one of the people calling for a bug tracker,
> > and these are the two most widely used systems available, what's wrong
> > with them and what else would you suggest?
>
> IIRC, both of them think that you should log into the web interface to
> send emails (which, in the case of Bugzilla, don't permit replies),
> rather than sending emails that show up in the web interface.  But the
> web interface is, at least in RT, also seems to be pretty rudimentary.
>

If you use the commands-by-email with RT you can do most things with
Email.

> Suppose you have a thread with 40 emails in it.  View that thread in
> Gmail.  Now view it in RT.  In RT, you will notice that there's no way
> to unexpand emails, and all of the data is loaded with the page, so
> you sit there for half a minute waiting for everything to load.
> There's also no suppression of duplicated or quoted meterial, as Gmail
> does.  It's usable, I guess, but it's a long way from
> state-of-the-art.
>
You can adjust what RT will display in the interface and the latest
release does include some enhanced duplicate/quoted material suppression.
Note, I am not pushing for RT necessarily just trying to keep information
available.

Regards,
Ken

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Andrew Dunstan]

On 05/31/2011 09:33 AM, Robert Haas wrote:
> IIRC, both of them think that you should log into the web interface to
> send emails (which, in the case of Bugzilla, don't permit replies),
> rather than sending emails that show up in the web interface.

I think you probably need to look at Bugzilla again. Here's what the
current feature page at <http://www.bugzilla.org/features/#email-in> says:

    In addition to the web interface, you can send Bugzilla an email
    that will create a new bug, or will modify an existing bug.


cheers

andrew

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

Robert Haas <[hidden email]> writes:

> On Tue, May 31, 2011 at 4:36 AM, Magnus Hagander <[hidden email]> wrote:
>> So in order to start a brand new bikeshed to paint on, have we even
>> considered a very trivial workflow like letting the bugtracker
>> actually *only* track our existing lists and archives. That would
>> mean:
>>
>> * Mailing lists are *primary*, and the mailing list archives are
>> *primary* (yes, this probably requires a fix to the archives, but that
>> really is a different issue)
>> * New bugs are added by simply saying "this messageid represents a
>> thread that has this bug in it", and all the actual contents are
>> pulled from the archives
>> * On top of this, the bug just tracks metadata - such as open/closed
>> more or less. It does *not* track the actual contents at all.
>> * Bugs registered through the bugs form would of course automatically
>> add such a messageid into the tracker.

> That's pretty much exactly what I think would be most useful.

I kinda wonder why the CF app doesn't work like that, actually.
(Yeah, I know the poor thread linking in the archives is an issue.)

                        regards, tom lane

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Kevin Grittner]

"[hidden email]" <[hidden email]> wrote:
 
> maybe we can do some tweaking our search engine to improve it.
 
A custom dictionary to carefully add a few synonyms might go a long
way.  I often need to try a number of permutations of likely words
to get relevant hits.
 
Including the subject line in searches, with a higher weight than
message body text, would also be great.
 
Possibly it would help to be able to search on From or To fields
(including CC in the To).  Sometimes you have some recollection who
participated in a discussion, but can't find the magic terms to get
a small result set which includes the right discussion.
 
I really think some pretty minor tweaks in these areas would go a
very long way toward making the archive searches more useful.
 
-Kevin

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Magnus Hagander-2]

On Tue, May 31, 2011 at 16:21, Kevin Grittner
<[hidden email]> wrote:
> "[hidden email]" <[hidden email]> wrote:
>
>> maybe we can do some tweaking our search engine to improve it.
>
> A custom dictionary to carefully add a few synonyms might go a long
> way.  I often need to try a number of permutations of likely words
> to get relevant hits.

If you can provide one, please do :-)
Right now, all we have is:
postgres postgres
postgresql postgres
pgsql postgres
pg postgres
postgre postgres


> Including the subject line in searches, with a higher weight than
> message body text, would also be great.

We already do this - we set them to class "A" with setweight().


> Possibly it would help to be able to search on From or To fields
> (including CC in the To).  Sometimes you have some recollection who
> participated in a discussion, but can't find the magic terms to get
> a small result set which includes the right discussion.

This we don't do -w e store the From field, but we don't index it. And
we don't do anything with the To field.

So that's certainly something we could add.


> I really think some pretty minor tweaks in these areas would go a
> very long way toward making the archive searches more useful.

Any patches are definitely welcome - you can find the search system at
https://pgweb.postgresql.org/browser/trunk/portal/tools/search :-)

(for the archives, you're probably most interested in
classes/ArchiveIndexer.class.php and the sql/functions.sql file)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

--
Sent via pgsql-hackers mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers