Open
Bug 1154728
Opened 9 years ago
Updated 1 month ago
Reverse the bug marking order
Categories
(Tree Management :: Bugherder, enhancement, P3)
Tree Management
Bugherder
Tracking
(Not tracked)
NEW
People
(Reporter: RyanVM, Unassigned)
Details
(Whiteboard: [bugherderq4want])
Attachments
(1 file, 1 obsolete file)
Right now, bugs get marked such that the newest revision in the push is the first to get marked. This means that bugs get resolved in reverse chronological order. This can lead to confusion over patch dependencies when doing uplifts and in general just seems counterintuitive. It would make more sense if bugs were marked (and as a result resolved) in the same order they landed.
Reporter | ||
Updated•9 years ago
|
Whiteboard: [bugherderq3want]
Assignee: nobody → wkocher
All of the bug arrays have had .reverse() called on them since the dawn of the repository. Was there a reason for this, Graeme, or can I just not reverse() them anymore? I'm also worried about not reverse()ing the other arrays besides fixes, as I'm not sure what effect this would have on the backout detection. Would it be safe to just not reverse() anything? needinfo@ryan: Do you want the other categories not reverse()d too?
Flags: needinfo?(ryanvm)
Attachment #8646461 -
Flags: feedback?(graeme.mccutcheon)
Comment 2•9 years ago
|
||
Comment on attachment 8646461 [details] [review] PR 27 I think there were two reasons I reversed them: first to mirror hg.m.o/repo/pushloghtml which ran in reverse chronological order. Next, I was aiming to smooth the workflow if a backout was misidentified as a fix due to some peculiarity of the checkin message. If a sheriff encountered the misidentified backout first, they'd simply need to look out for the matching bug fix cset later (in layout, earlier chronologically). In chronological order, you have to stop, search backwards to see if there was a push for the original bug, unset the resolve/comment boxes, and then scroll back down to continue. Really, I was imposing my workflow on others, and I'm not sure misidentified backouts have been a problem in practice; feel free to change. This won't affect backout detection etc. The arrays are reversed after that step. That said, I realised there's an implicit assumption that changesets array in the returned JSON is in chronological order. I think we should consider making that explicit by sorting the array keyed on each element's date field rather than relying on server-side behaviour that may change underneath us.
Attachment #8646461 -
Flags: feedback?(graeme.mccutcheon) → feedback+
Reporter | ||
Comment 3•9 years ago
|
||
I'll defer to Graeme on what makes sense. I just want them to be resolved in the same order that they landed to make uplifting less confusing.
Flags: needinfo?(ryanvm)
Whiteboard: [bugherderq3want] → [bugherderq4want]
Updated•6 years ago
|
Assignee: kwierso → nobody
Updated•5 years ago
|
Priority: -- → P3
Comment hidden (spam) |
Updated•1 month ago
|
Attachment #9383422 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•