Thread: CF app feature request
Yesterday Fabien and I submitted the same item to the Commitfest (1859 and 1860). Unfortunately there doesn't seem to be any way for one of these to be withdrawn. "Rejected" and "Returned with Feedback" seem wrong. Ideally, there would be a way for someone who submits an item in error to withdraw it, at which point it should be as if it had never been submitted. Meanwhile, what's the advice about how to deal with these? cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Nov 1, 2018 at 2:44 PM Andrew Dunstan <andrew.dunstan@2ndquadrant.com> wrote:
Yesterday Fabien and I submitted the same item to the Commitfest (1859
and 1860). Unfortunately there doesn't seem to be any way for one of
these to be withdrawn. "Rejected" and "Returned with Feedback" seem
wrong. Ideally, there would be a way for someone who submits an item in
error to withdraw it, at which point it should be as if it had never
been submitted.
Meanwhile, what's the advice about how to deal with these?
Are you thinking basically another status that's "Withdrawn", but keeping it, or actually removing the records completely?
//Magnus
On 11/01/2018 05:50 PM, Magnus Hagander wrote: > > > On Thu, Nov 1, 2018 at 2:44 PM Andrew Dunstan > <andrew.dunstan@2ndquadrant.com > <mailto:andrew.dunstan@2ndquadrant.com>> wrote: > > > Yesterday Fabien and I submitted the same item to the Commitfest > (1859 > and 1860). Unfortunately there doesn't seem to be any way for one of > these to be withdrawn. "Rejected" and "Returned with Feedback" seem > wrong. Ideally, there would be a way for someone who submits an > item in > error to withdraw it, at which point it should be as if it had never > been submitted. > > Meanwhile, what's the advice about how to deal with these? > > > Are you thinking basically another status that's "Withdrawn", but > keeping it, or actually removing the records completely? > > I don't know enough about the app internals to comment. But it probably shouldn't appear in the stats, or else should have its own category in the stats. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 11/01/2018 05:50 PM, Magnus Hagander wrote:
>> Are you thinking basically another status that's "Withdrawn", but
>> keeping it, or actually removing the records completely?
> I don't know enough about the app internals to comment. But it probably
> shouldn't appear in the stats, or else should have its own category in
> the stats.
A separate "Withdrawn" status seems like it'd cover more cases than
a "make like it never happened" action.
regards, tom lane
On Thu, Nov 01, 2018 at 05:56:24PM -0400, Andrew Dunstan wrote: > On 11/01/2018 05:50 PM, Magnus Hagander wrote: >> Are you thinking basically another status that's "Withdrawn", but >> keeping it, or actually removing the records completely? > > I don't know enough about the app internals to comment. But it probably > shouldn't appear in the stats, or else should have its own category in the > stats. Or that's closer to "Rejected by the author himself"? "Withdrawn" sounds like a good term for that, we surely don't want to simply remove the thing entirely either. What's actually the issue with not tracking such things in the stats? -- Michael
Attachment
On 11/01/2018 08:40 PM, Michael Paquier wrote: > On Thu, Nov 01, 2018 at 05:56:24PM -0400, Andrew Dunstan wrote: >> On 11/01/2018 05:50 PM, Magnus Hagander wrote: >>> Are you thinking basically another status that's "Withdrawn", but >>> keeping it, or actually removing the records completely? >> I don't know enough about the app internals to comment. But it probably >> shouldn't appear in the stats, or else should have its own category in the >> stats. > Or that's closer to "Rejected by the author himself"? "Withdrawn" > sounds like a good term for that, we surely don't want to simply remove > the thing entirely either. What's actually the issue with not tracking > such things in the stats? I don't have a strong opinion. It seemed to me that where something had been created in error it would be best simply to be able to undo that. But I can see arguments against. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>> I don't know enough about the app internals to comment. But it probably >> shouldn't appear in the stats, or else should have its own category in the >> stats. > > Or that's closer to "Rejected by the author himself"? "Withdrawn" > sounds like a good term for that, we surely don't want to simply remove > the thing entirely either. What's actually the issue with not tracking > such things in the stats? Because the same patch submission is already counted? It is a rare occurence, so just a "Withdrawn" state could be enough, and slightly false CF stats are no big deal. -- Fabien.
On Fri, Nov 02, 2018 at 08:17:51AM +0100, Fabien COELHO wrote: > Because the same patch submission is already counted? It is a rare > occurence, so just a "Withdrawn" state could be enough, and slightly false > CF stats are no big deal. Or as we are dealing with duplicated entries, perhaps we could just delete the entry not wanted, which seems to be 1859 in this case. Admins can do so. -- Michael
Attachment
Bonjour Michaël, >> Because the same patch submission is already counted? It is a rare >> occurence, so just a "Withdrawn" state could be enough, and slightly false >> CF stats are no big deal. > > Or as we are dealing with duplicated entries, perhaps we could just > delete the entry not wanted, which seems to be 1859 in this case. > Admins can do so. Good. Please proceed! So the solution is to contact an admin (no clear cue about who is an admin, though) to remove the entry. -- Fabien.
On Fri, 2 Nov 2018 at 10:24, Fabien COELHO <coelho@cri.ensmp.fr> wrote: > > > Bonjour Michaël, > > >> Because the same patch submission is already counted? It is a rare > >> occurence, so just a "Withdrawn" state could be enough, and slightly false > >> CF stats are no big deal. > > > > Or as we are dealing with duplicated entries, perhaps we could just > > delete the entry not wanted, which seems to be 1859 in this case. > > Admins can do so. > > Good. Please proceed! > > So the solution is to contact an admin (no clear cue about who is an > admin, though) to remove the entry. Just to make sure, if a duplicated entry will be removed, the patch itself will stay or not? I'm asking, because both entries have the same patch referenced, and the admin form says that one of the related items, that would be removed is the patch item.
On Fri, Nov 02, 2018 at 09:15:36PM +0100, Dmitry Dolgov wrote: > Just to make sure, if a duplicated entry will be removed, the patch itself > will stay or not? I'm asking, because both entries have the same patch > referenced, and the admin form says that one of the related items, that > would be removed is the patch item. If you remove only one entry, its references will be removed but the second one will remain. If you want me to proceed, I can do so. I have done that in the past, and it is not the first time someone registers a duplicated entry in the CF app. -- Michael
Attachment
On Sun, Nov 4, 2018 at 1:28 AM Michael Paquier <michael@paquier.xyz> wrote:
On Fri, Nov 02, 2018 at 09:15:36PM +0100, Dmitry Dolgov wrote:
> Just to make sure, if a duplicated entry will be removed, the patch itself
> will stay or not? I'm asking, because both entries have the same patch
> referenced, and the admin form says that one of the related items, that
> would be removed is the patch item.
If you remove only one entry, its references will be removed but the
second one will remain. If you want me to proceed, I can do so. I have
done that in the past, and it is not the first time someone registers a
duplicated entry in the CF app.
I'm trying to figure out where this thread left off :) My understanding of the consensus is we don't actually want/need a change in the app, but are instead OK with the admin just handling it a somewhat ugly way in the few cases where it's necessary?
Or is the consensus to add a "Withdrawn" status, just to solve a slightly different problem from the one that started this thread?
Magnus Hagander <magnus@hagander.net> writes:
> I'm trying to figure out where this thread left off :) My understanding of
> the consensus is we don't actually want/need a change in the app, but are
> instead OK with the admin just handling it a somewhat ugly way in the few
> cases where it's necessary?
The original case (just a mistakenly duplicated entry) seems OK to solve
with a quick DELETE on the underlying table.
> Or is the consensus to add a "Withdrawn" status, just to solve a slightly
> different problem from the one that started this thread?
I think there is a use-case for "Withdrawn", it's more polite than
"Rejected" ;-). But it's not a very high-priority request.
regards, tom lane
On 2018-Nov-20, Tom Lane wrote: > I think there is a use-case for "Withdrawn", it's more polite than > "Rejected" ;-). But it's not a very high-priority request. Certainly not higher than having the dropdown for entry author/reviewer be sorted alphabetically ... *wink* *wink* -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Nov 20, 2018 at 03:30:38PM -0300, Alvaro Herrera wrote: > On 2018-Nov-20, Tom Lane wrote: > Certainly not higher than having the dropdown for entry author/reviewer > be sorted alphabetically ... *wink* *wink* More *wink* *wink* -- Michael
Attachment
On Wed, Nov 21, 2018 at 12:52 AM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Nov 20, 2018 at 03:30:38PM -0300, Alvaro Herrera wrote:
> On 2018-Nov-20, Tom Lane wrote:
> Certainly not higher than having the dropdown for entry author/reviewer
> be sorted alphabetically ... *wink* *wink*
More *wink* *wink*
Here's a slightly late response to that winking :P
They *are* sorted. By lastname. Should I take all this winking to mean that people would prefer them being sorted by firstname? :)
On Tue, Nov 20, 2018 at 7:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Magnus Hagander <magnus@hagander.net> writes:
> I'm trying to figure out where this thread left off :) My understanding of
> the consensus is we don't actually want/need a change in the app, but are
> instead OK with the admin just handling it a somewhat ugly way in the few
> cases where it's necessary?
The original case (just a mistakenly duplicated entry) seems OK to solve
with a quick DELETE on the underlying table.
> Or is the consensus to add a "Withdrawn" status, just to solve a slightly
> different problem from the one that started this thread?
I think there is a use-case for "Withdrawn", it's more polite than
"Rejected" ;-). But it's not a very high-priority request.
Status "Withdrawn" has now been added.
On 2018-Dec-23, Magnus Hagander wrote: > On Wed, Nov 21, 2018 at 12:52 AM Michael Paquier <michael@paquier.xyz> > wrote: > > > On Tue, Nov 20, 2018 at 03:30:38PM -0300, Alvaro Herrera wrote: > > > On 2018-Nov-20, Tom Lane wrote: > > > Certainly not higher than having the dropdown for entry author/reviewer > > > be sorted alphabetically ... *wink* *wink* > > > > More *wink* *wink* > > Here's a slightly late response to that winking :P > > They *are* sorted. By lastname. Should I take all this winking to mean that > people would prefer them being sorted by firstname? :) Oh, wow. That's not at all obvious ... the fact that there's Scherbaum as the first entry, and Wang at the fifth position, threw me off. I can find entries easily enough knowing this. But I think it would make more sense to order by the complete string that makes up the name. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sun, Dec 23, 2018 at 3:59 PM Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2018-Dec-23, Magnus Hagander wrote:
> On Wed, Nov 21, 2018 at 12:52 AM Michael Paquier <michael@paquier.xyz>
> wrote:
>
> > On Tue, Nov 20, 2018 at 03:30:38PM -0300, Alvaro Herrera wrote:
> > > On 2018-Nov-20, Tom Lane wrote:
> > > Certainly not higher than having the dropdown for entry author/reviewer
> > > be sorted alphabetically ... *wink* *wink*
> >
> > More *wink* *wink*
>
> Here's a slightly late response to that winking :P
>
> They *are* sorted. By lastname. Should I take all this winking to mean that
> people would prefer them being sorted by firstname? :)
Oh, wow. That's not at all obvious ... the fact that there's Scherbaum
as the first entry, and Wang at the fifth position, threw me off.
Oh, there isn't, there's "ads Scherbaum" as his last name. I'm pretty sure he does that just to mess with people. And for the second one, it's Alexandra... But yes, I agree it's confusing, especially when you start mixing in cultures that may not have firstname/lastname working in the way that we do in the western world.
I can find entries easily enough knowing this. But I think it would
make more sense to order by the complete string that makes up the name.
Ok, I've pushed a change to do first_name sorting instead. Let's see if that causes less or more confusion :) But it will at least match the "full string sorting".