Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 08/03/2017 05:41 AM, Kamil Paral wrote: > Randy, can you please describe how it's going to change in terms of koji > tags? How the (new) koji tags are going to be named, when packages enter > them, when they leave them (including the -pending tags). Or is there a > diagram somewhere? I'd like

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Mon, Jul 31, 2017 at 11:34 PM, Randy Barlow wrote: > To necromance this old thread, I wanted to give a heads up that we're > about to get a cool feature in Bodhi in response to this thread: > > https://github.com/fedora-infra/bodhi/pull/1678 > > With that pull

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2017-08-01 at 16:47 -0400, Matthew Miller wrote: > What about the opposite? Should we require classification for bugfix > and security updates? I'd say it wouldn't hurt to require it. It always makes data nice if the parser of the data can know that a field is guaranteed to exist so they

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Aug 01, 2017 at 04:34:34PM -0400, Randy Barlow wrote: > > Yeah, exactly. Do you want a new RFE issue for this? > Sure, it makes sense to me. Though I will say that there probably isn't > much tangible harm done leaving it as it is, even though it doesn't > make sense. What about the

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2017-08-01 at 16:11 -0400, Matthew Miller wrote: > Yeah, exactly. Do you want a new RFE issue for this? Sure, it makes sense to me. Though I will say that there probably isn't much tangible harm done leaving it as it is, even though it doesn't make sense. signature.asc Description: This

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Aug 01, 2017 at 03:50:45PM -0400, Randy Barlow wrote: > > (Hmmm. And should enhancement > > and new packages _get_ a severity option? Maybe that should be locked > > to "unspecified"?) > Hahaha, "This newpackage update is urgently severe! Have some severe > new features!" Yeah, exactly.

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2017-08-01 at 15:31 -0400, Matthew Miller wrote: > I think this is why we don't just automatically make security fixes > all > high priority but instead have a separate field. Many security > updates > fix problems which only happen in unlikely configurations, or have > extremely minor

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Aug 1, 2017 at 3:10 PM, Randy Barlow wrote: > On Tue, 2017-08-01 at 11:02 -0500, Dennis Gilmore wrote: >> I would really like to see us have a single unified >> view on update management at a distro level and not having different >> tools implementing their

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Aug 01, 2017 at 03:09:22PM -0400, Randy Barlow wrote: > > Also, if I mark a security update as low priority, that means it > > really is low priority. There's no need for many security updates to > > skip batched. Many are e.g. minor DoS vulnerabilities that are > > unlikely to be

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2017-08-01 at 11:02 -0500, Dennis Gilmore wrote: > I would really like to see us have a single unified > view on update management at a distro level and not having different > tools implementing their own behaviours. I agree with Dennis here - not all users of Fedora use the Gnome

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2017-08-01 at 08:26 +0100, Michael Catanzaro wrote: > Also, if I mark a security update as low priority, that means it > really is low priority. There's no need for many security updates to > skip batched. Many are e.g. minor DoS vulnerabilities that are > unlikely to be exploited ever,

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

El mar, 01-08-2017 a las 08:26 +0100, Michael Catanzaro escribió: > Keep in mind that GNOME Software already only checks for non-security > updates weekly. So it will actually take as much as two weeks for the > update to reach users once it enters batched, which I suspect may not > have been

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 08/01/2017 03:58 PM, Matthew Miller wrote: > On Tue, Aug 01, 2017 at 02:41:57PM +0100, Kalev Lember wrote: Keep in mind that GNOME Software already only checks for non-security updates weekly. So it will actually take as much as two >>> Doesn't it check daily but only *alert* weekly?

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Aug 01, 2017 at 02:41:57PM +0100, Kalev Lember wrote: > >> Keep in mind that GNOME Software already only checks for > >> non-security updates weekly. So it will actually take as much as two > > Doesn't it check daily but only *alert* weekly? AFAIK there's no way to > > just ask our servers

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 08/01/2017 02:35 PM, Matthew Miller wrote: > On Tue, Aug 01, 2017 at 08:26:04AM +0100, Michael Catanzaro wrote: >> Keep in mind that GNOME Software already only checks for >> non-security updates weekly. So it will actually take as much as two > > Doesn't it check daily but only *alert*

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Aug 01, 2017 at 08:26:04AM +0100, Michael Catanzaro wrote: > Keep in mind that GNOME Software already only checks for > non-security updates weekly. So it will actually take as much as two Doesn't it check daily but only *alert* weekly? AFAIK there's no way to just ask our servers for

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

Keep in mind that GNOME Software already only checks for non-security updates weekly. So it will actually take as much as two weeks for the update to reach users once it enters batched, which I suspect may not have been intended. We are really looking at weekly updates with an additional

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Mon, 2017-07-31 at 22:51 -0400, Randy Barlow wrote: > On Mon, 2017-07-31 at 22:13 -0400, Ben Rosser wrote: > > 2. If we do implement this, could we consider not batching new > > package > > updates in addition to security and "urgent" updates? New package > > updates wouldn't get downloaded

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Mon, Jul 31, 2017 at 10:51 PM, Randy Barlow wrote: > It would be activated whenever the Bodhi that has it is deployed. > However, it won't be a forced policy - developers will still be free to > click "push to stable" if they please. The autokarma feature will >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Mon, 2017-07-31 at 22:13 -0400, Ben Rosser wrote: > 1. Are you saying that this feature will be *activated* once it's > merged, or just that it will be available should Fedora decide to > turn > it on as a policy decision? I'm assuming it's the latter, as I don't > think I've seen a change

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Mon, Jul 31, 2017 at 5:34 PM, Randy Barlow wrote: > To necromance this old thread, I wanted to give a heads up that we're about > to get a cool feature in Bodhi in response to this thread: > > https://github.com/fedora-infra/bodhi/pull/1678 > > With that pull

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Mon, 2017-07-31 at 21:00 -0400, Matthew Miller wrote: > This is awesome, Randy! Thanks! Caleigh did the hard work ☺ signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Mon, Jul 31, 2017 at 09:34:24PM -, Randy Barlow wrote: > request:stable. Then they will continue on as they do today. This > should help us to reduce the daily churn of Fedora updates for > end-users to only be updates they truly need. It may also make the > masher be a little faster on 6

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

To necromance this old thread, I wanted to give a heads up that we're about to get a cool feature in Bodhi in response to this thread: https://github.com/fedora-infra/bodhi/pull/1678 With that pull request, there will be a new request state called "batched". When non-priority[0] updates reach

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

Hey everyone -- clearly there's a bit of a miscommunication here. Working it out through further discussion is good, but in the future, it's probably better to briefly take that off list and come back when both sides are satisfied that understanding has been reached. Otherwise, it adds a lot of

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Wed, Dec 21, 2016 at 01:35:56AM +, Peter Robinson wrote: > > ...and actual QA, from the professionals and volunteers on the QA team, > > who are very good at finding bugs pre-release but currently do zero QA > > on our updates because it's an unmanageable rolling stream of a > > bazillion

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 10:25 PM Gerald B. Cox wrote: > > On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote: > > I don't see any context missing in a direct quote which I responded to. > If you believe otherwise, feel free to summarize your position and include > any context you need to. > >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote: > I don't see any context missing in a direct quote which I responded to. > If you believe otherwise, feel free to summarize your position and include > any context you need to. > That's ok... I don't think you'd get the

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 9:59 PM Gerald B. Cox wrote: > > " KDE folks by and large want the updates as fast as possible. If the > GNOME folks would like > their updates to age for six months, they can just keep them in > updates-testing." > > > Obviously you missed it. Again, you have to take

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 6:41 PM, Rahul Sundaram wrote: > > " KDE folks by and large want the updates as fast as possible. If the > GNOME folks would like > their updates to age for six months, they can just keep them in > updates-testing." > Obviously you missed it. Again,

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 9:33 PM Gerald B. Cox wrote: > > > Right. I understand that but the solution of letting things stay in > updates-testing for a long time isn't a great way to implement that. It an > abuse of updates-testing. > > > No one is doing that. You have to read

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 6:30 PM, Rahul Sundaram wrote: > > Right. I understand that but the solution of letting things stay in > updates-testing for a long time isn't a great way to implement that. It an > abuse of updates-testing. > No one is doing that. You have to read

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 9:26 PM Gerald B. Cox wrote: > > I was just repeating what I thought was a good suggestion - which is based > upon what has > already been implemented using the current infrastructure. Reserve "new" > releases only for things > that absolutely require it and let

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 5:45 PM, Rahul Sundaram wrote: > Well, it isn't some theoretical construct... it's being done now with KDE >> and has >> been working just fine. It stays in updates-testing until you decide to >> push it to stable. KDE >> folks by and large want the

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 1:23 PM Gerald B. Cox wrote: > Well, it isn't some theoretical construct... it's being done now with KDE > and has > been working just fine. It stays in updates-testing until you decide to > push it to stable. KDE > folks by and large want the updates as fast as

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

>> The only way it reduces the risk of releasing a botched update is >> the >> the updates somehow get more testing just by staying in the testing >> channel longer. > > ...and actual QA, from the professionals and volunteers on the QA team, > who are very good at finding bugs pre-release but

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 10:22:41AM -0800, Gerald B. Cox wrote: > Well, it isn't some theoretical construct... it's being done now with > KDE and has been working just fine. It stays in updates-testing until > you decide to push it to stable. KDE folks by and large want the > updates as fast as

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 10:08 AM, Matthew Miller wrote: > On Tue, Dec 20, 2016 at 10:01:57AM -0800, Gerald B. Cox wrote: > > I'll repost this because I believe Kevin had a good point: > > > > I don't understand why we are trying to reinvent the wheel here. The > >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

Maybe a bit bit off topic WRT $Subject, sorry if it is the case. On Tuesday, December 20, 2016 8:23:12 AM CET Michael Catanzaro wrote: > Batched updates are something I really want to do regardless. > Of course having fixes available sooner is valuable, but you have to weigh > that against the

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 10:01:57AM -0800, Gerald B. Cox wrote: > I'll repost this because I believe Kevin had a good point: > > I don't understand why we are trying to reinvent the wheel here. The > infrastructure for Kevin's suggestion > is in place now - KDE has been using it and it works.

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 12/20/2016 09:34 AM, Adam Williamson wrote: On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote: Batched updates are valuable when testing happens with the whole. It sorts out complex interactions between multiple package updates by testing them all together. Of course, a corollary

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

I'll repost this because I believe Kevin had a good point: I don't understand why we are trying to reinvent the wheel here. The infrastructure for Kevin's suggestion is in place now - KDE has been using it and it works. On Thu, Dec 8, 2016 at 9:07 PM, Kevin Kofler

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 20/12/16 17:40, Adam Williamson wrote: On Tue, 2016-12-20 at 17:15 +, Tom Hughes wrote: I didn't think updates-testing would be, it's just I don't think many people use it so I'm not sure having things there for longer will actually help. We do in fact have numbers on this. For

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 09:33 -0800, Adam Williamson wrote: > If we're talking about *weekly* batched > updates, no, it is not at all practical to assume we'll magically be > able to find the time to do release-validation level testing of each > update batch every week. Of course it wouldn't make

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 17:15 +, Tom Hughes wrote: > I didn't think updates-testing would be, it's just I don't think many > people use it so I'm not sure having things there for longer will > actually help. We do in fact have numbers on this. For instance, since F25 came out, 218 people have

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote: > Batched updates are valuable when testing happens with the whole.  It > sorts out complex interactions between multiple package updates by > testing them all together. Of course, a corollary of this is that you have to try and figure

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 10:48 -0600, Michael Catanzaro wrote: > On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: > > Surely it's more likely that it just delays the discovery of the > > botched  > > update? > > I don't think updates-testing should be batched. Testers should of > course still

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 2:32 AM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote: > [...] >> I would like to see us stop pushing non security updates to updates from >> updates-testing entirely and do it in monthly

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 2:32 AM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote: > [...] >> I would like to see us stop pushing non security updates to updates from >> updates-testing entirely and do it in monthly

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 20/12/16 16:48, Michael Catanzaro wrote: On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: Surely it's more likely that it just delays the discovery of the botched update? I don't think updates-testing should be batched. Testers should of course still get all test updates ASAP. I

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 12/20/2016 06:27 AM, Tom Hughes wrote: On 20/12/16 14:23, Michael Catanzaro wrote: Batched updates are something I really want to do regardless. Of course having fixes available sooner is valuable, but you have to weigh that against the cost of releasing a *botched* update. The advantage of

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: > Surely it's more likely that it just delays the discovery of the > botched  > update? I don't think updates-testing should be batched. Testers should of course still get all test updates ASAP. > The only way it reduces the risk of releasing

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Thursday, December 8, 2016 9:17:14 AM CET Matthew Miller wrote: > Trying to make this idea a little more concrete. Here's two suggestions > for how it might work. These are strawman ideas -- please provide > alternates, poke holes, etc. And particularly from a QA and rel-eng > point of view.

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 20/12/16 14:23, Michael Catanzaro wrote: Batched updates are something I really want to do regardless. Of course having fixes available sooner is valuable, but you have to weigh that against the cost of releasing a *botched* update. The advantage of batched updates is we reduce the risk of

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 10:32 +0100, Dominik 'Rathann' Mierzejewski wrote: > You gave just one disadvantage of this proposal and no advantages at > all. Why do you think the above is a good idea? I, for one, do not > like > waiting a month to get bug fixes that are not security-related. We > are >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote: [...] > I would like to see us stop pushing non security updates to updates from > updates-testing entirely and do it in monthly batches instead. we would push > daily security fixes and updates-testing. However this would make

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 09, 2016 at 12:12:56PM -0800, Adam Williamson wrote: > > What if we combined this time threshold with, also, auto-pushes happen > > only on Monday (or whatever)? > I wouldn't hate it. On a visceral level I've never bought the 'batched > updates' idea at all, but if it only affects

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 09, 2016 at 12:54:29PM -0800, Adam Williamson wrote: > On Fri, 2016-12-09 at 21:29 +0100, Michael Schwendt wrote: > > Of course, the developers of bodhi would need to be convinced of such a > > feature, too, and it could be that there is no big kahuna to do exactly > > that. Oh well. >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Dec 11, 2016 9:00 PM, "Chris Murphy" wrote: On Sun, Dec 11, 2016 at 3:10 PM, Neal Gompa wrote: > On Fri, Dec 9, 2016 at 5:58 PM, Matthew Miller wrote: >> On Fri, Dec 09, 2016 at 10:22:44PM +, Peter Robinson wrote:

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Sun, Dec 11, 2016 at 3:10 PM, Neal Gompa wrote: > On Fri, Dec 9, 2016 at 5:58 PM, Matthew Miller > wrote: >> On Fri, Dec 09, 2016 at 10:22:44PM +, Peter Robinson wrote: >>> repo data). The full list makes up most of the 40Mb downloaded. The

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 9, 2016 at 5:58 PM, Matthew Miller wrote: > On Fri, Dec 09, 2016 at 10:22:44PM +, Peter Robinson wrote: >> repo data). The full list makes up most of the 40Mb downloaded. The >> dnf developers seem to think that everyone has lots of data/bandwidth >> and

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 9, 2016 at 10:58 PM, Matthew Miller wrote: > On Fri, Dec 09, 2016 at 10:22:44PM +, Peter Robinson wrote: >> repo data). The full list makes up most of the 40Mb downloaded. The >> dnf developers seem to think that everyone has lots of data/bandwidth >> and

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 12/09/2016 03:26 PM, Matthew Miller wrote: On Fri, Dec 09, 2016 at 03:19:58PM -0500, langdon wrote: Langdon is sitting right next to me right now and I'm going to tag him in for more on Modularity. [...] them. We can also decide when a "release" makes sense based on marketing or other

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Thu, 8 Dec 2016 12:40:49 -0500 Przemek Klosowski wrote: > On 12/08/2016 11:10 AM, Matthew Miller wrote: > > It's my plan to explore different ideas to continue to make Fedora > > more successful as measured by user and contributor growth, > > contributor return on

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Friday, December 9, 2016, Matthew Miller wrote: > On Fri, Dec 09, 2016 at 03:19:58PM -0500, langdon wrote: > > >Langdon is sitting right next to me right now and I'm going to tag him > > >in for more on Modularity. > [...] > > them. We can also decide when a

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 09, 2016 at 10:22:44PM +, Peter Robinson wrote: > repo data). The full list makes up most of the 40Mb downloaded. The > dnf developers seem to think that everyone has lots of data/bandwidth > and don't see the problem with it. Isn't the problem that the SAT solver used by DNF for

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

>>> > problem. The fact that updates default to auto-push after +3 karma is >>> > entirely plucked out of the air, it's just something someone made up >>> > one day. We could *certainly* change that. I'd be quite interested in a >>> > tweak where there's a minimum-time-in-testing value for

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 14:31 -0600, Michael Catanzaro wrote: > On Fri, 2016-12-09 at 12:25 -0800, Adam Williamson wrote: > > Software will check for new updates at most every 48 hours, so if > > there > > happen to *be* new updates every 48 hours and your system is running > > the whole time, yeah,

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 21:29 +0100, Michael Schwendt wrote: > Of course, the developers of bodhi would need to be convinced of such a > feature, too, and it could be that there is no big kahuna to do exactly > that. Oh well. Well, no, you could just send a patch. Bodhi is a rather nice codebase

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 12:25 -0800, Adam Williamson wrote: > Software will check for new updates at most every 48 hours, so if > there > happen to *be* new updates every 48 hours and your system is running > the whole time, yeah, you can get 3-and-a-bit update notifications > per > week. Not

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 09 Dec 2016 11:00:45 -0800, Adam Williamson wrote: > > Same applies to your usage scenario. Personal experience is just that: > > personal experience. > > Yes, but the burden of proof always lies with those who want to change > stuff. I've got the easy job here: I just get to say

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 09, 2016 at 03:19:58PM -0500, langdon wrote: > >Langdon is sitting right next to me right now and I'm going to tag him > >in for more on Modularity. [...] > them. We can also decide when a "release" makes sense based on > marketing or other considerations and just "pull the trigger" on

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 13:21 -0700, Chris Murphy wrote: > On Fri, Dec 9, 2016 at 1:12 PM, Adam Williamson > wrote: > > On Fri, 2016-12-09 at 15:05 -0500, Matthew Miller wrote: > > > On Fri, Dec 09, 2016 at 11:55:26AM -0800, Adam Williamson wrote: > > > > problem. The

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 9, 2016 at 1:12 PM, Adam Williamson wrote: > On Fri, 2016-12-09 at 15:05 -0500, Matthew Miller wrote: >> On Fri, Dec 09, 2016 at 11:55:26AM -0800, Adam Williamson wrote: >> > problem. The fact that updates default to auto-push after +3 karma is >> >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 12/09/2016 02:52 PM, Matthew Miller wrote: On Fri, Dec 09, 2016 at 08:50:06AM -0800, Adam Williamson wrote: So, *did* you feel that the F25 cycle felt compressed? If we're close enough to the theoretical-world above that we feel like we can do, say, four month cycles to stay on track without

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 15:05 -0500, Matthew Miller wrote: > On Fri, Dec 09, 2016 at 11:55:26AM -0800, Adam Williamson wrote: > > problem. The fact that updates default to auto-push after +3 karma is > > entirely plucked out of the air, it's just something someone made up > > one day. We could

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 09, 2016 at 11:55:26AM -0800, Adam Williamson wrote: > problem. The fact that updates default to auto-push after +3 karma is > entirely plucked out of the air, it's just something someone made up > one day. We could *certainly* change that. I'd be quite interested in a > tweak where

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 20:46 +0100, Michael Schwendt wrote: > On Fri, 9 Dec 2016 19:41:28 +0100, Ralf Corsepius wrote: > > > And? What*s the problem? It's part of a packagers job to balance the > > tradeoffs and find a viable compromise. > > You don't need to agree. In the reply you've

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 09, 2016 at 08:50:06AM -0800, Adam Williamson wrote: > > So, *did* you feel that the F25 cycle felt compressed? If we're close > > enough to the theoretical-world above that we feel like we can do, say, > > four month cycles to stay on track without experiencing (particular) > > pain,

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 9 Dec 2016 19:41:28 +0100, Ralf Corsepius wrote: > And? What*s the problem? It's part of a packagers job to balance the > tradeoffs and find a viable compromise. You don't need to agree. In the reply you've truncated, I've only pointed out how I feel about the updates flood. It's my

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 9, 2016 at 11:00 AM, Adam Williamson wrote: > Yes, but the burden of proof always lies with those who want to change > stuff. I've got the easy job here: I just get to say 'look, if you want > to change everything, provide some concrete evidence: > > a)

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 9, 2016 at 4:51 AM, Michael Schwendt wrote: > And there it is again, the rush to get out updates. Quickly! Quickly! > What has been released before is not bug-free, and the update are not > bug-free either, and even if no user has reported a bug, the flow of >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 19:48 +0100, Michael Schwendt wrote: > On Fri, 09 Dec 2016 09:40:08 -0800, Adam Williamson wrote: > > > This is just a bunch of entirely unsupported assertions, and thus not > > worth the time to respond to. > > Same applies to your usage scenario. Personal experience is

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 09 Dec 2016 09:40:08 -0800, Adam Williamson wrote: > This is just a bunch of entirely unsupported assertions, and thus not > worth the time to respond to. Same applies to your usage scenario. Personal experience is just that: personal experience. > But I'll just note that it is not

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 12/09/2016 01:51 PM, Michael Schwendt wrote: On Fri, 09 Dec 2016 06:07:02 +0100, Kevin Kofler wrote: If as a maintainer you don't release version upgrades quickly, some users complain everywhere they are permitted to post. Except for bugzilla. And if you make available upgrades quickly,

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Qui, 2016-12-08 at 09:17 -0500, Matthew Miller wrote: > Trying to make this idea a little more concrete. Here's two > suggestions > for how it might work. These are strawman ideas -- please provide > alternates, poke holes, etc. And particularly from a QA and rel-eng > point of view. Both of

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

On 12/09/2016 11:17 AM, Matthew Miller wrote: For other software, where users would like the version to match more closely the long lifecycle, maybe there could be a hand-off from Fedora version to CentOS version. Yeah, hand-offs would be a great feature for the users. Right now, it's tricky to

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 18:37 +0100, Michael Schwendt wrote: > On Fri, 09 Dec 2016 08:44:26 -0800, Adam Williamson wrote: > > > On Fri, 2016-12-09 at 13:18 +0100, Michael Schwendt wrote: > > > The apparently random flow of poorly tested "rushed out" updates > > > > > > Nah, not needed at all.

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 09 Dec 2016 08:44:26 -0800, Adam Williamson wrote: > On Fri, 2016-12-09 at 13:18 +0100, Michael Schwendt wrote: > > The apparently random flow of poorly tested "rushed out" updates > > Nah, not needed at all. Basically, one can update a desktop workstation to death, if applying

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

On Fri, Dec 9, 2016 at 12:14 PM, Igor Gnatenko wrote: > On Dec 9, 2016 5:18 PM, "Matthew Miller" wrote: > > On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote: >> > Anyways, in the big picture, while I don't speak for everyone on

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

On Dec 9, 2016 5:18 PM, "Matthew Miller" wrote: On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote: > > Anyways, in the big picture, while I don't speak for everyone on > > the Project Atomic side, I personally point users at CentOS first, > > unless I have

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

On 9 December 2016 at 11:42, Nikos Mavrogiannopoulos wrote: > On Fri, 2016-12-09 at 11:17 -0500, Matthew Miller wrote: >> On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote: >> > > Anyways, in the big picture, while I don't speak for everyone on >> > > the Project

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 11:03 -0500, Matthew Miller wrote: > So, *did* you feel that the F25 cycle felt compressed? If we're close > enough to the theoretical-world above that we feel like we can do, say, > four month cycles to stay on track without experiencing (particular) > pain, maybe that's

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, 2016-12-09 at 13:18 +0100, Michael Schwendt wrote: > The apparently random flow of poorly tested "rushed out" updates I've had automatic updates, of all kinds, turned on on all of my servers for at least the last four releases, and can think of maybe one time one of them broke? This

Re: a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

On Fri, 2016-12-09 at 11:17 -0500, Matthew Miller wrote: > On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote: > > > Anyways, in the big picture, while I don't speak for everyone on > > > the Project Atomic side, I personally point users at CentOS > > > first, > > > unless I have some

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 9, 2016 at 11:30 AM, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Dec 09, 2016 at 01:18:31PM +0100, Michael Schwendt wrote: >> On Thu, 8 Dec 2016 19:45:55 +0100, Christian Dersch wrote: >> >> > On 12/08/2016 07:26 PM, Dennis Gilmore wrote: >> > > I would like to see

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 9 December 2016 at 11:07, Colin Walters wrote: > On Thu, Dec 8, 2016, at 09:26 PM, Colin Walters wrote: > >> Anyways, in the big picture, while I don't speak for everyone on the Project >> Atomic side, >> I personally point users at CentOS first, unless I have some reason

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Fri, Dec 09, 2016 at 01:18:31PM +0100, Michael Schwendt wrote: > On Thu, 8 Dec 2016 19:45:55 +0100, Christian Dersch wrote: > > > On 12/08/2016 07:26 PM, Dennis Gilmore wrote: > > > I would like to see us stop pushing non security updates to updates from > > > updates-testing entirely and do

a diversion into EPEL [was Re: Two more concrete ideas for what a once-yearly+update schedule would look like]

On Fri, Dec 09, 2016 at 11:07:32AM -0500, Colin Walters wrote: > > Anyways, in the big picture, while I don't speak for everyone on > > the Project Atomic side, I personally point users at CentOS first, > > unless I have some reason to think they want Fedora. Something like > > 80% of Fedora usage

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Thu, Dec 8, 2016, at 09:26 PM, Colin Walters wrote: > Anyways, in the big picture, while I don't speak for everyone on the Project > Atomic side, > I personally point users at CentOS first, unless I have some reason to think > they want Fedora. > Something like 80% of Fedora usage hitting

  1   2   >