[Lubuntu-qa] Final Freeze for Ubuntu 13.10 (Saucy) at 2100UTC today

[Phill Whiteside]

Running from live usb will be slower than running off the hard drive as an
installed system.

Regards.

Phill.


On 12 October 2013 14:39, JM <meets at gmx.fr> wrote:

> Hi,
>
> As I am reading this message I feel confused somehow : have some clear
> step-to-step
> instructions been given? If not is it possible to get some (and not too
> long to read if
> possible)?
>
> I am presently testing the Lubuntu Saucy updated with zsync as of
> yesterday evening Paris
> time, which I have installed with USB GTK Creator from withing a Ubuntu
> 12.04, and trying
> to see if I can get a boot with persistency.
>
> The Live USB is running on a nice P4 with 4 GB RAM CPU 2.8 Ghz dual
> core/hyperthreading,
> integrated Graphic Intel, and it seems more sluggish than it should be on
> a machine with
> that much resource.
>
> So, in few words, what about the testing should be prior tested, exactly
> how, and within
> how much time? (I'll report on another thread later, of course).
>
> Regards,
> Mélodie
>
>
>
> On Fri, 11 Oct 2013 23:48:25 +0100
> Phill Whiteside <PhillW at Ubuntu.com> wrote:
>
> > 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 at ubuntu.com> 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 at lists.ubuntu.com
> > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
> > >
> > > --
> > > https://wiki.ubuntu.com/phillw
> > > <https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce>
> > >
>
>
> --
> JM <meets at gmx.fr>
>



-- 
https://wiki.ubuntu.com/phillw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20131012/298d1056/attachment.html>