On Thu, May 28, 2015 at 2:08 PM, Josh Boyer wrote:
> On Thu, May 28, 2015 at 3:58 PM, Michael Catanzaro
> 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
On 8 June 2015 at 06:37, Neal Gompa wrote:
> On Sun, Jun 7, 2015 at 3:30 PM, Will Woods 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
>>
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 Feat
On Sun, Jun 7, 2015 at 3:30 PM, Will Woods 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 that we ca
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 w
On Sun, Jun 7, 2015 at 1:41 PM, 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? I'd
On 3 June 2015 at 11:55, Petr Hracek 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 possibility
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 th
On 29 May 2015 at 13:04, Matthew Miller 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 libraries
>> it's a mes
On Fri, May 29, 2015 at 12:04 PM, Matthew Miller
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 necessarily a bad thing; but
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? Keepin
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
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 thing
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: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 11:10 AM, Michael Catanzaro
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 still has to cre
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?
Am 29.05.2015 um 18:39 schrieb Gerald B. Cox:
On Fri, May 29, 2015 at 6:47 AM, Michael Catanzaro 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
older than what Ubun
On Fri, May 29, 2015 at 6:47 AM, Michael Catanzaro
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 is a different p
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 Wol
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 th
Am 29.05.2015 um 01:11 schrieb Stephen John Smoogen:
On 28 May 2015 at 16:42, Michael Catanzaro 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
On Thu, May 28, 2015 at 12:58 PM, Michael Catanzaro
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 the value of keepin
On 28 May 2015 at 16:42, Michael Catanzaro 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 bugfixes/security updates
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 a
On Thu, 28 May 2015 17:32:24 -0400
Matthew Miller 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 really already th
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 troubleshoo
On Thu, 28 May 2015 14:58:03 -0500
Michael Catanzaro 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 a majo
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
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 o
On Thu, May 28, 2015 at 4:05 PM, Reindl Harald 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 remains a
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 u
On Thu, May 28, 2015 at 3:58 PM, Michael Catanzaro 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 a major offli
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, inst
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 thin
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 ent
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 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.
A
5 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
wor
[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 that
41 matches
Mail list logo
