810411 - autofill/suggestions in release kickoff app

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, defect, P3)

Description

[[e-mail] (:bhearsum)]

It would be great for the release kickoff app to suggest version numbers, branch names, etc. based off of the current data it has.

Comment 1

[[e-mail] (:bhearsum)]

Even something as simple as grayed out sample data in each field would be great. The kind that disappears when you click into the field.

Comment 2

[[e-mail] (:bhearsum)]

Attachment: add placeholders/tooltips

Tooltips not shown in the screenshot, but here's what the placeholders look like: https://people.mozilla.com/~bhearsum/sattap/69144557.png

Unfortunately, there's no way to have newlines in placeholder text.

Comment 3

[[e-mail] (:bhearsum)]

OK, I think I've come up with an idea to do autofill on Version, Build Number, Branch, and Partials. I'd like to get some feedback on it before I look at implementation. Here's the details:

For version, we'll suggest the "next" version for all of the releases from the past N weeks (N=7 probably), unless that version exists. For example, if versions from the past N weeks are: 16.0, 10.0.7esr, 17.0b1, 17.0b2, and 17.0b3 we'll ask for the "next" versions for each of those and get back:
- 16.0.1 and 17.0 (from 16.0)
- 10.0.8esr (from 10.0.7esr)
- 17.0b2 and 18.0b1 (from 17.0b1)
- 17.0b3 and 18.0b1 (from 17.0b2)
- 17.0b4 and 18.0b1 (from 17.0b3)

The duplicate 18.0b1's will be tossed away, as will 17.0b2 and 17.0b3 - leaving us with: 16.0.1, 17.0, 10.0.8esr, 17.0b4, and 18.0b1 as version number suggestions.

After a version number is entered, build number can be automatically filled out by looking for that version in the list of releases. If it already exists, use the next build number (making sure to look at the highest current build number, in case we've skipped one).

Branch suggestions will be very simple -- any branch we've seen in the past N weeks will be suggested.

Partial version suggestion will be done by looking for the last N releases (N=4 probably) that match the branch. Only one suggestion for version number will be given (so you won't have 17.0b3build1 and 17.0b3build2). The user will be able to click on the suggestions to have them appended to the field. This might be done with a short list of checkboxes.

I don't think any of the other fields make sense to autofill. Revisions (be they mozilla, comm, or l10n) cannot be guessed. Currently, we could assume that the dashboard check should only be done for betas, but I'm not sure how long that will hold true for. I could be swayed to turn the dashboard check off by default for finals and esrs if others feel strongly.

Coop, Armen - I know you two both requested this. What do you think of this plan?

Comment 4

[Armen [:armenzg]]

This sounds like a fine plan. Thanks bhearsum for checking with us!

Comment 5

[Chris Cooper [:coop] (he/him)]

(In reply to Ben Hearsum [:bhearsum] from comment #3) 
> Partial version suggestion will be done by looking for the last N releases
> (N=4 probably) that match the branch. Only one suggestion for version number
> will be given (so you won't have 17.0b3build1 and 17.0b3build2). The user
> will be able to click on the suggestions to have them appended to the field.
> This might be done with a short list of checkboxes.

Will the suggestions for partial versions update once the version is selected above?

Everything else makes sense to me.

Comment 6

[[e-mail] (:bhearsum)]

(In reply to Chris Cooper [:coop] from comment #5)
> (In reply to Ben Hearsum [:bhearsum] from comment #3) 
> > Partial version suggestion will be done by looking for the last N releases
> > (N=4 probably) that match the branch. Only one suggestion for version number
> > will be given (so you won't have 17.0b3build1 and 17.0b3build2). The user
> > will be able to click on the suggestions to have them appended to the field.
> > This might be done with a short list of checkboxes.
> 
> Will the suggestions for partial versions update once the version is
> selected above?

I wasn't planning to re-populate upon selection because we don't generally do more than 3 partials for a release. Is that OK?

Comment 7

[[e-mail] (:bhearsum)]

Comment on attachment 696745 [details] [diff] [review]
add placeholders/tooltips

Landed this patch in http://git.mozilla.org/?p=build/release-kickoff.git;a=commit;h=2f372f772acf6737691b96502fb797fdc8584bd3.

Comment 8

[[e-mail] (:bhearsum)]

Attachment: add submittedAt column

This patch is the main prerequisite for implementing suggestions - we need to keep track of submission time so we can do queries like 'releases from the past N weeks'.

Nothing too complicated here, the biggest thing of note is after much futzing around I figured out that keeping dates in UTC until they're ready to be displayed is the easiest thing to do. I'm not happy with the usage of Javascript just to do conversion to the user's local timezone...but there's no way to do that conversion on the server side.

Comment 9

[[e-mail] (:bhearsum)]

Attachment: same patch w/ --binary

Comment 10

[[e-mail] (:bhearsum)]

Comment on attachment 706583 [details] [diff] [review]
same patch w/ --binary

I pushed this and upgraded the db. We should see a "Submitted At" column here in a bit: https://ship-it-dev.allizom.org/releases.html

Comment 11

[[e-mail] (:bhearsum)]

Attachment: implement suggestions for versions, build numbers, branches, and partials

This implements the idea described in comment #3. It doesn't quite get us 100% there for partials (there's a comment in the code about that), but I think it's good enough for now.

Coop, I know you've done some JS stuff with slavealloc recently, so I'm hoping you can tell me if my JS is terrible or not. I'm....far from an expert. If you're not comfortable reviewing any part of this rail or catlee probably can.

Comment 12

[[e-mail] (:bhearsum)]

Attachment: library methods for version suggestions

Comment 13

[Chris Cooper [:coop] (he/him)]

Comment on attachment 707785 [details] [diff] [review]
implement suggestions for versions, build numbers, branches, and partials

Review of attachment 707785 [details] [diff] [review]:
-----------------------------------------------------------------

::: kickoff/static/suggestions.js
@@ +102,5 @@
> +    }
> +}
> +
> +// Helper methods for the partials' autocomplete.
> +function split(val) {

Generally not a fan of overriding built-in methods. Is this used in enough places to warrant it vs. just using val.split() where required?

::: kickoff/test/base.py
@@ +35,5 @@
> +                              l10nChangesets='lk mn', dashboardCheck=False,
> +                              mozillaRelbranch='BAR',
> +                              submittedAt=datetime(2005, 1, 2, 2, 3, 3, 5))
> +            db.session.add(r)
> +            r = FirefoxRelease(partials='0,1', promptWaitTime=5,

Should we be doing be doing multiple test releases for Firefox and Thunderbird with different params too?

::: kickoff/test/views/base.py
@@ -36,5 @@
> -                              branch='a', mozillaRevision='abc',
> -                              l10nChangesets='lk mn', dashboardCheck=False,
> -                              mozillaRelbranch='BAR')
> -            db.session.add(r)
> -            r = FirefoxRelease(partials='0,1', promptWaitTime=5,

Same question as before re: doing multiple test releases for Firefox and Thunderbird.

Comment 14

[[e-mail] (:bhearsum)]

(In reply to Chris Cooper [:coop] from comment #13)
> Comment on attachment 707785 [details] [diff] [review]
> implement suggestions for versions, build numbers, branches, and partials
> 
> Review of attachment 707785 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: kickoff/static/suggestions.js
> @@ +102,5 @@
> > +    }
> > +}
> > +
> > +// Helper methods for the partials' autocomplete.
> > +function split(val) {
> 
> Generally not a fan of overriding built-in methods. Is this used in enough
> places to warrant it vs. just using val.split() where required?

To be honest, this is stuff I copy/pasted from jquery ui tutorials. I'll see if I can use .split() instead.

> ::: kickoff/test/base.py
> @@ +35,5 @@
> > +                              l10nChangesets='lk mn', dashboardCheck=False,
> > +                              mozillaRelbranch='BAR',
> > +                              submittedAt=datetime(2005, 1, 2, 2, 3, 3, 5))
> > +            db.session.add(r)
> > +            r = FirefoxRelease(partials='0,1', promptWaitTime=5,
> 
> Should we be doing be doing multiple test releases for Firefox and
> Thunderbird with different params too?
> ::: kickoff/test/views/base.py
> @@ -36,5 @@
> > -                              branch='a', mozillaRevision='abc',
> > -                              l10nChangesets='lk mn', dashboardCheck=False,
> > -                              mozillaRelbranch='BAR')
> > -            db.session.add(r)
> > -            r = FirefoxRelease(partials='0,1', promptWaitTime=5,
> 
> Same question as before re: doing multiple test releases for Firefox and
> Thunderbird.

I think I have all important cases covered -- most of the functionality is common between Fennec and Desktop releases. (Most of this code is just being moved from test/views/base.py, ftr.)

Comment 15

[[e-mail] (:bhearsum)]

Attachment: stop overriding split

Comment 16

[[e-mail] (:bhearsum)]

Comment on attachment 708125 [details] [diff] [review]
stop overriding split

Oops, wrong reviewer.

Comment 17

[[e-mail] (:bhearsum)]

Comment on attachment 707787 [details] [diff] [review]
library methods for version suggestions

Had to back this out because crappy Python version preproduction....

Comment 18

[[e-mail] (:bhearsum)]

Attachment: use old syntax

Tested this by hand w/ the same Python that's used for the preprod tests.

Comment 19

[Chris Cooper [:coop] (he/him)]

(In reply to Ben Hearsum [:bhearsum] from comment #17) 
> Had to back this out because crappy Python version preproduction....

Should we update that?

Comment 20

[[e-mail] (:bhearsum)]

(In reply to Chris Cooper [:coop] from comment #19)
> (In reply to Ben Hearsum [:bhearsum] from comment #17) 
> > Had to back this out because crappy Python version preproduction....
> 
> Should we update that?

It would be great to update it to whatever the minimum version we use across all slaves+masters is.

Comment 21

[[e-mail] (:bhearsum)]

(In reply to Ben Hearsum [:bhearsum] from comment #20)
> (In reply to Chris Cooper [:coop] from comment #19)
> > (In reply to Ben Hearsum [:bhearsum] from comment #17) 
> > > Had to back this out because crappy Python version preproduction....
> > 
> > Should we update that?
> 
> It would be great to update it to whatever the minimum version we use across
> all slaves+masters is.

Filed bug 836787 on that.

Comment 22

[[e-mail] (:bhearsum)]

Landed and the dev instance picked it up.