Open Bug 1154728 Opened 7 years ago Updated 3 years ago

Reverse the bug marking order


(Tree Management :: Bugherder, enhancement, P3)



(Not tracked)


(Reporter: RyanVM, Unassigned)


(Whiteboard: [bugherderq4want])


(1 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.
No longer depends on: 1154722, 1154724, 1154725
Attached file PR 27
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 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+
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]
Assignee: kwierso → nobody
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.