On 12/02/2013 06:25 AM, Richard Brown wrote:
On Mon, 2013-12-02 at 11:50 +0100, Stephan Kulow
Our testing are devel projects. I bet some use
devel:gcc to test
gcc and report bugs before you send it to Factory. But not enough.
That is exactly how I prefer to operate when testing/maintaining GNOME
Using GNOME:Factory (the gnome devel repo) with Factory gives me a way
of testing all of the 'incoming' GNOME changes.
If something in our GNOME devel repo fouls up, I'm a simple 'zypper
removerepo' and 'zypper dup' away from getting my machine back to
'usable' so I can get working on figuring out what broke in GNOME
The only reason I don't use this approach 24/7, 365 days a year is that
with our current approach, Factory isn't 'stable' enough.
Or to put it another way, there's about as much chance (if not more)
every time I 'zypper up' my machine that recent updates to Factory are
going to break my system, as the recent updates to our GNOME devel
I think the suggestions so far take us huge strides towards making
Factory usable in exactly the kind of way *I* need it.. which is why I'm
so excited by them.
Well I HATE rebooting my machine, sitting on top of Factory would imply
kernel updates on a more regular basis and that doesn't work for me.
Rebooting 2 or 3 times during the 8 month release cycle is more than
enough for me.
If we do not chase the kernel in the new Factory model, but only update
the Factory kernel every 3 months or so when there is a new upstream
release then I am OK with it, but if we have RC releases in Factory and
I would end up having to reboot every two weeks as the kernel release
cycle is approaching a new release that is just not going to work for me.
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Public Cloud Architect
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org