974387 - upgrade bmo to upstream trunk

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, defect, P3)

Description

[:glob ✱]

after upstream bugzilla 5.0 has been released, we should upgrade bmo to 5.0.

until then requests can be filed for specific features to be backported, however due to the scope of changes this may not always be possible.

Comment 1

[Ed Morley [:emorley]]

Is there a rough timeframe for this?

Comment 3

[David Lawrence [:dkl]]

Attachment: upstream-merge branch

After much crying and cursing, I have the test suite fully functional for the upstream-merge branch:

https://treeherder.mozilla.org/#/jobs?repo=bmo-upstream-merge&revision=784280a41a67

I feel it is ready for proper review/feedback for any that have time.

dkl

Comment 4

[Dylan Hardison [:dylan] (he/him)]

Looks good so far!

Comment 5

[Dylan Hardison [:dylan] (he/him)]

Comment on attachment 8703242 [details]
upstream-merge branch

Ready to begin UAT on this -- although we also need to re-uplift patches from master, right?

Comment 6

[David Lawrence [:dkl]]

(In reply to Dylan William Hardison [:dylan] from comment #5)
> Comment on attachment 8703242 [details]
> upstream-merge branch
> 
> Ready to begin UAT on this -- although we also need to re-uplift patches
> from master, right?

Yeah. Suppose we need to discuss how quickly we want to track upstream. Do we do it weekly/monthly/quarterly? Also do we want to be more pick and choose rather than straight merges each time? We may not want certain features or changes. I suppose we would param or comment out certain features after we have merged rather than straight delete. This will make future merges easier.

dkl

Comment 7

[:glob ✱]

(In reply to David Lawrence [:dkl] from comment #6)
> Yeah. Suppose we need to discuss how quickly we want to track upstream.

we discussed and documented that in whistler: https://wiki.mozilla.org/BMO/Development_Processes

tl;dr cherry-pick.

Comment 8

[David Lawrence [:dkl]]

(In reply to Byron Jones ‹:glob› from comment #7)
> (In reply to David Lawrence [:dkl] from comment #6)
> > Yeah. Suppose we need to discuss how quickly we want to track upstream.
> 
> we discussed and documented that in whistler:
> https://wiki.mozilla.org/BMO/Development_Processes
> 
> tl;dr cherry-pick.

Yes I remember us discussing that now and forming that document. But reading it again, it seems to be in the context of our current code base and not necessarily relevant to the upstream merge. I am not totally for cherry picking as the longer we maintain that policy the more conflicts will arise and possibly more headache. Later on down the road we may want a feature that normally we can cherry pick if we did periodic merges, but will not be able to easily due to missing dependent code that we did not bring in earlier or the patch will reject due to being a totally different place. Not impossible, but not as smooth as it would be normally. Anyway, just an opinion.

dkl

Comment 9

[David Lawrence [:dkl]]

(In reply to Dylan William Hardison [:dylan] from comment #5)
> Comment on attachment 8703242 [details]
> upstream-merge branch
> 
> Ready to begin UAT on this -- although we also need to re-uplift patches
> from master, right?

Here is the link the simplied UAT spreadsheet (like what we used for AWS).

https://docs.google.com/spreadsheets/d/1xeIdLvqfvHtHYDBe-cELzlaJsdbU13RxI5mftrHGXSA/edit#gid=769517769

UAT Tests:
https://wiki.mozilla.org/BMO/UAT

dkl

Comment 10

[:glob ✱]

(In reply to David Lawrence [:dkl] from comment #8)
> Yes I remember us discussing that now and forming that document. But reading
> it again, it seems to be in the context of our current code base and not
> necessarily relevant to the upstream merge.

when we discussed it the scope wasn't limited to the current state.

> I am not totally for cherry picking as the longer we maintain that policy the
> more conflicts will arise and possibly more headache. Later on down the road we may
> want a feature that normally we can cherry pick if we did periodic merges, but will not be
> able to easily due to missing dependent code that we did not bring in
> earlier or the patch will reject due to being a totally different place. Not
> impossible, but not as smooth as it would be normally. Anyway, just an
> opinion.

given the state of upstream development this is unlikely to be a problem.  i'm not against periodic/scheduled merges, but we should always be selective in what we bring in from upstream as our requirements do not always align with upstream.

Comment 11

[David Lawrence [:dkl]]

Taskcluster CI work has been completed and is now all green at the moment.
https://treeherder.mozilla.org/#/jobs?repo=bmo-upstream-merge

We are ready to move on to UAT and start fleshing out any remaining bugs

Thanks to fubar's work on using a tarball of module dependencies, we have a system to perform the UAT on.

Test Instance:
https://bugzilla-merge.allizom.org

Upstream Merge UAT Worksheet:
https://docs.google.com/spreadsheets/d/1xeIdLvqfvHtHYDBe-cELzlaJsdbU13RxI5mftrHGXSA/edit#gid=769517769

Once UAT is complete, we can open up to a broader audience for possible testing and feedback.

dkl