Re: New CF app deployment

On Mon, Jan 26, 2015 at 4:01 PM, Magnus Hagander <magnus@hagander.net> wrote:
> According to my mailbox, you didn't even respond on that thread. But it may
> well be that your email ended up on some other thread and therefor was not
> included when I went back and looked over all the responses I got on it. If
> that was the case, then I apologize for loosing track of the feedback.

I remember bringing it up at PGCon, I think.  I don't know whether I
wrote it in an email.

> The "most recent activity on the summary page" is on my short-term todo list
> to fix. The past couple of days have been a bit too busy to get that done
> though, mainly due to the upcoming FOSDEM and pgday events. But rest assured
> that part is definitely on the list, as it doesn't actually change any
> functionality, it's just a view. Same as that "quick stats numbers" thing on
> the frontpage of each cf.

OK.  What I'd like to understand is why this new app had to be rolled
out before these things were done.  We've been using my app for 5
years and it, like, worked.  So why the rush to roll it out with these
known issues unfixed?  I mean, it's not like you couldn't look at any
time and see what the new app lacked that the old app had.  The last
time you presented this app for feedback, which I remember to be
PGCon, it was so buggy that there was no point in trying to form any
considered opinion of it.  Now, it's rolled out, but with a bunch of
stuff that people use and rely on missing.  I grant that some of those
things you may not have realized anyone cared about, but it feels to
me like this got pushed into production without really getting it to
feature parity.  I could've spent more of my time complaining about
that than I did, but why should I have to do that?

> As for being able to flag more things on individual emails/patches, I am
> definitely not against that in principle, if that's what people prefer. But
> I don't think it's unreasonable to give it a few days and then collect
> feedback on that (and other things).

Suit yourself.

> Which of course also includes rolling back the whole thing if people prefer
> the older one - that has been an option on the table from the time we
> decided to give this one a try in the first place. (Though in that case, we
> really need to find a maintainer for that code, as it's we don't seem to
> have that now. But I'm sure that can get sorted)

I understand that having someone who has the time to maintain the code
is an important issue, and I admit I don't, and haven't for a while.
There is a lot of sense in replacing the app with something that uses
the same software framework as the rest of our infrastructure, which I
understand that yours does.  And it's not like what the new one does
is horribly different from what the old one did.  So I don't see that
there's any reason we can't make the new one work.  But I confess to
having no patience with the idea that I have to build a consensus to
get you to re-add features that you removed.  You can take that
position, and since you are the tool maintainer it's not exactly
unfair, but since I was willing to put in the work to add those
features in the first place, I probably think they were worth having.

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