Add SSE deprecation bugs to precreated templates

[bhearsum]

I'm told that this is how we prefer to track "special stuff that needs to be done as part of releases" these days, like the OS X deprecation stuff that @Callek added to the 48.0 template.

I did the same for all upcoming SSE deprecation stuff listed in https://bugzilla.mozilla.org/show_bug.cgi?id=1271762#c18. I thought it would be better to integrate with the "status" section, because certain things have to happen at certain times of the release, so it's good to put them in order now. This is what we used to do back in the day with wiki build notes. I can change that if it's unwanted, though.

Not sure who the right person to review this is, @rail, @lundjordan, @nthomas-mozilla, @kmoir, @Callek?

[Callek]

I think this is the best we can do right now... I also do think we should/need some way to mark a release as future though, so that we don't get "created" dates of ~now and can hide them from release status by default (the 48.0 one clutters me every time -- as does the TB aborted-build one) -- but either way I'm happy to take this until such a thing exists.

I'm awaiting someone else on your ping list to comment before any of us merge though ;-)

[lundjordan]

iirc - I set it up so we use the template markdown page against current json file every time we modify a given release. iow - things in the status/checklist of the $release.md files will be overwritten if not in the default template[1]

so we need two things:

1) we need a way to be able to define 1 off items for a checklist/status of a release 2) be able to write future releases ahead of time without a confusing start date

how about something like having a new directory like templates/one-off/ that has a markdown and json template for a very specific release. releasewarrior then, for every create/update cmd, first looks for that specific release template, e.g. templates/one-off/{firefox-beta-49.0b1.md.template,firefox-beta-49.0b1.json.template} and if it finds that, it uses that. otherwise, it falls back to default: templates/{firefox_beta.md.tmpl,firefox_beta.json.tmpl}

I believe that would fix both issues.

[1] https://github.com/mozilla/releasewarrior/blob/master/releasewarrior/commands.py#L62

On Fri, Jul 8, 2016 at 6:48 AM, Justin Wood (Callek) < notifications@github.com> wrote:

I think this is the best we can do right now... I also do think we should/need some way to mark a release as future though, so that we don't get "created" dates of ~now and can hide them from release status by default (the 48.0 one clutters me every time -- as does the TB aborted-build one) -- but either way I'm happy to take this until such a thing exists.

I'm awaiting someone else on your ping list to comment before any of us merge though ;-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla/releasewarrior/pull/17#issuecomment-231363776, or mute the thread https://github.com/notifications/unsubscribe/ABknMZB2QJaJeF8es8JMQ4HJNH1O2g20ks5qTlUcgaJpZM4JICRI .

[Callek]

@lundjordan I was more thinking something like:

release create --future firefox release 48 release update --future firefox release 48 --issue "Need to do FOO"

If --future is not passed will abort saying no release of that name in flight (or whatever)

release create firefox release 48 will then create the release with the json issue list of that future release.

The json (and markdown?) can be in a releases/FUTURE/ folder.

[lundjordan]

@Callek

the main problem with this PR is that the 'one-off' steps that need to be done are defined in the human_tasks/status section[1] not issues. which is ultimately what we want since these are human steps not issues. However, they will be blown away every time we update.

I am down for using --future to define upcoming releases but when they are no longer future releases (AKA current), and you go to use the normal commands, the human_tasks will be blown away. That is why I feel like future releases should be defined in template files. Which also solves the confusing date problem

However, the downside is releasewarrior won't know how to check off the one-off human_task items as they will not be cmd line options like the existing --emailed-cdntest. So for the unknown steps, you would have to update the current releases/$one-off-release{.md,.json} files manually and commit. But that is no worse than the old wiki days :)

[1] https://github.com/mozilla/releasewarrior/pull/17/files#diff-f4616d3b972cbd49e08270cb37bb4260R14

[lundjordan]

if we are okay with having these human_step reminders as issues. then I think your solution is the least invasive as we wouldn't force users to manually edit json/md files

[bhearsum]

If folks prefer to use issues, that's fine with me. I didn't realize the complications of putting them in the section I did. It's your call :)

[bhearsum]

How's this look? I moved everything into the "issues" section, and updated the JSON in addition to the md.

[lundjordan]

lgtm for now. thanks for putting it in the issues. one day I might get around to tackling what callek suggested with regards to a --future option