On Thu, May 28, 2015 at 2:08 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
On Thu, May 28, 2015 at 3:58 PM, Michael Catanzaro mcatanz...@gnome.org
wrote:
On Thu, 2015-05-28 at 14:39 -0400, Przemek Klosowski wrote:
Do you think the tech could stabilize enough to obviate the first
reason?
On 8 June 2015 at 06:37, Neal Gompa ngomp...@gmail.com wrote:
On Sun, Jun 7, 2015 at 3:30 PM, Will Woods wwo...@redhat.com wrote:
On Sun, 2015-06-07 at 07:41 -0400, Neal Gompa wrote:
Uhh, this might be a stupid question, but what actually prevents us
from integrating the FedUp process into
Dne 29.5.2015 v 13:38 Petr Hracek napsal(a):
Please have a look on Feature proposed in Fedora 19.
https://fedoraproject.org/wiki/Features/FedoraUpgrade
It should be redesigned maybe. Package already exists in Fedora.
What do you think about it?
It is still there. Just not marked as Feature,
On Sun, Jun 7, 2015 at 3:30 PM, Will Woods wwo...@redhat.com wrote:
On Sun, 2015-06-07 at 07:41 -0400, Neal Gompa wrote:
Uhh, this might be a stupid question, but what actually prevents us
from integrating the FedUp process into install media (that is, not
live images)? I mean, yeah, it's nice
On Sun, 2015-06-07 at 07:41 -0400, Neal Gompa wrote:
Uhh, this might be a stupid question, but what actually prevents us
from integrating the FedUp process into install media (that is, not
live images)? I mean, yeah, it's nice that we can do upgrades online,
but what about when the system we
Uhh, this might be a stupid question, but what actually prevents us
from integrating the FedUp process into install media (that is, not
live images)? I mean, yeah, it's nice that we can do upgrades online,
but what about when the system we need to upgrade doesn't necessarily
have online access?
On Sun, Jun 7, 2015 at 1:41 PM, Neal Gompa ngomp...@gmail.com wrote:
Uhh, this might be a stupid question, but what actually prevents us
from integrating the FedUp process into install media (that is, not
live images)? I mean, yeah, it's nice that we can do upgrades online,
but what about when
On 05/28/2015 05:42 PM, Will Woods wrote:
[tl;dr: fedup is going away and should be re-implemented by the system
packaging tools.]
Hey all,
F22 is the fifth release we've handled with fedup. A lot has changed
since F17, and we've learned some valuable lessons about how upgrades
work (and how
On 3 June 2015 at 11:55, Petr Hracek phra...@redhat.com wrote:
Does it mean that using systemd Offline Updates there will not be a Zero
downtime feature.
Except rebooting because of kernel upgrade?
Well, we'll certainly be using offline updates to do the actual transaction.
Will there be any
On 05/28/2015 05:42 PM, Will Woods wrote:
[tl;dr: fedup is going away and should be re-implemented by the system
packaging tools.]
Hey all,
F22 is the fifth release we've handled with fedup. A lot has changed
since F17, and we've learned some valuable lessons about how upgrades
work (and how
On Thu, 2015-05-28 at 17:11 -0600, Stephen John Smoogen wrote:
Good luck with that vision. I would buy into it a bit more if this
wasn't the same chestnut dragged out every couple of releases to
somehow motivate us to accept whatever big OS change is being pushed.
It has become the Cry Wolf
On Fri, May 29, 2015 at 6:47 AM, Michael Catanzaro mcatanz...@gnome.org
wrote:
...our primary competitor is doing it in the near future...
...we cannot head towards a future where all of our applications are older
than what Ubuntu is shipping...
I'm failing to connect the dots here... snappy
Am 29.05.2015 um 18:39 schrieb Gerald B. Cox:
On Fri, May 29, 2015 at 6:47 AM, Michael Catanzaro mcatanz...@gnome.org
mailto:mcatanz...@gnome.org wrote:
...our primary competitor is doing it in the near future...
...we cannot head towards a future where all of our applications are
On Fri, May 29, 2015 at 11:10 AM, Michael Catanzaro mcatanz...@gnome.org
wrote:
The point is that you can update to the newest versions of applications
as they are released upstream, without having to worry about whether there
could be incompatibilities with system
libraries.
Well, someone
Am 29.05.2015 um 20:10 schrieb Michael Catanzaro:
On Fri, 2015-05-29 at 09:39 -0700, Gerald B. Cox wrote:
I'm failing to connect the dots here... snappy is a different
packaging paradigm with some advantages
and disadvantages; but how exactly does it ensure that distributed
packages are newer?
On Fri, May 29, 2015 at 08:40:07PM +0200, Reindl Harald wrote:
cool, and now we went the windows road
* security update of library X
* nobody knows which applications are still vulnerable
Why does no one know? Keeping track of this kind of thing is exactly
what computers are good for.
--
Am 29.05.2015 um 20:50 schrieb Matthew Miller:
On Fri, May 29, 2015 at 08:40:07PM +0200, Reindl Harald wrote:
cool, and now we went the windows road
* security update of library X
* nobody knows which applications are still vulnerable
Why does no one know? Keeping track of this kind of
On Fri, May 29, 2015 at 12:04 PM, Matthew Miller mat...@fedoraproject.org
wrote:
Right, so... let's make the package managers keep the mess clean _even
in this case_.
Well, I don't know if I would use the term mess - but snappy would be a
paradigm
shift. That in and of itself isn't
On Fri, May 29, 2015 at 02:50:05PM -0400, Matthew Miller wrote:
On Fri, May 29, 2015 at 08:40:07PM +0200, Reindl Harald wrote:
cool, and now we went the windows road
* security update of library X
* nobody knows which applications are still vulnerable
Why does no one know? Keeping track
On Fri, May 29, 2015 at 08:55:55PM +0200, Reindl Harald wrote:
Why does no one know? Keeping track of this kind of thing is exactly
what computers are good for
because when each and every application sjips it's own libraries
it's a mess - that's exactly what package managers are for - if i
On 29 May 2015 at 13:04, Matthew Miller mat...@fedoraproject.org wrote:
On Fri, May 29, 2015 at 08:55:55PM +0200, Reindl Harald wrote:
Why does no one know? Keeping track of this kind of thing is exactly
what computers are good for
because when each and every application sjips it's own
On Fri, 2015-05-29 at 09:39 -0700, Gerald B. Cox wrote:
I'm failing to connect the dots here... snappy is a different
packaging paradigm with some advantages
and disadvantages; but how exactly does it ensure that distributed
packages are newer? Isn't that
a function of the packager?
The
On Thu, 2015-05-28 at 15:05 -0600, Kevin Fenzi wrote:
With timed: you don't get the newest thing, but switching to the new
stuff is more on your schedule. You can ignore the new release for a
while and still get bugfixes/security updates until you are ready to
do
the upgrade.
I should add
On 28 May 2015 at 16:42, Michael Catanzaro mcatanz...@gnome.org wrote:
On Thu, 2015-05-28 at 15:05 -0600, Kevin Fenzi wrote:
With timed: you don't get the newest thing, but switching to the new
stuff is more on your schedule. You can ignore the new release for a
while and still get
On Thu, May 28, 2015 at 3:58 PM, Michael Catanzaro mcatanz...@gnome.org wrote:
On Thu, 2015-05-28 at 14:39 -0400, Przemek Klosowski wrote:
Do you think the tech could stabilize enough to obviate the first
reason? The 6-month workflow cadence remains a good idea, of course,
but could result in
On Thu, May 28, 2015 at 04:08:23PM -0400, Josh Boyer wrote:
about how to provided some kind of API/ABI at the platform level that
developers can depend on. Your goal is nice, but we are nowhere near
the point of actually doing what you just said.
Also, the release cycle is a reliable engine
On Thu, 28 May 2015 14:58:03 -0500
Michael Catanzaro mcatanz...@gnome.org wrote:
On Thu, 2015-05-28 at 14:39 -0400, Przemek Klosowski wrote:
Do you think the tech could stabilize enough to obviate the first
reason? The 6-month workflow cadence remains a good idea, of
course, but could
On Thu, 28 May 2015 17:32:24 -0400
Matthew Miller mat...@fedoraproject.org wrote:
On Thu, May 28, 2015 at 03:05:03PM -0600, Kevin Fenzi wrote:
In some kind of ideal world it would be great if rawhide was the
rolling release and people who liked that model could use it day to
day. (Which is
On 05/28/2015 03:58 PM, Michael Catanzaro wrote:
I think we're already at the point where -- at least for Fedora
Workstation (not sure about Server/Cloud), and except for
infrastructure issues -- we can stop branding our releases with a
version number, and simply have a particularly big offline
On Thu, May 28, 2015 at 4:05 PM, Reindl Harald h.rei...@thelounge.net wrote:
Am 28.05.2015 um 21:58 schrieb Michael Catanzaro:
On Thu, 2015-05-28 at 14:39 -0400, Przemek Klosowski wrote:
Do you think the tech could stabilize enough to obviate the first
reason? The 6-month workflow cadence
Am 28.05.2015 um 22:12 schrieb Josh Boyer:
On Thu, May 28, 2015 at 4:05 PM, Reindl Harald wrote:
when i hear offline update i have enough at all
frankly what people really need is relieable and fast *online updates* and
not taking the esay road well go offline and that works pretty well over
Am 28.05.2015 um 21:58 schrieb Michael Catanzaro:
On Thu, 2015-05-28 at 14:39 -0400, Przemek Klosowski wrote:
Do you think the tech could stabilize enough to obviate the first
reason? The 6-month workflow cadence remains a good idea, of course,
but could result in a major offline upgrade,
On Thu, May 28, 2015 at 03:05:03PM -0600, Kevin Fenzi wrote:
In some kind of ideal world it would be great if rawhide was the
rolling release and people who liked that model could use it day to
day. (Which is really already the case, but things do break so you need
to be good at
On Thu, 2015-05-28 at 14:39 -0400, Przemek Klosowski wrote:
Do you think the tech could stabilize enough to obviate the first
reason? The 6-month workflow cadence remains a good idea, of course,
but could result in a major offline upgrade, instead of an entire
new distribution.
I think
On 05/28/2015 11:42 AM, Will Woods wrote:
Here's how it should work:
1) Download packages for the new system
2) Use the systemd Offline Updates[2] facility to install packages
This is really simple - simple enough that it should probably be
provided by the system packaging tools themselves.
On 05/28/2015 02:44 PM, Reindl Harald wrote:
Am 28.05.2015 um 20:39 schrieb Przemek Klosowski:
Do you think the tech could stabilize enough to obviate the first
reason? The 6-month workflow cadence remains a good idea, of course,
but could result in a major offline upgrade, instead of an
Am 28.05.2015 um 20:39 schrieb Przemek Klosowski:
On 05/28/2015 11:42 AM, Will Woods wrote:
Here's how it should work:
1) Download packages for the new system
2) Use the systemd Offline Updates[2] facility to install packages
This is really simple - simple enough that it should probably be
On Thu, May 28, 2015 at 12:58 PM, Michael Catanzaro mcatanz...@gnome.org
wrote:
...we can stop branding our releases with a
version number...we still have the six-month cycle, but
this is hidden to users...this is the model Windows is moving to...
As Josh alluded, I'm not exactly clear on
Am 29.05.2015 um 01:11 schrieb Stephen John Smoogen:
On 28 May 2015 at 16:42, Michael Catanzaro mcatanz...@gnome.org wrote:
On Thu, 2015-05-28 at 15:05 -0600, Kevin Fenzi wrote:
With timed: you don't get the newest thing, but switching to the new
stuff is more on your schedule. You can
, 2015 11:42:56 AM
Subject: fedup for F23 and beyond
[tl;dr: fedup is going away and should be re-implemented by the system
packaging tools.]
Hey all,
F22 is the fifth release we've handled with fedup. A lot has changed
since F17, and we've learned some valuable lessons about how upgrades
work
[tl;dr: fedup is going away and should be re-implemented by the system
packaging tools.]
Hey all,
F22 is the fifth release we've handled with fedup. A lot has changed
since F17, and we've learned some valuable lessons about how upgrades
work (and how they fail).
We've come to the conclusion
41 matches
Mail list logo
