Yes, you're correct. More focused testing occurs before the release. We are
looking for OOTB experience and making sure users don't install fresh with
broken stuff.
On Tue, Mar 13, 2018, 2:34 PM Sławomir Nizio
wrote:
> > Its testing in general. I don't just test raw images. If I see something
>
OK, looks like the Kanban board is the pet we like.
On Github, the board can be made of (classic) issues and notes. I
believe notes are enough as replies to this thread don't suggest we need
anything special from issues. (Still, they can be mixed so there's no…
issue.)
Anyway,
shall I go and crea
I propose to keep it as simple as possible and think of extending that
as needed.
> For those links: I personally prefer the issues view.
Hopefully also the Kanban board!
> Its testing in general. I don't just test raw images. If I see something
> or hear complaints, I test, and file a bug where necessary.
> the idea is we're testing all the time, not just ISOs during/after freeze.
Right, although more focused testing is being done prior to the release,
no? :) (An
Coming back to your question...
I'd look for a tool we not only can use for the release process, but may be
able to get an oversight of where are we standing at any given point in time (=
whenever we want to see it, we get the state as it is at that point. No time
travel).
https://github.com/d
Hi,
if you are interested, I could ask how Mozilla is synching their GitHub issues
with their Bugzilla issue tracker (this setup sounds familiar :-)).
https://github.com/mozilla-bteam/bmo if you want to get an idea.
I assume it comes down to bot + conventions.
Kind regards
Ryuno-Ki
--
Kanban works for me :)
Il lun 12 mar 2018, 02:20 Jerrod Frost ha
scritto:
> Oops, I had my tabs ordered wrong. I opened them in reverse and noticed
> the Kanban one as the "first" tab. I prefer the Kanban board.
>
> On Sun, Mar 11, 2018 at 5:58 PM Joost Ruis wrote:
>
>> Kanban board works for m
