commitfest.postgresql.org

[slakr]

> I *am* using some kind of key.  Specifically, in integer derived from
> a serial column.  It's just as stable as 16 random bytes displayed in
> hex, but a lot shorter and easier to remember, if you're the sort of
> person who likes to remember URLs.  :-)
>

Wasn't aware of exately what you were doing.  It sounded like multiple
things were in the query_string.  If its already a single key, than
there is no need to use a different key.  And no, I don't like
remebering URLs ... thus all the fuss about breaking bookmarks ;-)

 >>>> It's impossible to know that this is commitfest 2009-07.
 >>>>
 >>> commitfest.postgresql.org/2009/07 ?
 >>>
 >>> That, or any similar scheme, seems easily doable with a
 >>> little apache rewrite magic and some programming. See my
 >>> blog urls for one such example.
>> IMHO, I don't see much gain to encoding the date into the url either. This
>> is not a great way of telling the user when something occurred.  A lookup is
>> going to occur either way, so why not get all data at once using a single
>> method?
>
> Sorry, I'm not following this part.

Using a URL to encode when something occurred was being offered as a
solution to know what commitfest it is.  I'm not sure where your
confusion is?

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Robert Haas]

On Fri, Jul 3, 2009 at 3:08 PM, Dimitri Fontaine<dfontaine@...> wrote:
> Your software seems to be better than a wiki, but its potential users are
> expressing needs and bikescheding. I think you'd better accept both kind of
> changes as long as it's not making your life much harder than you'd want.
> Frankly, what URL looks better:
>  http://commitfest.postgresql.org/action/commitfest_view?id=2
>  http://commitfest.postgresql.org/2009/07

We've definitely gotten to the "harder than I'd want" point at this point.

> Oh, and while at it, I don't foresee that we would want the commitfest of
> july 2009 to change its name but not the "semantic" URL pointing to its
> management. Or if it's ever wanted, as has been said, have a look at Apache
> Rewrite Rules system, it's made for supporting content being moved.
> Something in the spirit of:
>  RedirectPermanent /2009/07 /2009/08

I humbly submit that it's insane to thing about editing httpd.conf
every time somebody renames an object.  The point here is to *reduce*
the administrative burden of maintaining this thing.

> While at it, I imagine that within a given commit fest, a single patch will
> have a stable shortname, or if it comes to change, we could accept that the
> URL too change:
>  http://commitfest.postgresql.org/action/patch_view?id=71
>  http://commitfest.postgresql.org/2009/07/Synch_Rep
>  http://commitfest.postgresql.org/current/Synch_Rep
>
> Now, rather than following the names with apache setup, maybe you could add
> something like some history tables tracking short name changes (maybe some
> ON UPDATE trigger would do), so that referring to an older name would send a
> HTTP 302 redirect to the new name URL?

So, the good thing about the current system is that the URL *doesn't*
change and you *don't* need complicated bookkeeping to remember every
URL you've ever assigned to the thing to get it.  I am well aware that
it's possible to design a system that does this, but what benefit do
we get out of it?  Making it possible to tell what a URL points to
without clicking on it, for those occasions when you're stranded on a
desert island with a URL and no Internet access?

There's a subtle and pernicious danger of the system you're proposing,
too.  If we regularly change the URLs that refer to certain objects,
but compensate for that by remembering the whole history of URLs that
have ever referred to that object, then there will multiple URLs that
refer to the same object, of which all but one will contain WRONG
information about what that link points to.  The
http://commitfest.postgresql.org/2009/07/Sync_Rep link, for example,
might imply to someone that the patch is in the 2009-07 commitfest,
but in fact it may well have been moved to the 2009-11, 2010-01, or
2010-03 commitfest, or we might have finally come to our senses and
realized that it ought to be called "streaming rep" and rename it.

It's true that the current URLs, without some sort of accompanying
text, do not tell you what they point to.  But no information can
often be better than disinformation.

> I'd like your work to be useful for all of us and appreciated to its real
> value, and those changes well seem like user interface improvements rather
> than basic structure or behavior questioning.

I'd like that, too.

...Robert

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Robert Haas]

On Fri, Jul 3, 2009 at 3:15 PM, Andrew Chernow<ac@...> wrote:

>> I *am* using some kind of key.  Specifically, in integer derived from
>> a serial column.  It's just as stable as 16 random bytes displayed in
>> hex, but a lot shorter and easier to remember, if you're the sort of
>> person who likes to remember URLs.  :-)
>>
>
> Wasn't aware of exately what you were doing.  It sounded like multiple
> things were in the query_string.  If its already a single key, than there is
> no need to use a different key.  And no, I don't like remebering URLs ...
> thus all the fuss about breaking bookmarks ;-)

Right.  The current system has exactly ZERO chance of breaking any
bookmarks, and all of the proposed alternatives are much more likely
to do so.

>>>>> It's impossible to know that this is commitfest 2009-07.
>>>>>
>>>> commitfest.postgresql.org/2009/07 ?
>>>>
>>>> That, or any similar scheme, seems easily doable with a
>>>> little apache rewrite magic and some programming. See my
>>>> blog urls for one such example.
>>>
>>> IMHO, I don't see much gain to encoding the date into the url either.
>>> This
>>> is not a great way of telling the user when something occurred.  A lookup
>>> is
>>> going to occur either way, so why not get all data at once using a single
>>> method?
>>
>> Sorry, I'm not following this part.
>
> Using a URL to encode when something occurred was being offered as a
> solution to know what commitfest it is.  I'm not sure where your confusion
> is?

The suggestion was to encode the start date of the CommitFest in the
URL, instead of using a non-natural key.

...Robert

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Tom Lane-2]

Robert Haas <robertmhaas@...> writes:
> Backing up for a moment to ten thousand feet here, I posted a link to
> this web app on May 26th.  I received several comments on it, all of
> them positive, including some constructive feedback from you which I
> took to heart.  It is now July 1st, and I am trying very hard to get
> ready for the next CommitFest, which I have agreed to manage.  So I
> need to determine whether there is some finite number of changes of
> manageable size that I can make to get this to a state where we can
> use it, or whether I should give up hope now and go back to the wiki.

I think it's probably fixable, if you've got some time to put into it
between now and the 15th.  What's being griped about is user interface
details, and it's not surprising that you as the author didn't see
these things the same way a new user would.  From what I've been able to
see, the underlying functionality is mostly there, but it needs some
usability/presentation tweaking.

> I accept the need for and am willing to make the following changes:

> - Changing the patch comment field from type text to type textarea and
> integrating it into the patch view page to provide context.
> - Adding a note to the effect that the message ID is optional.
> - Adding stable links with mnemonic names for the open, in progress,
> and most recently closed commitfests.

> With respect to the issue of the page URLs, I'm very unconvinced of
> the value of making a change.

Given your item 3 above, I think we can live with the URLs otherwise.

One other thing I was noticing is that the items for a particular patch
seem to be listed in reverse date order.  Personally I find this strange
and would prefer newest-at-the-bottom --- in particular, having the
patch itself at the bottom doesn't seem especially usable.  We might
need to take a vote on that though, since I suppose some people like
newest-at-the-top.

                        regards, tom lane

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Robert Haas]

On Fri, Jul 3, 2009 at 3:27 PM, Tom Lane<tgl@...> wrote:

> Robert Haas <robertmhaas@...> writes:
>> Backing up for a moment to ten thousand feet here, I posted a link to
>> this web app on May 26th.  I received several comments on it, all of
>> them positive, including some constructive feedback from you which I
>> took to heart.  It is now July 1st, and I am trying very hard to get
>> ready for the next CommitFest, which I have agreed to manage.  So I
>> need to determine whether there is some finite number of changes of
>> manageable size that I can make to get this to a state where we can
>> use it, or whether I should give up hope now and go back to the wiki.
>
> I think it's probably fixable, if you've got some time to put into it
> between now and the 15th.  What's being griped about is user interface
> details, and it's not surprising that you as the author didn't see
> these things the same way a new user would.  From what I've been able to
> see, the underlying functionality is mostly there, but it needs some
> usability/presentation tweaking.

Thanks, that is really good news.  I agree that the presentation and
usability need some work and I'm trying to address those concerns as
expediently as I can.  Part of my angst is that I am going to have
only sporadic Internet access for the next week, so what I can't get
done today (while my wife wonders why I am doing a second job on a
holiday for no money) probably isn't going to happen for a bit, and I
would like to get cut over so that Brendan doesn't have to keep
manually replicating changes between the systems.  I will see if I can
make the changes below happen today.

>> I accept the need for and am willing to make the following changes:
>
>> - Changing the patch comment field from type text to type textarea and
>> integrating it into the patch view page to provide context.
>> - Adding a note to the effect that the message ID is optional.
>> - Adding stable links with mnemonic names for the open, in progress,
>> and most recently closed commitfests.
>
>> With respect to the issue of the page URLs, I'm very unconvinced of
>> the value of making a change.
>
> Given your item 3 above, I think we can live with the URLs otherwise.

/me feels like he has dodged a bullet.

> One other thing I was noticing is that the items for a particular patch
> seem to be listed in reverse date order.  Personally I find this strange
> and would prefer newest-at-the-bottom --- in particular, having the
> patch itself at the bottom doesn't seem especially usable.  We might
> need to take a vote on that though, since I suppose some people like
> newest-at-the-top.

I think it IS newest at the bottom, and I agree that that is how it
should be.  24 hours ago it was alpha by topic and then alpha by patch
name, but now it is topic by sortorder, then topic by name, then patch
by ascending ID number (which works out to newest at the bottom).  I
thought the other way would be OK, but after Brendan and I imported
the data we both said "that sucks", so it got changed last night
around midnight Eastern +/- an hour.

One of the things that I would like to add in the future is the
ability to assign a patch a shortname.  This would be useful for
building command-line tools to interface with the system, e.g.
download the sepgsql patch.  The idea would be that these names would
be stable, though of course it's hard to see how to guarantee that
100%.  I am still trying to work out in my mind how best to set that
up, though, so it's probably not going to happen right away unless
someone else is prepared to do some of the legwork.

...Robert

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Kevin Grittner]

Robert Haas <robertmhaas@...> wrote:
 
> I think it IS newest at the bottom, and I agree that that is how it
> should be.
 
It seems to be inconsistent.  Probably because everything wound up
with the same date, the order is probably more-or-less random.  What
are the chances that the date or timestamp of the corresponding wiki
modification could be put onto the patch and comment lines?  (One
would hope that could be done with a script, rather than by hand....)
 
-Kevin

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Tom Lane-2]

"Kevin Grittner" <Kevin.Grittner@...> writes:
> Robert Haas <robertmhaas@...> wrote:
>> I think it IS newest at the bottom, and I agree that that is how it
>> should be.
 
> It seems to be inconsistent.  Probably because everything wound up
> with the same date, the order is probably more-or-less random.

Yeah, I think that's what I'm seeing.

> What
> are the chances that the date or timestamp of the corresponding wiki
> modification could be put onto the patch and comment lines?  (One
> would hope that could be done with a script, rather than by hand....)

Currently, it seems that most or all of the entries are links to
archived messages.  Scraping the date from the underlying message
would be the best thing.

                        regards, tom lane

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Kevin Grittner]

Tom Lane <tgl@...> wrote:
 
> Currently, it seems that most or all of the entries are links to
> archived messages.  Scraping the date from the underlying message
> would be the best thing.
 
Just for purposes of conversion, or as a long-term behavior?
 
-Kevin

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Tom Lane-2]

"Kevin Grittner" <Kevin.Grittner@...> writes:
> Tom Lane <tgl@...> wrote:
>> Currently, it seems that most or all of the entries are links to
>> archived messages.  Scraping the date from the underlying message
>> would be the best thing.
 
> Just for purposes of conversion, or as a long-term behavior?

Well, right at the moment I was just thinking of the conversion problem,
but it wouldn't be a horrible idea to make it a permanent behavior for
entries that include a message reference.

                        regards, tom lane

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Robert Haas]

On Fri, Jul 3, 2009 at 3:40 PM, Robert Haas<robertmhaas@...> wrote:
>>> I accept the need for and am willing to make the following changes:
>>
>>> - Changing the patch comment field from type text to type textarea and
>>> integrating it into the patch view page to provide context.
>>> - Adding a note to the effect that the message ID is optional.
>>> - Adding stable links with mnemonic names for the open, in progress,
>>> and most recently closed commitfests.

Done.
Done.
Done.

You guys are harder to please than my boss.  He doesn't quite know for
sure which things are possible.  :-)

...Robert

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Robert Haas]

On Fri, Jul 3, 2009 at 4:00 PM, Tom Lane<tgl@...> wrote:
> "Kevin Grittner" <Kevin.Grittner@...> writes:
>> Robert Haas <robertmhaas@...> wrote:
>>> I think it IS newest at the bottom, and I agree that that is how it
>>> should be.
>
>> It seems to be inconsistent.  Probably because everything wound up
>> with the same date, the order is probably more-or-less random.
>
> Yeah, I think that's what I'm seeing.

I think what you guys must be seeing is that the topics are not in
quite the same order.  As far as I can tell, the ordering of patches
within topics is absolutely identical.  If you see a counterexample,
please point it out.  If you want to fix the order of the topics,
click on the "CommitFest Topics" link in the upper lefthand corner of
the page and frobnicate the sort order.

>> What
>> are the chances that the date or timestamp of the corresponding wiki
>> modification could be put onto the patch and comment lines?  (One
>> would hope that could be done with a script, rather than by hand....)
>
> Currently, it seems that most or all of the entries are links to
> archived messages.  Scraping the date from the underlying message
> would be the best thing.

Brendan, is this something that you can work on?  Or does anyone else
have some time to put into it?  And do we have to fix this before we
can declare the new system live, or can we catch up after the fact?
Because replicating changes from the old system to the new is a bit of
a pain in the neck.

...Robert

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Brendan Jurd]

2009/7/4 Robert Haas <robertmhaas@...>:

> On Fri, Jul 3, 2009 at 4:00 PM, Tom Lane<tgl@...> wrote:
>> "Kevin Grittner" <Kevin.Grittner@...> writes:
>>> What
>>> are the chances that the date or timestamp of the corresponding wiki
>>> modification could be put onto the patch and comment lines?  (One
>>> would hope that could be done with a script, rather than by hand....)
>>
>> Currently, it seems that most or all of the entries are links to
>> archived messages.  Scraping the date from the underlying message
>> would be the best thing.
>
> Brendan, is this something that you can work on?

I will take a stab at it.  I think Tom's suggestion of harvesting the
time of the mail message from the archives could do the job.

Cheers,
BJ

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Tom Lane-2]

Robert Haas <robertmhaas@...> writes:
> On Fri, Jul 3, 2009 at 4:00 PM, Tom Lane<tgl@...> wrote:
>> "Kevin Grittner" <Kevin.Grittner@...> writes:
>>> It seems to be inconsistent.  Probably because everything wound up
>>> with the same date, the order is probably more-or-less random.
>>
>> Yeah, I think that's what I'm seeing.

> I think what you guys must be seeing is that the topics are not in
> quite the same order.  As far as I can tell, the ordering of patches
> within topics is absolutely identical.

No, what we're complaining about is the ordering of comments for a
single patch.  If you look at
http://commitfest.postgresql.org/action/commitfest_view?id=2
in some cases there are Comments before the Patch itself, and in
some cases after, but more often than not the original Patch is
at the bottom.

                        regards, tom lane

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Brendan Jurd]

2009/7/4 Tom Lane <tgl@...>:
> No, what we're complaining about is the ordering of comments for a
> single patch.

Now moot, since I've successfully pulled the dates for all comments
with a message-id from the archives, and updated the database
accordingly.

Cheers,
BJ

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Robert Haas]

On Jul 3, 2009, at 11:56 PM, Tom Lane <tgl@...> wrote:

> Robert Haas <robertmhaas@...> writes:
>> On Fri, Jul 3, 2009 at 4:00 PM, Tom Lane<tgl@...> wrote:
>>> "Kevin Grittner" <Kevin.Grittner@...> writes:
>>>> It seems to be inconsistent.  Probably because everything wound up
>>>> with the same date, the order is probably more-or-less random.
>>>
>>> Yeah, I think that's what I'm seeing.
>
>> I think what you guys must be seeing is that the topics are not in
>> quite the same order.  As far as I can tell, the ordering of patches
>> within topics is absolutely identical.
>
> No, what we're complaining about is the ordering of comments for a
> single patch.  If you look at
> http://commitfest.postgresql.org/action/commitfest_view?id=2
> in some cases there are Comments before the Patch itself, and in
> some cases after, but more often than not the original Patch is
> at the bottom.

Oh, duh.  I totally missed that.

...Robert

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Brendan Jurd]

2009/7/3 Robert Haas <robertmhaas@...>:
> The application stamps comments with the
> community login of the person who left them, but the import stamped
> them with names instead.  This is actually of some significance, since
> the app will allow you to edit your own comments but not those of
> other people.  We could probably fix this if someone can give us
> access to (or a dump of) the realname to username mappings from the
> community login DB.

Nobody came forward with a mapping of real names to community logins,
so I went ahead and did this the dumb, slow way (eyeballing the wiki
history and manually creating a mapping for the names we have in the
commitfest app so far).

I've updated the patch comment creator field with the login names I
was able to map, but there are a few contributors who either don't
have a community login, or haven't used the wiki.  In those cases I
left the name as-is.

You should now be able to edit comments that you created.  If you
think you should be able to edit a comment, but you can't because the
login name is wrong, let me know and I'll fix it up.

Cheers,
BJ

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Brendan Jurd]

Hi folks,

We're now about a week away from the start of the July 2009
commitfest, and we need to make a decision about whether to start
using http://commitfest.postgresql.org to manage it, or punt to the
next commitfest and continue to use the wiki for July.

Robert and I have been upgrading the app in response to the feedback
so far, and personally I think the app is already a far superior tool
to the wiki for managing a commitfest.  I think we should use it for
2009-07.

What we need in order to proceed is:
 a) a viable consensus from patch reviewers/committers to switch over,
 b) an email out to -hackers about the new app,
 c) updates to the wiki developer pages pointing to the new app, and
 d) decommissioning the wiki July CF.

I can do b), c) and d) but I could use your help in obtaining a).

If you think we should switch over, please say so.

If you think the app needs some tweaking, please say so but let's
switch over anyway and make those tweaks as we go.

If you think the app is fundamentally less useful than the wiki,
please say so and we'll work out whether we can resolve your objection
in time for the start of the CF.

Thanks in advance for your comments.

Cheers,
BJ

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Kevin Grittner]

Brendan Jurd <direvus@...> wrote:
 
> If you think the app is fundamentally less useful than the wiki,
> please say so and we'll work out whether we can resolve your
> objection in time for the start of the CF.
 
It's been down for a while now.  I don't know if this is causal, but
the failure seemed to start when I went into the patch I submitted,
and clicked on the link to edit a comment I added.
 
At any rate, the reliability doesn't seem to match the wiki yet, which
would seem to be a pretty fundamental thing to fix before switching.
 
-Kevin

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Kevin Grittner]

Brendan Jurd <direvus@...> wrote:
 
> If you think the app is fundamentally less useful than the wiki,
> please say so and we'll work out whether we can resolve your
> objection in time for the start of the CF.
 
Oh, sure -- I post about it being down, and seconds after I hit send
it comes up again.   :-/
 
Do we know that cause?
 
-Kevin

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www

[Brendan Jurd]

2009/7/8 Kevin Grittner <Kevin.Grittner@...>:
> Oh, sure -- I post about it being down, and seconds after I hit send
> it comes up again.   :-/
>
> Do we know that cause?

Well, no, since I've never observed it being "down" and I really have
no idea what you mean by that.

Maybe you could describe the symptoms you observed?  Was the webserver
totally uncontactable, or was it an error in the web app itself?

Cheers,
BJ

--
Sent via pgsql-www mailing list (pgsql-www@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www