On Wed, Nov 14, 2018 at 05:43:15PM -0500, Matthew Miller wrote:
> On Wed, Nov 14, 2018 at 10:30:06PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > I love Fedora, but the idea that you can take a 3 year old Fedora and
> > put it out on the web is just bonkers. We don't have the manpower and
> > the
Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-11-15 17:00 UTC in #fedora-meeting-1 on
irc.freenode.net.
Local time information (via. uitime):
= Day: Thursday ==
2018-11-15 09:00 PST US/Pacific
On Wednesday, November 14, 2018, Laura Abbott wrote:
> On 11/14/18 5:29 AM, Matthew Miller wrote:
>
>> On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote:
>>
>>> Do we have any user data about what "stability" means to users and on
>>> what
>>> different levels that can be achieved? Is
No missing expected images.
Failed openQA tests: 37/142 (x86_64), 5/24 (i386), 1/2 (arm)
New failures (same test did not fail in Rawhide-20181113.n.0):
ID: 308758 Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/308758
ID: 308763 Test: x86_64
OLD: Fedora-Rawhide-20181113.n.0
NEW: Fedora-Rawhide-20181114.n.0
= SUMMARY =
Added images:2
Dropped images: 0
Added packages: 5
Dropped packages:9
Upgraded packages: 186
Downgraded packages: 0
Size of added packages: 7.31 MiB
Size of dropped packages
https://bugzilla.redhat.com/show_bug.cgi?id=1636863
--- Comment #2 from Fedora Update System ---
perl-Regexp-Grammars-1.049-1.fc29 has been pushed to the Fedora 29 testing
repository. If problems still persist, please make note of it in this bug
report.
See
Hello people,
I'm a Gluster engineer and have joined the Fedora community with an effort
to factor off the Glusterfs SELinux bits off the primary
selinux-policy-targeted package. This factoring with help the distribution
SELinux policy maintainers as well as Gluster engineers to ship their
https://bugzilla.redhat.com/show_bug.cgi?id=1646144
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-RDF-NS-20181102-1.fc30 |perl-RDF-NS-20181102-1.fc30
https://bugzilla.redhat.com/show_bug.cgi?id=1646135
--- Comment #10 from Fedora Update System ---
perl-DB_File-1.843-1.fc29 has been pushed to the Fedora 29 stable repository.
If problems still persist, please make note of it in this bug report.
--
You are receiving this mail because:
You
https://bugzilla.redhat.com/show_bug.cgi?id=1646993
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1646135
--- Comment #9 from Fedora Update System ---
perl-DB_File-1.843-1.fc28 has been pushed to the Fedora 28 stable repository.
If problems still persist, please make note of it in this bug report.
--
You are receiving this mail because:
You are
https://bugzilla.redhat.com/show_bug.cgi?id=1646144
Fedora Update System changed:
What|Removed |Added
Fixed In Version|perl-RDF-NS-20181102-1.fc30 |perl-RDF-NS-20181102-1.fc30
https://fedorapeople.org/groups/389ds/ci/nightly/2018/11/15/report-389-ds-base-1.4.0.16-1.fc29.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code
https://bugzilla.redhat.com/show_bug.cgi?id=1646144
Fedora Update System changed:
What|Removed |Added
Status|ON_QA |CLOSED
Fixed In
https://bugzilla.redhat.com/show_bug.cgi?id=1646135
--- Comment #8 from Fedora Update System ---
perl-DB_File-1.843-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.
--
You are receiving this mail because:
You are
The major OS competitor has moved to a 6 month release cadence, so that
needs to be taken into account.
I suspect the easiest way to have a longer supported system is by NOT
having a longer supported system. For the case of desktop hardware vendors
something like a constantly updating silverblue
On Wed, Nov 14, 2018 at 4:42 PM, John Florian
wrote:
I still don't understand what makes updating these for a *new*
release significantly easier than an *existing* one. So let's
just say GNOME (or whatever) comes out next month with a new major
release we want to showcase. Why is it necessary
On Wed, Nov 14, 2018 at 6:04 PM Stephen John Smoogen wrote:
>
> On Wed, 14 Nov 2018 at 16:03, Ben Rosser wrote:
> >
> > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen
> > wrote:
> > > From what I have talked with in the past.. 3 years is their bare
> > > minimum and 7 is their what we
On 11/14/18 2:42 PM, John Florian wrote:
> I still don't understand what makes updating these for a *new* release
> significantly easier than an *existing* one. So let's just say GNOME
> (or whatever) comes out next month with a new major release we want to
> showcase. Why is it necessary to
On 11/14/18 5:29 AM, Matthew Miller wrote:
On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote:
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime
On 11/14/18 1:26 PM, Carmen Bianca Bakker wrote:
Je mer, 2018-11-14 je 18:34 +0100, Kevin Kofler skribis:
That is what make us different distro with its own user base. Want the
very same but LTS system? try CentOS. Or RHEL.
+1. LTS Fedora is what CentOS is for. Why should we not just point
On Wed, Nov 14, 2018 at 10:30:06PM +, Zbigniew Jędrzejewski-Szmek wrote:
> I love Fedora, but the idea that you can take a 3 year old Fedora and
> put it out on the web is just bonkers. We don't have the manpower and
> the procedures to make Fedora suitable for this kind of use.
We,
On 11/14/18 4:38 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Nov 14, 2018 at 12:37:46PM -0500, John Florian wrote:
On 11/14/18 10:36 AM, mcatanz...@gnome.org wrote:
We need to rebase GNOME within about two months of the new
upstream releases, or we'll lose our edge with the GNOME
On 11/14/18 2:35 AM, Daniel P. Berrangé wrote:
If Fedora had longer life cycles, and more streams maintained in
parallel, then I think the result would be that I end up doing
rebases for everything I maintain rather than trying to backport
anything. Admittedly this would somewhat negate the
On Wed, Nov 14, 2018 at 05:09:18PM -0500, Matthew Miller wrote:
> On Wed, Nov 14, 2018 at 09:54:45PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > > The answer is "a lot". I don't think we have any hard numbers, but
> > > > see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
> >
On 13 November 2018 23:36:38 GMT, Matthew Miller wrote:
>
>Hi everyone! Let's talk about something new and exciting.
Assuming a system that is automatically updating, but doesn't get upgraded to
the next fedora release - a system like this needs to degrade progressively but
securely: after
On Wed, 14 Nov 2018 at 16:03, Ben Rosser wrote:
>
> On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen wrote:
> > From what I have talked with in the past.. 3 years is their bare
> > minimum and 7 is their what we really want. It usually takes the
> > vendor about 3-6 months of work to make
On 11/14/18 6:29 AM, Matthew Miller wrote:
On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote:
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime
On Wed, Nov 14, 2018 at 09:54:45PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > The answer is "a lot". I don't think we have any hard numbers, but
> > > see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
> > > process the CVEs we get now.
> > > "This result was limited to 1000
El mié., 14 nov. 2018 20:09, Matthew Miller
escribió:
> On Wed, Nov 14, 2018 at 06:11:48PM +0100, Iñaki Ucar wrote:
> > > Mostly blue sky -- let's generate ideas! -- but let's also stay within
> > > reasonable possibilities, and also, you know, keeping it Fedora.
> > > Particularly, I'm pretty
Josh Boyer (jwbo...@fedoraproject.org) said:
> > > If 7 years is what manufacturers really want, then it sounds like
> > > CentOS is much better positioned to be get shipped on laptops than
> > > Fedora. Instead of working on a new "Fedora LTS" for this usage case,
> > > would time be better
On Wed, Nov 14, 2018 at 04:48:04PM -0500, Matthew Miller wrote:
> On Wed, Nov 14, 2018 at 09:29:31PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > The answer is "a lot". I don't think we have any hard numbers, but
> > see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
> > process
On Wed, Nov 14, 2018 at 4:20 PM Bill Nottingham wrote:
>
> Ben Rosser (rosser@gmail.com) said:
> > On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen
> > wrote:
> > > From what I have talked with in the past.. 3 years is their bare
> > > minimum and 7 is their what we really want. It
On Wed, Nov 14, 2018 at 09:29:31PM +, Zbigniew Jędrzejewski-Szmek wrote:
> The answer is "a lot". I don't think we have any hard numbers, but
> see https://pagure.io/fesco/issue/1935. Generally, it seems we can't
> process the CVEs we get now.
> "This result was limited to 1000 bugs." → that's
On Wed, Nov 14, 2018 at 12:37:46PM -0500, John Florian wrote:
> On 11/14/18 10:36 AM, mcatanz...@gnome.org wrote:
> >We need to rebase GNOME within about two months of the new
> >upstream releases, or we'll lose our edge with the GNOME
> >community. We'd be ceding our position as best GNOME distro
On Wed, Nov 14, 2018 at 11:11:59AM -0700, Ken Dreyer wrote:
> On Tue, Nov 13, 2018 at 4:37 PM Matthew Miller
> wrote:
> > But there are some good cases for a longer lifecycle. For one thing,
> > this has been a really big blocker for getting Fedora shipped on
> > hardware.
>
> This is an
Ben Rosser (rosser@gmail.com) said:
> On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen wrote:
> > From what I have talked with in the past.. 3 years is their bare
> > minimum and 7 is their what we really want. It usually takes the
> > vendor about 3-6 months of work to make sure the OS
On Wed, Nov 14, 2018 at 2:55 PM Stephen John Smoogen wrote:
> From what I have talked with in the past.. 3 years is their bare
> minimum and 7 is their what we really want. It usually takes the
> vendor about 3-6 months of work to make sure the OS works on their
> hardware without major problems
Dear all,
It is now possible to use bodhi to release a new container build. Currently
it is following the same flow as packages.
After a successful OSBS build, a bodhi update can be created. Fedpkg does
not yet support creating updates for containers [0], so you have to either
use bodhi web UI
On 11/14/18 12:36 AM, Matthew Miller wrote:
>
> So, what would this look like? I have some ideas, but, really, there
> are many possibilities. That's what this thread is for. Let's figure it
> out. How would we structure repositories? How would we make sure we're
> not overworked? How would we
Today we are starting the Nomination & Campaign period during which we
accept nominations to the "steering bodies" of the following teams:
* FESCo (Engineering) (5 seats) [1]
* Fedora Council (1 seat) [2]
* Mindshare (1 seat) [3]
This period is open until 2018-Nov-28 at 23:59:59 UTC.
Candidates
Today we are starting the Nomination & Campaign period during which we
accept nominations to the "steering bodies" of the following teams:
* FESCo (Engineering) (5 seats) [1]
* Fedora Council (1 seat) [2]
* Mindshare (1 seat) [3]
This period is open until 2018-Nov-28 at 23:59:59 UTC.
Candidates
On Wed, 14 Nov 2018 at 11:45, wrote:
>
> On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller
> wrote:
>
> But there are some good cases for a longer lifecycle. For one thing, this has
> been a really big blocker for getting Fedora shipped on hardware. Second,
> there are people who really could
On Wed, 14 Nov 2018 at 13:00, Troy Dawson wrote:
>
> Here are the list of packages with bad dependencies, their bug URL,
> and current status.
> For those that still have "No Comment" tomorrow, I will start going
> through and fixing.
> For those that want to be removed, I'll be doing that
Je mer, 2018-11-14 je 18:34 +0100, Kevin Kofler skribis:
> > That is what make us different distro with its own user base. Want the
> > very same but LTS system? try CentOS. Or RHEL.
>
> +1. LTS Fedora is what CentOS is for. Why should we not just point users who
> want LTS to CentOS and EPEL?
On Tue, Nov 13, 2018 at 4:37 PM Matthew Miller wrote:
> But there are some good cases for a longer lifecycle. For one thing,
> this has been a really big blocker for getting Fedora shipped on
> hardware.
This is an interesting topic to me because I recently toured the
System76 factory here in
I think different people want different things from an LTS though. CentOS
makes it hard to do e.g. Postgres 10 and Python3 which Ubuntu ships out of the
box in 1804. Modularity seems like it will help in this regard.
> On Nov 14, 2018, at 11:39 AM, Kevin Kofler wrote:
>
> Ralf Corsepius
On Wed, Nov 14, 2018 at 06:11:48PM +0100, Iñaki Ucar wrote:
> > Mostly blue sky -- let's generate ideas! -- but let's also stay within
> > reasonable possibilities, and also, you know, keeping it Fedora.
> > Particularly, I'm pretty sure about the goals: 1. getting Fedora desktop and
> > IoT
I concur. This is effectively what I was trying to express with respect to the
distinctions.
On November 14, 2018 12:39:40 PM EST, Kevin Kofler
wrote:
>Ralf Corsepius wrote:
>> This would be my proposal, also. I would simply extend the release
>> cycles to 1 year and to return to the roots.
Ralf Corsepius wrote:
> This would be my proposal, also. I would simply extend the release
> cycles to 1 year and to return to the roots. I.e. make a distro, and
> drop "rings" "modules" and "spins".
Rings and modules should go away indeed, but spins should not! We have had
spins since Fedora 7!
On 11/14/18 10:36 AM, mcatanz...@gnome.org wrote:
We need to rebase GNOME within about two months of the new upstream
releases, or we'll lose our edge with the GNOME community. We'd be
ceding our position as best GNOME distro to Ubuntu and Arch.
It seems wrong that a DE, even if it's the
Michal Schorm wrote:
> We, as a distro, just take a different approach.
> To be bleeding edge requires to have releases often.
>
> That allow us to manage changes like GCC, OpenSSL and so on quickly.
> Struggling with upstream who don't adapt, can't adapt or don't want to
> adapt at the same
On Wed, Nov 14, 2018 at 11:44 AM Randy Barlow
wrote:
> On Wed, 2018-11-14 at 11:56 +0100, Igor Gnatenko wrote:
> > > > > This was not approved - there was a -1 vote and so it was
> > > > > planned to be
> > > > > discussed in the next meeting.
> > > >
> > > > I commented the ticket, but I will
On Wed, 14 Nov 2018 at 15:25, Matthew Miller wrote:
>
> Mostly blue sky -- let's generate ideas! -- but let's also stay within
> reasonable possibilities, and also, you know, keeping it Fedora.
> Particularly, I'm pretty sure about the goals: 1. getting Fedora desktop and
> IoT shipped on systems
Here are the list of packages with bad dependencies, their bug URL,
and current status.
For those that still have "No Comment" tomorrow, I will start going
through and fixing.
For those that want to be removed, I'll be doing that tomorrow as well.
airinv
On Wed, Nov 14, 2018 at 10:41:17AM -0600, mcatanz...@gnome.org wrote:
> It's a possibility... I'd rather call it .5 for halfway, though.
> F30, F30.5, F31... ehh, it would be OK, but there should be real
> concrete gain if we do this. It gets us no closer to a 36 month
> lifetime.
Well, it would
On Mon, 12 Nov 2018 at 15:35, Jaroslav Mracek wrote:
>
> Hello everyone,
>
> There was an announcement of release libsolv-0.7.0 ([HEADS UP] libsolv 0.7)
> into rawhide, but the rebase also ended up in stable branches of Fedora 28
> and 29. This release could affect not only libsolv users, but
On Wed, 2018-11-14 at 11:56 +0100, Igor Gnatenko wrote:
> > > > This was not approved - there was a -1 vote and so it was
> > > > planned to be
> > > > discussed in the next meeting.
> > >
> > > I commented the ticket, but I will copy my response here: there
> > > was no
> > > single -1 within a
On Wed, Nov 14, 2018 at 10:31 AM, Matthew Miller
wrote:
Is there a way we could do these as ".1" releases, with orchestrated
QA for
the big update rather than a whole release?
It's a possibility... I'd rather call it .5 for halfway, though.
F30, F30.5, F31... ehh, it would be OK, but there
Thanks for starting this discussion, Matthew!
A few notes:
* My personal long-term dream is that all Fedora users are running
Silverblue, we do great automated QA testing, and upgrading from one
Fedora to the next is a non-event, and opt-out rather than opt-in, and
long term support would not
On Wed, Nov 14, 2018 at 09:54:27AM -0600, mcatanz...@gnome.org wrote:
> Is 36 months an absolute minimum for getting onto consumer laptops?
Based on the conversations I've had, yes. We might be able to get some niche
acceptance with 27 months.
--
Matthew Miller
Fedora Project Leader
On Wed, Nov 14, 2018 at 09:36:01AM -0600, mcatanz...@gnome.org wrote:
> We need to rebase GNOME within about two months of the new upstream
> releases, or we'll lose our edge with the GNOME community. We'd be
> ceding our position as best GNOME distro to Ubuntu and Arch. So a
> one-year cycle
https://bugzilla.redhat.com/show_bug.cgi?id=1636863
--- Comment #1 from Fedora Update System ---
perl-Regexp-Grammars-1.049-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-cb569ba2ba
--
You are receiving this mail because:
You are on
On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller
wrote:
But there are some good cases for a longer lifecycle. For one thing,
this has been a really big blocker for getting Fedora shipped on
hardware. Second, there are people who really could be happily running
Fedora but since we don't check the
The following commits were pushed to the repo rpms/perl-Regexp-Grammars on
branch
f29, which you are following:
30ddc112216f89bb428f73e96d40a910527a997bBill Pembertonupdate to version
1.049
To view more about the commits, visit:
On Wed, Nov 14, 2018 at 04:29:22PM +0100, Ralf Corsepius wrote:
> On 11/14/18 4:08 PM, Gerald Henriksen wrote:
> > On Wed, 14 Nov 2018 06:12:11 +0100, you wrote:
> >
> > > We, as a distro, just take a different approach.
> > > To be bleeding edge requires to have releases often.
> >
> > Such a
On Wed, Nov 14, 2018 at 9:29 AM, Ralf Corsepius
wrote:
Absolutely. Fedora once was a pretty solid end-user distro and
fun-project for devs. Now it has become an unstable, experimental
"bleeding edge" distro with a more and more balloning overhead.
I don't agree at all. Fedora is great. We
On Wed, Nov 14, 2018 at 9:08 AM, Gerald Henriksen
wrote:
My feeling is part of the solution is to move to a yearly release
cycle. Unlike the early days of Fedora things just aren't changing as
quick in terms of the base of the OS - hardware support in the kernel
is generally excellent, and
On 11/14/18 4:08 PM, Gerald Henriksen wrote:
On Wed, 14 Nov 2018 06:12:11 +0100, you wrote:
We, as a distro, just take a different approach.
To be bleeding edge requires to have releases often.
Such a bleeding edge distro that it took 4 years for Swift to arrive,
or still trying to get rid
https://bugzilla.redhat.com/show_bug.cgi?id=1645426
Jitka Plesnikova changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
On Wed, 14 Nov 2018 06:12:11 +0100, you wrote:
>We, as a distro, just take a different approach.
>To be bleeding edge requires to have releases often.
Such a bleeding edge distro that it took 4 years for Swift to arrive,
or still trying to get rid of Python 2.
Regardless of what we think Fedora
On Wed, Nov 14, 2018 at 01:58:13PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Because each old version is different? The fact that a backport has
> been made for RHEL does not mean that this backport is appropriate for
> the given Fedora version. Iff this was so simple, we could just take
>
On Wed, Nov 14, 2018 at 08:36:46AM -0500, Matthew Miller wrote:
> On Wed, Nov 14, 2018 at 06:12:11AM +0100, Michal Schorm wrote:
> > We, as a distro, just take a different approach.
> > To be bleeding edge requires to have releases often.
>
> But being "bleeding edge" has never been what Fedora's
On Wed, 14 Nov 2018 at 11:26, Daniel P. Berrangé wrote:
> It is not so much whether we "care", but rather whether we have enough
> time in the day to get the expected work done. I can't magic up more
> time to work no matter how much I care to.
Exactly my situation too.
Richard.
The following commits were pushed to the repo rpms/perl-Lingua-EN-Fathom on
branch
master, which you are following:
bc36eaa1047f71958db5a291db02a523ae4384a3Jitka Plesnikova1.22 bump
To view more about the commits, visit:
On Wed, Nov 14, 2018 at 07:54:24AM -0500, Neal Gompa wrote:
> > If we reduce the non-LTS supported time from 13 months to, let's say, 7
> > months (2 months overlap to allow for time to upgrade) then perhaps it
> > could work? And then add a LTS branch that's supported for 3 years? We'd
> > have
The update frequency is twice a year, the method is fully documented:
https://fedoraproject.org/wiki/DNF_system_upgrade
Simply refresh, download, reboot and wait a little while ...
It's hardly a burden, I've got at least 5 machines that have been
upgraded this way since Fedora 13.
Op wo 14
On Wed, Nov 14, 2018 at 06:12:11AM +0100, Michal Schorm wrote:
> We, as a distro, just take a different approach.
> To be bleeding edge requires to have releases often.
But being "bleeding edge" has never been what Fedora's about, despite
getting that epithet slapped at us. Yes, we want
On Wed, Nov 14, 2018 at 02:26:09PM +0100, Carmen Bianca Bakker wrote:
> Je mer, 2018-11-14 je 12:28 +0100, Miroslav Suchý skribis:
> > This is the core issue. We only have a limited manpower. You have three
> > things to choose from: free of charge
> > distribution, long support, fresh versions
On Wed, Nov 14, 2018 at 12:32:14PM +0100, Adam Samalik wrote:
> Do we have any user data about what "stability" means to users and on what
> different levels that can be achieved? Is it about app versions such as
> MariaDB? is it about language runtime versions such as Node.js? is it about
>
On Wed, Nov 14, 2018 at 09:27:39AM -, Leigh Scott wrote:
> > out. How would we structure repositories? How would we make sure we're
> > not overworked? How would we balance this with getting people new stuff
> > fast as well?
> I'm already overworked supporting old releases for the current 13
On Tue, Nov 13, 2018 at 08:05:54PM -0500, Stephen John Smoogen wrote:
> > But there are some good cases for a longer lifecycle. For one thing,
> > this has been a really big blocker for getting Fedora shipped on
> > hardware. Second, there are people who really could be happily running
> > Fedora
Je mer, 2018-11-14 je 12:28 +0100, Miroslav Suchý skribis:
> This is the core issue. We only have a limited manpower. You have three
> things to choose from: free of charge
> distribution, long support, fresh versions of SW in distribution - but we can
> only choose two of them.
>
> [...]
>
>
On Wed, Nov 14, 2018 at 7:49 AM Kalev Lember wrote:
>
> On 11/14/2018 11:35 AM, Daniel P. Berrangé wrote:
> > If Fedora had longer life cycles, and more streams maintained in
> > parallel, then I think the result would be that I end up doing
> > rebases for everything I maintain rather than
On Wed, Nov 14, 2018 at 12:47:42PM +0100, Miroslav Suchý wrote:
> Dne 14. 11. 18 v 0:36 Matthew Miller napsal(a):
> > I'd love to change these things. To do that, we need
> > something that lasts for 36-48 months.
>
> So that means we will be supporting something like Fedora 23 nowadays. That
>
On 11/14/2018 11:35 AM, Daniel P. Berrangé wrote:
If Fedora had longer life cycles, and more streams maintained in
parallel, then I think the result would be that I end up doing
rebases for everything I maintain rather than trying to backport
anything. Admittedly this would somewhat negate the
Dne 14. 11. 18 v 0:36 Matthew Miller napsal(a):
> I'd love to change these things. To do that, we need
> something that lasts for 36-48 months.
So that means we will be supporting something like Fedora 23 nowadays. That is
Firefox 41, mock 1.2, dnf 1.1.3, ruby
2.2. systemd 222, kernel 4.2.3,
Do we have any user data about what "stability" means to users and on what
different levels that can be achieved? Is it about app versions such as
MariaDB? is it about language runtime versions such as Node.js? is it about
things like glibc? or kernel? Or does it need to be the whole distro as we
Dne 14. 11. 18 v 2:23 steve schooler napsal(a):
> I recognize that since Fedora is FREE, the developers face an enormous
> burden. However, I suspect that many will feel as I do that it is an onerous
> user-burden to have to frequently upgrade/re-install. Further,
> forum-technical-support,
On 11/14/18 12:56 PM, Igor Gnatenko wrote:
On Wed, Nov 14, 2018 at 10:14 AM Panu Matilainen wrote:
On 11/13/18 10:24 PM, Igor Gnatenko wrote:
On Tue, Nov 13, 2018 at 8:49 PM Randy Barlow
wrote:
On Tue, 2018-11-13 at 13:43 -0500, Neal Gompa wrote:
It wasn't a random rebase. A FESCo ticket
On Wed, Nov 14, 2018 at 10:14 AM Panu Matilainen wrote:
>
> On 11/13/18 10:24 PM, Igor Gnatenko wrote:
> > On Tue, Nov 13, 2018 at 8:49 PM Randy Barlow
> > wrote:
> >>
> >> On Tue, 2018-11-13 at 13:43 -0500, Neal Gompa wrote:
> >>> It wasn't a random rebase. A FESCo ticket was submitted and
>
On Wed, Nov 14, 2018 at 10:19:32AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Nov 14, 2018 at 06:12:11AM +0100, Michal Schorm wrote:
> > We, as a distro, just take a different approach.
> > To be bleeding edge requires to have releases often.
> >
> > That allow us to manage changes like
https://bugzilla.redhat.com/show_bug.cgi?id=1648489
--- Comment #6 from Ralf Corsepius ---
(In reply to Łukasz Trąbiński from comment #4)
Do you have a reproducer?
I can't reproduce this issue with rt-4.4.2 on F28 nor does its testsuite
trigger it.
--
You are receiving this mail because:
On Wed, Nov 14, 2018 at 06:12:11AM +0100, Michal Schorm wrote:
> We, as a distro, just take a different approach.
> To be bleeding edge requires to have releases often.
>
> That allow us to manage changes like GCC, OpenSSL and so on quickly.
> Struggling with upstream who don't adapt, can't adapt
> out. How would we structure repositories? How would we make sure we're
> not overworked? How would we balance this with getting people new stuff
> fast as well?
I'm already overworked supporting old releases for the current 13 months, most
of my time is spent on fedora next.
https://bugzilla.redhat.com/show_bug.cgi?id=1648489
Petr Pisar changed:
What|Removed |Added
Component|perl|rt
Assignee|jples...@redhat.com
On 11/13/18 10:24 PM, Igor Gnatenko wrote:
On Tue, Nov 13, 2018 at 8:49 PM Randy Barlow
wrote:
On Tue, 2018-11-13 at 13:43 -0500, Neal Gompa wrote:
It wasn't a random rebase. A FESCo ticket was submitted and
approved[1]. However, there was a miscommunication that led to the
DNF
team not
97 matches
Mail list logo
