commitfest.postgresql.org

[Kevin Grittner]

Brendan Jurd <direvus@...> wrote:
 
> Maybe you could describe the symptoms you observed?  Was the
> webserver totally uncontactable, or was it an error in the web app
> itself?
 
When I clicked the link to edit the comment, it clocked until the
browser timed out.  So then I tried the URL for the main page, and it
again clocked until the browser timed out.  I then tried again on the
main page, and it clocked for a minute, so I posted the message about
it being down.  Moments after I sent that, the page came up.
 
If anyone else was hitting the site and it was working, perhaps the
problem could have been elsewhere.  (Our network or our Internet path
to the site could have had some temporary issue.)
 
-Kevin

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

[Peter Eisentraut-2]

On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote:
> 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.

I have the following concern: Likely, this tool and the overall process will
evolve over time.  To pick an example that may or may not be actually useful,
in the future we might want to change from a fixed list of patch sections to a
free list of tags, say.  Then someone might alter the application backend, and
we'd use that new version for the next commit fest at the time.  What will
that do to the data of old commit fests?

With the wiki, the data of the old fests will pretty much stay what is was,
unless we change the wiki templates in drastic ways, as I understand it.  But
if we did changes like the above, or more complicated things, perhaps, what
will happen?  Perhaps we simply don't care about the historical data.  But if
we do, we better have pretty high confidence that the current application will
do for a while or is easily upgradable.


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

[Kevin Grittner]

Peter Eisentraut <peter_e@...> wrote:
 
> in the future we might want to change from a fixed list of patch
> sections to a free list of tags, say.  Then someone might alter the
> application backend, and we'd use that new version for the next
> commit fest at the time.  What will that do to the data of old
> commit fests?
 
Certainly you see how trivial that conversion would be.  If that were
the worst case anyone could even imagine, it would be a pretty strong
argument that the schema is more than good enough to proceed.
 
Do you see anything fundamentally wrong with the structure in terms
of long term goals?
 
-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]

Peter Eisentraut <peter_e@...> writes:
> With the wiki, the data of the old fests will pretty much stay what is
> was, unless we change the wiki templates in drastic ways, as I
> understand it.  But if we did changes like the above, or more
> complicated things, perhaps, what will happen?  Perhaps we simply
> don't care about the historical data.  But if we do, we better have
> pretty high confidence that the current application will do for a
> while or is easily upgradable.

I'm not convinced that we care in the least about commitfests that are
more than a fest or two back; especially since the mailing lists archive
all the interesting underlying data.  However, if we did, the answer
doesn't seem that hard: keep the old database instance on-line for
serving up the old data, and put a new one beside it.

                        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 Jul 7, 2009, at 2:14 PM, Peter Eisentraut <peter_e@...> wrote:

> On Tuesday 07 July 2009 11:29:07 Brendan Jurd wrote:
>> 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.
>
> I have the following concern: Likely, this tool and the overall  
> process will
> evolve over time.  To pick an example that may or may not be  
> actually useful,
> in the future we might want to change from a fixed list of patch  
> sections to a
> free list of tags, say.  Then someone might alter the application  
> backend, and
> we'd use that new version for the next commit fest at the time.  
> What will
> that do to the data of old commit fests?

I don't see this as being much of an obstacle.  I have migrated data  
far more complex, and I venture to say that most of the rest of the  
regular posters in this forum have too.

> With the wiki, the data of the old fests will pretty much stay what  
> is was,
> unless we change the wiki templates in drastic ways, as I understand  
> it.  But
> if we did changes like the above, or more complicated things,  
> perhaps, what
> will happen?  Perhaps we simply don't care about the historical  
> data.  But if
> we do, we better have pretty high confidence that the current  
> application will
> do for a while or is easily upgradable.

I suspect both are true, but in the unlikely event that we decide on  
some massive change to the system, we can either run the DBs in  
parallel as Tom suggests, or dump out the older data in Wiki markup  
and post it on there. But I can't imagine what we'd want to do that  
would even make us consider such drastic steps.  Your example would  
not be a difficult migration, for instance.

...Robert
 

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

[Alvaro Herrera-7]

Robert Haas escribió:

> I suspect both are true, but in the unlikely event that we decide on  
> some massive change to the system, we can either run the DBs in parallel
> as Tom suggests, or dump out the older data in Wiki markup and post it on
> there. But I can't imagine what we'd want to do that would even make us
> consider such drastic steps.  Your example would not be a difficult
> migration, for instance.

By the way, if the migration of the current commitfest was an automatic
procedure, is there a chance that the old commitfests can be migrated as
well?

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
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 Alvaro Herrera <alvherre@...>:
>
> By the way, if the migration of the current commitfest was an automatic
> procedure, is there a chance that the old commitfests can be migrated as
> well?
>

It wasn't really automatic as such.  I used a few scripts that I saved
in case we needed to use them again, but there was also quite a bit of
manual massage of the data required in between those script runs.
There are a few minor incompatibilities, for example the wiki allows
you to put links to the mailing list archives anywhere in a review or
comment with {{messageLink}} but the app has the message-id as a
separate field.  I like the way the data is laid out in the app
better, but it makes it difficult to migrate comments with multiple
{{messageLinks}} in them.

Short answer: I could bring across the old commitfests but it would
take a couple hours at best per commitfest and result in little bits
of data loss here and there.  I think we might be better off just
leaving the closed commitfests up on the wiki, and putting a notice on
the app saying "commitfests prior to July 2009 can be found at
wiki.postgresql.org".

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]

2009/7/8 Peter Eisentraut <peter_e@...>:
> I have the following concern: Likely, this tool and the overall process will
> evolve over time.  To pick an example that may or may not be actually useful,
> in the future we might want to change from a fixed list of patch sections to a
> free list of tags, say.  Then someone might alter the application backend, and
> we'd use that new version for the next commit fest at the time.  What will
> that do to the data of old commit fests?

Same thing that always happens when you make big-picture schema
changes to an app ... you either migrate the data or you leave a
historical instance in place.

NB moving from "topics" to "tags" is *not* a big-picture change and
wouldn't invalidate past data in the slightest.

> With the wiki, the data of the old fests will pretty much stay what is was,
> unless we change the wiki templates in drastic ways, as I understand it.

Actually the wiki makes this more difficult.  Changes to the templates
are limited to adding new keyword arguments.  If you want to, say,
insert a new positional argument into one of the templates, you need
to make a copy of all the affected templates and migrate all existing
template calls to the historical copy.  We had to do this once.  It
wasn't pleasant.

So, even for minor changes to layout (like the "tags" thing you
mentioned) result in having to leave a historical instance of the
system in place.  Whereas having the data in a relational database
makes it far more likely that we can just migrate across small,
incremental changes.

Cheers,
BJ

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

[Alvaro Herrera-7]

Brendan Jurd escribió:

> Short answer: I could bring across the old commitfests but it would
> take a couple hours at best per commitfest and result in little bits
> of data loss here and there.  I think we might be better off just
> leaving the closed commitfests up on the wiki, and putting a notice on
> the app saying "commitfests prior to July 2009 can be found at
> wiki.postgresql.org".

Agreed; if it requires manual work let's leave them in the wiki.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

[Tom Lane-2]

Brendan Jurd <direvus@...> writes:
> 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.

While reorganizing my bookmarks for this I realized that there is a
fairly significant bit of functionality that's entirely missing from
the new app.  With the wiki page, you could conveniently see what had
been done lately by examining the page history.  I don't see any
equivalent capability in the new app.  I find this fairly significant,
as evidenced by the fact that I'd gone so far as to set up a bookmark
for the history view.  I'm not particularly wedded to the wiki page
history in terms of what it looks like or how it functions, but I do
feel a need to know what other people have done recently.

                        regards, tom lane

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

[Dickson S. Guedes-4]

Em Thu, 09 Jul 2009 14:16:41 -0300, Tom Lane <tgl@...> escreveu:
> I'm not particularly wedded to the wiki page
> history in terms of what it looks like or how it functions, but I do
> feel a need to know what other people have done recently.

May be the new app could have a page with a filterable table log with some  
important columns like "who" do "what" on "where" and "when".

This could help, maybe with a RSS in that (like in git).

[]s
Dickson S. Guedes
http://pgcon.postgresql.org.br
http://www.postgresql.org.br

--
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/10 Tom Lane <tgl@...>:
> While reorganizing my bookmarks for this I realized that there is a
> fairly significant bit of functionality that's entirely missing from
> the new app.  With the wiki page, you could conveniently see what had
> been done lately by examining the page history.  I don't see any
> equivalent capability in the new app.

You're right, the app currently lacks a view for this.

And while it would be pretty easy to add a page that just lists the
most recent comments in descending creation order, that would not show
things like

 * patches being committed/rejected/punted;
 * patches changed to a different subsection;
 * changes to a patch's short name;
 * edits to existing comments.

We don't AFAIK collect data about these events.  However, we could
have certain actions trigger the creation of an automated comment
(e.g., "Status changed to Committed by petere") and let the
aforementioned comment view suffice for a "history".

Cheers,
BJ

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

[Joshua Tolley]

On Thu, Jul 09, 2009 at 02:35:04PM -0300, Dickson S. Guedes wrote:
> This could help, maybe with a RSS in that (like in git).

+1 for the RSS feed, if only because I think it sounds neat :)

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

[Robert Haas]

On Jul 9, 2009, at 12:16 PM, Tom Lane <tgl@...> wrote:

> Brendan Jurd <direvus@...> writes:
>> 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.
>
> While reorganizing my bookmarks for this I realized that there is a
> fairly significant bit of functionality that's entirely missing from
> the new app.  With the wiki page, you could conveniently see what had
> been done lately by examining the page history.  I don't see any
> equivalent capability in the new app.  I find this fairly significant,
> as evidenced by the fact that I'd gone so far as to set up a bookmark
> for the history view.  I'm not particularly wedded to the wiki page
> history in terms of what it looks like or how it functions, but I do
> feel a need to know what other people have done recently

I'll fix this. Give me a couple days; my Internet access here at the  
family vacation spot is not compatible with "git push".

...Robert

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

[Josh Berkus]

> We don't AFAIK collect data about these events.  However, we could
> have certain actions trigger the creation of an automated comment
> (e.g., "Status changed to Committed by petere") and let the
> aforementioned comment view suffice for a "history".

Can you put in a simple event-recording trigger for all changes?  We can
dress it up for easy viewing later, but if the data isn't collected, it
will be impossible to recreate.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

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

[Tom Lane-2]

Josh Berkus <josh@...> writes:
>> We don't AFAIK collect data about these events.  However, we could
>> have certain actions trigger the creation of an automated comment
>> (e.g., "Status changed to Committed by petere") and let the
>> aforementioned comment view suffice for a "history".

> Can you put in a simple event-recording trigger for all changes?

+1.  Just add an event log table.  I think we'll wish we had one later.

                        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/10 Josh Berkus <josh@...>:

>
>> We don't AFAIK collect data about these events.  However, we could
>> have certain actions trigger the creation of an automated comment
>> (e.g., "Status changed to Committed by petere") and let the
>> aforementioned comment view suffice for a "history".
>
> Can you put in a simple event-recording trigger for all changes?  We can
> dress it up for easy viewing later, but if the data isn't collected, it will
> be impossible to recreate.
>

I could, but a db trigger would have no awareness of which user made
the change.  That would make the information substantially less useful
IMO.

I've got access to the database but I'm not in a position to make
changes to the app frontend.  I'm therefore inclined to wait the
prophesied couple days for Robert's proper fix for this problem than
dropping in a trigger which will only tell us part of the story.

Bear in mind that CF activity over the past week has been in the realm
of 0-4 changes per 24 hours, so it's not like we are talking about
huge amounts of throughput here.  Making up the bulk of those changes
were new patches coming in (which involves adding a comment so the
change is already tracked) and patches getting committed (which is
stored in -hackers and version control anyway).

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]

Brendan Jurd <direvus@...> writes:
> Bear in mind that CF activity over the past week has been in the realm
> of 0-4 changes per 24 hours, so it's not like we are talking about
> huge amounts of throughput here.

Well, it'll be more once commitfest actually starts, but in any case
it's not going to be enough to make a log table be a resource hog.

                        regards, tom lane

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

[Decibel!]

On Jul 9, 2009, at 12:35 PM, Brendan Jurd wrote:
> We don't AFAIK collect data about these events.  However, we could
> have certain actions trigger the creation of an automated comment
> (e.g., "Status changed to Committed by petere") and let the
> aforementioned comment view suffice for a "history".


Our main system at work does that; any kind of status is stored as a  
raw, text "note". It sucks. It makes trying to query for specific  
kinds of events difficult, and it wastes a bunch of space.

It's a lot better to record machine-readable information for machine-
created events. If you want to present it all as one, I suggest a  
union view that turns the machine-understood data into a human-
understandable text format.
--
Decibel!, aka Jim C. Nasby, Database Architect  decibel@...
Give your computer some brain candy! www.distributed.net Team #1828



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

[Josh Berkus]

 >>  I think we might be better off just
>> leaving the closed commitfests up on the wiki, and putting a notice on
>> the app saying "commitfests prior to July 2009 can be found at
>> wiki.postgresql.org".

+1.  That's why we're switching technogies at the beginning of a dev cycle.


--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

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