Thread: About that CommitFest redirect page ...

About that CommitFest redirect page ...

From
Tom Lane
Date:
So according to
http://wiki.postgresql.org/index.php?title=CommitFest&action=history
there's been rather a lot of confusion about where the CommitFest
redirect page should point when.

I think the problem is that we need two redirect pages: one for "the
place where you should submit a new patch" and one for "the commitfest in
progress".  The problem is to choose names that will make it reasonably
obvious which is which.

Another possibility is to convert CommitFest to a plain page with
suitably-explained links leading to the two relevant pages.  However,
a redirect would be nicer because you could bookmark it.

Ideas?
        regards, tom lane


Re: About that CommitFest redirect page ...

From
Alvaro Herrera
Date:
Tom Lane wrote:
> So according to
> http://wiki.postgresql.org/index.php?title=CommitFest&action=history
> there's been rather a lot of confusion about where the CommitFest
> redirect page should point when.
> 
> I think the problem is that we need two redirect pages: one for "the
> place where you should submit a new patch" and one for "the commitfest in
> progress".  The problem is to choose names that will make it reasonably
> obvious which is which.

I suggest two redirects CommitFestInProgress and CommitFestOpen, and
turning CommitFest into a plain page with suitable text pointing to both
redirects.

We'd also need a page saying "there is no commitfest currently in
progress; maybe you wanted to go to CommitFestOpen instead?" to point
the CommitFestInProgress to in the period between commitfests.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


Re: About that CommitFest redirect page ...

From
Tom Lane
Date:
Alvaro Herrera <alvherre@commandprompt.com> writes:
> I suggest two redirects CommitFestInProgress and CommitFestOpen, and
> turning CommitFest into a plain page with suitable text pointing to both
> redirects.

> We'd also need a page saying "there is no commitfest currently in
> progress; maybe you wanted to go to CommitFestOpen instead?" to point
> the CommitFestInProgress to in the period between commitfests.

Works for me ...
        regards, tom lane


Re: About that CommitFest redirect page ...

From
Peter Eisentraut
Date:
Tom Lane wrote:
> So according to
> http://wiki.postgresql.org/index.php?title=CommitFest&action=history
> there's been rather a lot of confusion about where the CommitFest
> redirect page should point when.
>
> I think the problem is that we need two redirect pages: one for "the
> place where you should submit a new patch" and one for "the commitfest in
> progress".  The problem is to choose names that will make it reasonably
> obvious which is which.

Well, when it is commitfest right now, I would like to be able to go to a URL 
that says "commitfest" and then monitor and work on the things there.  Most 
people should be doing that.

The use case for adding things to the next commitfest while a commitfest is 
currently happening much less convincing.  Why would you submit a patch now 
when you still have two months to work on on it and you should be reviewing 
other patches anyway?


Re: About that CommitFest redirect page ...

From
Gregory Stark
Date:
Peter Eisentraut <peter_e@gmx.net> writes:

> The use case for adding things to the next commitfest while a commitfest is 
> currently happening much less convincing.  Why would you submit a patch now 
> when you still have two months to work on on it and you should be reviewing 
> other patches anyway?

Same reason you would send in a patch any other time, because you have a
question and/or want feedback.

Nonetheless I agree that the link to the currently active commitfest is the
one most people would want most of the time. There's a link at the top of the
active commitfest to the currently open commitfest which makes it clear when
to use which.


--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!