commitfest.postgresql.org

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Peter Eisentraut-2]

On Saturday 04 July 2009 01:19:23 Joshua D. Drake wrote:
> On Fri, 2009-07-03 at 17:57 -0400, Robert Haas wrote:
> > I guess I'm not really seeing why that particular thing should be a
> > button rather than a link.  It would mess up the formatting for no
> > obvious benefit.
>
> Not arguing one way or the other, a button says, "I am about to perform
> X". A link *always* says, "I am about to go to a new web page".

That was my feeling.

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

[Dimitri Fontaine-3]

Le 5 juil. 09 à 00:13, Peter Eisentraut a écrit :
> On Saturday 04 July 2009 01:19:23 Joshua D. Drake wrote:
>> Not arguing one way or the other, a button says, "I am about to  
>> perform
>> X". A link *always* says, "I am about to go to a new web page".
>
> That was my feeling.

And bots (google etc) will follow links.
--
dim
--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Robert Haas]

On Jul 4, 2009, at 5:18 PM, Dimitri Fontaine <dfontaine@...>  
wrote:

> Le 5 juil. 09 à 00:13, Peter Eisentraut a écrit :
>> On Saturday 04 July 2009 01:19:23 Joshua D. Drake wrote:
>>> Not arguing one way or the other, a button says, "I am about to  
>>> perform
>>> X". A link *always* says, "I am about to go to a new web page".
>>
>> That was my feeling.
>
> And bots (google etc) will follow links.

They won't log in, though. :-)

Someone want to write a patch, then?

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

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Kevin Grittner]

Peter Eisentraut <peter_e@...> wrote:
> On Saturday 04 July 2009 01:19:23 Joshua D. Drake wrote:
>> a button says, "I am about to perform X".
>> A link *always* says, "I am about to go to a new web page".
>
> That was my feeling.
 
In addition, if the action will be preceded by a dialog (for options
or confirmation) the button text should end with '...'.
 
-Kevin

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

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[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-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Chris Browne]

robertmhaas@... (Robert Haas) writes:
> 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.

We had an ancient version of Bugzilla in use for quite a while; it was
*SO* vastly different from modern versions that it wasn't remotely
plausible to port the data from the old instance to a new one.

I went and ran "wget" to pull all the contents of the old instance,
turning that into a series of static web pages.  No longer updatable,
but certainly browsable.

Once a CommitFest is complete, I could easily see making a summary of
it, as a series of static web pages.  No need for a database anymore
altogether ;-).
--
select 'cbbrowne' || '@' || 'linuxfinances.info';
http://linuxdatabases.info/info/spreadsheets.html
I'd give my right arm to be ambidextrous!

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