lubuntu-qa team mailing list archive

[Phill Whiteside <PhillW@xxxxxxxxxx>]

Hi,

I know full well that I'm no longer allowed on this area, but the thought
of Ubiquity being launched with such a, IMHO, serious bug does lead me to
ask that the bug be allocated to some one and the testers are asked as to
how we can provide data.

I'm going to step out of line and explain a little behind the bug....
Asking bug reporters generic questions is not the correct way to deal with
installer issues. We are testers and *you* good people have to let us know
what further we can do to provide information. Commenting on a bug "we need
more information" is of no use to either the people reporting the bug, nor
those who need the additional information to track it down.

Having Nick let me know a wiki link for such things should have been done
long ago. You asked for installer bugs and that they would be top
priority?... Well, here it is with no one allocated to it. Having a name to
a bug does encourage the testers as they see a 'person' and not a blind
bug. This allows the person looking after the bug and the testers to be
able to talk to humans.

Regards,

Phill.
1. https://bugs.launchpad.net/ubuntu/+source/linux-ppc/+bug/1220165


On 10 October 2013 18:09, Adam Conrad <adconrad@xxxxxxxxxx> wrote:

> [ This is a shameless copy-and-paste from last year ]
>
> For the timezone challenged, as of 2100UTC today, the archive is
> officially fozen in preparation of release candidates and the
> final release of Saucy Salamander in a week.  This is three
> hours from the time I hit send on this email.
>
> Uploads from here on in should fall into the following 4 bins:
>
> 1) Installer/release-critical bugs that absolutely MUST get fixed
>    lest we risk shipping a broken image that turns computers pink
>    or sets them on fire:  Please contact the release team about
>    these bugs and upload (well-tested) solutions ASAP.
>
>    Last minute hardware enablement fixes, and pretty much anything
>    installer related that is auditable and testable also falls in
>    to this category, as our best installer testing comes in the
>    next few days, historically.
>
>    Some people may have noticed that we're also in the process of
>    spinning up a new port right now (our timing is impeccable, is
>    it not?), so uploads with clear and targetted FTBFS fixes for
>    arm64 will continue to be accepted for seeded packages until
>    Sunday night, and for unseeded pretty much right up to release.
>
> 2) Non-release-critical-but-nice-to-have bugfixes:  These are
>    fixes that you would absolutely feel comfortably about doing
>    as an SRU but not necessarily destabilising the release process
>    for.  Again, contact the release team, and we may slip some of
>    these in, while asking you to defer the rest to SRUs.
>
> 3) Feature additions, massive code refactoring, user interface
>    changes, non-typo string changes:  Just don't upload these, or
>    ask about them.  The time for them came and went long ago.
>
> 4) Updates to non-seeded packages:  Technically, unseeded packages
>    don't freeze until pretty much right before release.  While this
>    is true, we may still try to talk you out of pushing some huge
>    new upstream version of something, or start a library transition
>    at the zero hour.  We're only a week away from opening the next
>    release, a bit of patience (or prepping in a PPA, etc) might be
>    a decent plan.
>
> Here's hoping everyone gets on board with testing images, helping
> to fix absolutely critical bugs, donating spare creative cycles to
> the release notes, and any other way we can all contribute to yet
> another great Ubuntu release.
>
> ... Adam
>
> --
> ubuntu-devel-announce mailing list
> ubuntu-devel-announce@xxxxxxxxxxxxxxxx
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
>
> --
> https://wiki.ubuntu.com/phillw
> <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce>
>