565640 - [shipping] Create milestones on shipping, move events to AppVersion

Status: RESOLVED FIXED

(Webtools Graveyard :: Elmo, defect, P2)

Description

[Axel Hecht [:Pike]]

Right now, we're doing SignOff control via the state of existing milestones, which leaves us with a lot of bugs on managing milestones if plans change.

It'd be easier to have flags on the AppVersion that denote if sign-offs are open or not, and to actually only create a milestone object at the time of shipping it, and then naming it explicitly.

Talked this through with gandalf, and we think that's the way to go.

I guess this would obsolete bugs 527901, 530884, 530885, at least.

Comment 1

[Axel Hecht [:Pike]]

FWIW, here's how I envision the changes:

For non-shipped milestones, have a link to the shipping UI, which will:

Show all changes in sign-offs, similar to what https://l10n-stage-sj.mozilla.org/shipping/about-milestone/fx4.0b3 does, with an UI to take all, none, or just particular ones (think checkboxens, with select all, select none buttons).

On that sign-off UI, you specify milestone data like version and buildnumber, where the latter is new.

Once you submit, permissions get checked, and the action performed, redirecting you go https://l10n-stage-sj.mozilla.org/shipping/about-milestone/fx4.0b3, which would then have prominent links to l10n-changesets.

Comment 2

[Axel Hecht [:Pike]]

Taking.

Comment 3

[Axel Hecht [:Pike]]

Attachment: draft of how shipping.models could change

gandalf, do you have a moment to glance over the model changes here before you head off?

I added both a build and a shipping datetime to milestone, the latter because I think it's of interest in the long run.

Also, the events are now on AppVersion, renamed and tweaked. No data loss here, as there's no single Event instance in the db right now.

And I moved the permission for opening and closing from Milestone to AppVersion. It's technically equivalent to being able to create AppVersionEvents, but I think this is cleaner.

For data migration, I may move those changes into a patch series, so that we have data additions and removals in separate patches, but I'll do that later on.

Comment 4

[Axel Hecht [:Pike]]

I'm updating the l10n_site_test db with a snapshot of l10n_site, and will use that to test the code and the migration pieces.

Comment 5

[Axel Hecht [:Pike]]

ping?

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 463169 [details] [diff] [review]
draft of how shipping.models could change

does it still make sense to keep the events? Do we need the timestamps here? Maybe we could just turn it into appver flag, unless you expect we may want to extend it later...

Comment 7

[Axel Hecht [:Pike]]

I think I'd like to have the events so that we can easily see the life span of an appversion.

Comment 8

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 463169 [details] [diff] [review]
draft of how shipping.models could change

Ok. I'm worried about the number of tables we're getting ourselves into if we follow that pattern for everything, but if there's one place where it's worth having it, it may be this one.

One other option would be to just use django action logs for that. Or make the event table generic for all events that we may want to store. Or we can ignore it for now as well.

>+            if self.build > 1:
>+                rv += ' Build ' + self.build
(..)
>-            return self.code
>+            return self.code + "." + self.build

Make sure to bring it to the python motherland with '%s.%s' % (self.code, self.build) etc. ;)

Comment 9

[Axel Hecht [:Pike]]

Enough of this was achieved with bug 650816. Marking FIXED.