* Neal Gompa:
> Sure, fork traps and such do still happen, but they're a lot rarer
> because that is much more painful with our current packaging model.
It's relatively painless once you write some scripts. Some teams
serialize some Git history to a long list of patches, some teams work
with
On Thu, Dec 6, 2018 at 7:59 AM Florian Weimer wrote:
>
> * Neal Gompa:
>
> > The problem with merged source trees (aka source-git) is that it
> > implies forking projects.
>
> But that's true for *any* distribution that wants to integrate things.
> I guess you could govern everything by build
On Thu, Dec 6, 2018 at 3:54 PM Ken Dreyer wrote:
>
> On Thu, Dec 6, 2018 at 6:12 AM Florian Weimer wrote:
> > I'm worried that this kind of pointless work makes it hard to attract
> > talent.
>
> Florian, you might want to check out rdopkg.
> https://github.com/softwarefactory-project/rdopkg .
On Thu, Dec 6, 2018 at 6:12 AM Florian Weimer wrote:
> I'm worried that this kind of pointless work makes it hard to attract
> talent.
Florian, you might want to check out rdopkg.
https://github.com/softwarefactory-project/rdopkg . It's a bit like
fedpkg, in that it's a CLI with sub-commands.
* Petr Pisar:
> On 2018-12-06, Florian Weimer wrote:
>> In a sense, it's the old discussion between explicit rename recording
>> and rename detection. I think it's clear by now that rename detection
>> has won.
> Can you give us some example of a rename detection that works?
I meant file
On 2018-12-06, Daniel P Berrangé wrote:
> On Thu, Dec 06, 2018 at 02:48:32PM +, Petr Pisar wrote:
>> On 2018-12-06, Florian Weimer wrote:
>> > In a sense, it's the old discussion between explicit rename recording
>> > and rename detection. I think it's clear by now that rename detection
>>
On Thursday, December 6, 2018 3:48:32 PM CET Petr Pisar wrote:
> On 2018-12-06, Florian Weimer wrote:
>
> > In a sense, it's the old discussion between explicit rename recording
> > and rename detection. I think it's clear by now that rename detection
> > has won.
> >
> >
>
> Can you give us
On Thu, Dec 06, 2018 at 02:48:32PM +, Petr Pisar wrote:
> On 2018-12-06, Florian Weimer wrote:
> > In a sense, it's the old discussion between explicit rename recording
> > and rename detection. I think it's clear by now that rename detection
> > has won.
> >
> Can you give us some example
On 2018-12-06, Florian Weimer wrote:
> In a sense, it's the old discussion between explicit rename recording
> and rename detection. I think it's clear by now that rename detection
> has won.
>
Can you give us some example of a rename detection that works?
If a packager cherry-picks patches, he
On Thu, Dec 06, 2018 at 01:42:06PM +0100, Florian Weimer wrote:
> > https://github.com/user-cont/source-git
[...]
> > We would love to take development off dist-git (but keep dist-git!)
> > and move it to git repos with real source code which match upstream
> > repositories. In such repo you have
* Neal Gompa:
> You're confusing this with trust. And yes, there's some trust to give
> here, but keeping a (tiny) amount of friction for small patch sets
> that increases as your patch load goes up just further encourages not
> maintaining heavy patch loads.
Heavy patch loads are just a fact of
* Neal Gompa:
> The problem with merged source trees (aka source-git) is that it
> implies forking projects.
But that's true for *any* distribution that wants to integrate things.
I guess you could govern everything by build flags eventually, but
upstreams will rarely be willing to backport
* Tomas Tomecek:
>> * Matthew Miller:
>>
>>
>> Make it cheap to maintain branches. I expect that one what to achieve
>> this would be to build directly out of Git, with synthesized release
>> numbers and changelogs. This way, you can apply a lot of fixes to
>> multiple branches without
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.
https://bazaarreview.com/
___
devel mailing
On Wed, Nov 28, 2018 at 2:53 PM Nicolas Mailhot
wrote:
>
> Le 2018-11-26 12:31, Brian (bex) Exelbierd a écrit :
>
> >
> > I agree that we need a beta vs stable pathway, but I am not sure
> > having a release helps us.
>
> If we want hardware manufacturers to ship Fedora-compatible hardware we
>
Le 2018-11-26 12:31, Brian (bex) Exelbierd a écrit :
I agree that we need a beta vs stable pathway, but I am not sure
having a release helps us.
If we want hardware manufacturers to ship Fedora-compatible hardware we
need to ship them official Fedora starting points. "Just pick any",
spend
On Tue, Nov 20, 2018 at 5:12 PM Fabio Valentini wrote:
>
> On Tue, Nov 20, 2018, 16:43 Brian (bex) Exelbierd >
>> On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann wrote:
>> >
>> > Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500:
>> > > On Thu, 15 Nov 2018 14:38:12 +0100, you wrote:
>> > >
>>
* Dominik Mierzejewski:
> On Thursday, 15 November 2018 at 13:48, Florian Weimer wrote:
>> * Przemek Klosowski:
>>
>> > I wonder if RedHat could be persuaded to modify their process to adopt
>> > a Fedora release instead of forking it, and backport into that
>> > release---let's call it "Fedora
On Tue, Nov 20, 2018 at 01:36:06PM -0500, Neal Gompa wrote:
> On Tue, Nov 20, 2018 at 12:49 PM Daniel P. Berrangé
> wrote:
> >
> > On Tue, Nov 20, 2018 at 12:15:17PM -0500, Neal Gompa wrote:
> > >
> > > The problem with merged source trees (aka source-git) is that it
> > > implies forking
On Thursday, 15 November 2018 at 13:48, Florian Weimer wrote:
> * Przemek Klosowski:
>
> > I wonder if RedHat could be persuaded to modify their process to adopt
> > a Fedora release instead of forking it, and backport into that
> > release---let's call it "Fedora LTS a.k.a. CentOS Release
On Tuesday, 20 November 2018 at 08:46, Kalev Lember wrote:
> On 11/19/2018 10:04 PM, Stephen John Smoogen wrote:
> > Centos also ships a lot of non-Red Hat kernels and modules which
> > meet various itches that people feel (xen, upstream lts, various
> > gluster/ceph/arm32/etc)
>
> I wonder if
On Tue, Nov 20, 2018 at 12:49 PM Daniel P. Berrangé wrote:
>
> On Tue, Nov 20, 2018 at 12:15:17PM -0500, Neal Gompa wrote:
> > On Tue, Nov 20, 2018 at 12:03 PM Michal Novotny wrote:
> > >
> > > On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny wrote:
> > >>
> > >> On Tue, Nov 20, 2018 at 12:43 PM
On Tue, Nov 20, 2018 at 12:15:17PM -0500, Neal Gompa wrote:
> On Tue, Nov 20, 2018 at 12:03 PM Michal Novotny wrote:
> >
> > On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny wrote:
> >>
> >> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek wrote:
> >>>
> >>> > * Matthew Miller:
> >>> >
> >>> >
>
On Tue, Nov 20, 2018 at 12:03 PM Michal Novotny wrote:
>
> On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny wrote:
>>
>> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek wrote:
>>>
>>> > * Matthew Miller:
>>> >
>>> >
>>> > Make it cheap to maintain branches. I expect that one what to achieve
>>> >
On Tue, Nov 20, 2018 at 1:57 PM Michal Novotny wrote:
> On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek
> wrote:
>
>> > * Matthew Miller:
>> >
>> >
>> > Make it cheap to maintain branches. I expect that one what to achieve
>> > this would be to build directly out of Git, with synthesized
On Tue, Nov 20, 2018, 16:43 Brian (bex) Exelbierd On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann
> wrote:
> >
> > Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500:
> > > On Thu, 15 Nov 2018 14:38:12 +0100, you wrote:
> > >
> > > > I understand this argument, but I think more and more
On Thu, Nov 15, 2018 at 6:43 PM Jiri Eischmann wrote:
>
> Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500:
> > On Thu, 15 Nov 2018 14:38:12 +0100, you wrote:
> >
> > > I understand this argument, but I think more and more desktop users
> > > are being trained that updates happen on a
On Tue, Nov 20, 2018 at 12:43 PM Tomas Tomecek wrote:
> > * Matthew Miller:
> >
> >
> > Make it cheap to maintain branches. I expect that one what to achieve
> > this would be to build directly out of Git, with synthesized release
> > numbers and changelogs. This way, you can apply a lot of
On Tue, Nov 20, 2018, 12:42 Tomas Tomecek > * Matthew Miller:
> >
> >
> > Make it cheap to maintain branches. I expect that one what to achieve
> > this would be to build directly out of Git, with synthesized release
> > numbers and changelogs. This way, you can apply a lot of fixes to
> >
> * Matthew Miller:
>
>
> Make it cheap to maintain branches. I expect that one what to achieve
> this would be to build directly out of Git, with synthesized release
> numbers and changelogs. This way, you can apply a lot of fixes to
> multiple branches without encountering mandatory
On 11/19/2018 10:04 PM, Stephen John Smoogen wrote:
Centos also ships a lot of non-Red Hat kernels and modules which
meet various itches that people feel (xen, upstream lts, various
gluster/ceph/arm32/etc)
I wonder if something like this could make sense for Fedora as well, to
ship two kernel
On 2018-11-13 3:36 p.m., Matthew Miller wrote:
> > Hi everyone! Let's talk about something new and exciting. Since its >
first release fifteen years ago, Fedora has had a 13-month lifecycle >
(give or take). That works awesomely for many cases (like, hey, we're >
all here), but not for everyone.
Le lundi 19 novembre 2018 à 11:27 -0800, Japheth Cleaver a écrit :
> On 11/16/2018 3:19 PM, Nicolas Mailhot wrote:
> >
> > Really, if there is one distro component we should backport to el
> > and
> > all release streams, that's rpm + all Fedora macro packages, not the
> > kernel.
>
> Well,
On Sun, 18 Nov 2018 at 17:20, Neal Gompa wrote:
>
> On Sun, Nov 18, 2018 at 5:08 PM Orion Poplawski wrote:
> >
> > On 11/18/18 2:29 PM, Richard W.M. Jones wrote:
> > > I'm not for or against a longer Fedora lifecycle, but I think we need
> > > a stronger statement of what the problem is we're
On 11/16/2018 3:19 PM, Nicolas Mailhot wrote:
Le vendredi 16 novembre 2018 à 13:02 -0800, Japheth Cleaver a écrit :
I'm not sure why punting like this is a good thing. RPM is a
standard,
moving along at what one might expect a core component to do, but to
the
extent that "evolving our
On 11/16/18 5:17 PM, Jason L Tibbitts III wrote:
>> "MM" == Matthew Miller writes:
>
> MM> It's the fundamental contradiction that all operating systems face:
> MM> users complain "too fast and too slow!" at the same time.
>
> Well, then lengthening the Fedora lifecycle does not seem to me
On Sun, 18 Nov 2018 17:19:37 -0500, you wrote:
>But I don't think we should extend the lifecycle on a general basis.
>That's asking for trouble, since it cedes our leadership in the Linux
>platform and destroys our ability to meet our own values.
What leadership would Fedora be ceding by
On Sun, Nov 18, 2018 at 5:30 PM Reindl Harald wrote:
>
> Am 18.11.18 um 23:19 schrieb Neal Gompa:
> > I think it's quite obvious why. No one can really influence what's in
> > CentOS. Red Hat Enterprise Linux itself is developed mostly behind
> > closed doors, after forking a Fedora release.
>
>
On Sun, Nov 18, 2018 at 5:08 PM Orion Poplawski wrote:
>
> On 11/18/18 2:29 PM, Richard W.M. Jones wrote:
> > I'm not for or against a longer Fedora lifecycle, but I think we need
> > a stronger statement of what the problem is we're trying to address.
> >
> > From your email:
> >
> > On Tue,
On 18-11-18 16:29:45, Richard W.M. Jones wrote:
I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.
From your email:
On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
> But there are some good
On 11/18/18 2:29 PM, Richard W.M. Jones wrote:
I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.
From your email:
On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
But there are some good
I'm not for or against a longer Fedora lifecycle, but I think we need
a stronger statement of what the problem is we're trying to address.
From your email:
On Tue, Nov 13, 2018 at 06:36:38PM -0500, Matthew Miller wrote:
> But there are some good cases for a longer lifecycle. For one thing,
>
I'm hoping the Fedora LTS idea will die as quickly as it started.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
Hello,
On Sat, 2018-11-17 at 08:10 +, Leigh Scott wrote:
> > On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller
> > >
> > "Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years"
> >
> > https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18.04-lt...
> >
> > I just don't
On Tue, 13 Nov 2018 18:36:38 -0500, you 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.
In a later message you also bring up the reluctance of Universities to
use Fedora - a bad sign given
On Fri, 16 Nov 2018 17:58:36 +0100, you wrote:
>Gerald Henriksen wrote:
>> I think the problem is that for a consumer / desktop oriented product
>> - which we seem to be talking about given that this appears to be
>> driven in part by the desire of hardware vendors - the RHEL/CentOS
>> release
> On Tue, Nov 13, 2018 at 5:36 PM, Matthew Miller
>
> "Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years"
>
> https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18.04-lt...
>
> I just don't see how we're going to be able to compete with that, not
> unless our Fedora
Le vendredi 16 novembre 2018 à 13:02 -0800, Japheth Cleaver a écrit :
>
> I'm not sure why punting like this is a good thing. RPM is a
> standard,
> moving along at what one might expect a core component to do, but to
> the
> extent that "evolving our packaging" means doing things at odds with
> "MM" == Matthew Miller writes:
MM> It's the fundamental contradiction that all operating systems face:
MM> users complain "too fast and too slow!" at the same time.
Well, then lengthening the Fedora lifecycle does not seem to me to be
the real solution. Instead, I think, it's to
On 11/15/2018 3:54 PM, Jason Tibbitts wrote:
And to add in an additional argument that we didn't have a decade ago:
We're actually trying to evolve our packaging now. EPEL with it's "old
RPM never changes" restriction is bad enough but fortunately limited in
scope. Having years of Fedora
On Fri, Nov 16, 2018 at 12:52 PM Jason L Tibbitts III wrote:
>
> > "IU" == Iñaki Ucar writes:
>
> IU> AFAIK, that wasn't officially supported.
>
> What does "official" actually mean, and what relevance does that have?
> Adrian Bunk didn't maintain 2.6.16 in a way that's much different than
>
> "IU" == Iñaki Ucar writes:
IU> AFAIK, that wasn't officially supported.
What does "official" actually mean, and what relevance does that have?
Adrian Bunk didn't maintain 2.6.16 in a way that's much different than
the current long term support kernels are supported. And even before
that,
Gerald Henriksen wrote:
> I think the problem is that for a consumer / desktop oriented product
> - which we seem to be talking about given that this appears to be
> driven in part by the desire of hardware vendors - the RHEL/CentOS
> release cycle leads to problems for several years worth of
El vie., 16 nov. 2018 17:07, Jason L Tibbitts III
escribió:
> > "IU" == Iñaki Ucar writes:
>
> IU> In this respect (the kernel), it's true that something changed
> IU> compared to a decade ago: there was no LTS support upstream
> IU> then. Now, there is.
>
> That is not really true. 2.6.16
> "IU" == Iñaki Ucar writes:
IU> In this respect (the kernel), it's true that something changed
IU> compared to a decade ago: there was no LTS support upstream
IU> then. Now, there is.
That is not really true. 2.6.16 (the first kernel that I recall anyone
calling some equivalent of "LTS")
On Thu, Nov 15, 2018 at 05:54:59PM -0600, Jason Tibbitts wrote:
> MM> Let's talk about something new and exciting.
[...]
> I know it's been a while. Maybe it's been long enough that a
> significant number of the developers here don't remember it. I am
> pretty sure you were around, though, so I
mcatanz...@gnome.org píše v Čt 15. 11. 2018 v 19:00 -0600:
> 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
Le vendredi 16 novembre 2018 à 11:37 +0100, Nicolas Mailhot a écrit :
> iable, and checking those in the installer)
>
> * that effectively means:
> * the only supported state is the current upgrade tip,
> * you have an N-era window where upgrades to the current tip are
> supported baring
Le jeudi 15 novembre 2018 à 16:22 -0500, Matthew Miller a écrit :
> On Thu, Nov 15, 2018 at 10:45:26AM -0500, Neal Gompa wrote:
> > He's proposing Debian-style source code forking into git repos and
> > having the build description merged into that source tree. It's
> > usually referred to as
Hi,
Realistically, the only thing that fits the interests of Fedora
packagers, the cadence and interdependencies of the projects Fedora
ships, is a form of rolling release.
We are not a Microsoft that can tell its software groups “from now on
you release with this cadence and support for this
On Fri, 16 Nov 2018 at 01:54, Jason Tibbitts wrote:
>
> My recollection is that meaningful discussion usually stopped at the
> kernel issue. At one point we had some basic agreement that people who
> cared were welcome to push to old branches of things to keep them going,
> but that was back
Dne 16. 11. 18 v 10:38 Vít Ondruch napsal(a):
> Dne 16. 11. 18 v 0:54 Jason Tibbitts napsal(a):
>>> "MM" == Matthew Miller writes:
>> MM> How would we balance this with getting people new stuff fast as
>> MM> well?
>>
>> Wait, what? Certainly you're not suggesting trying to do an extended
Dne 16. 11. 18 v 0:54 Jason Tibbitts napsal(a):
>> "MM" == Matthew Miller writes:
> MM> Let's talk about something new and exciting.
>
> I assume that you mean "very much not new and about as exciting as the
> fifteenth viewing of an episode of the Joy of Painting".
>
> I know it's been a
Dne 14. 11. 18 v 21:11 Ben Rosser napsal(a):
> Instead of working on a new "Fedora LTS" for this usage case,
> would time be better spent improving EPEL and CentOS for the
> desktop/laptop use case?
+1
Instead of building bigger kernel team, rel-engs, security team... we can focus
on CentOS
On 11/15/18 10:42 AM, Jiri Eischmann wrote:
Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500:
On Thu, 15 Nov 2018 14:38:12 +0100, you wrote:
I understand this argument, but I think more and more desktop users
are being trained that updates happen on a schedule they didn't
choose
and are
Well, I have read tons of things, and only one thing bump in my head:
"Ubuntu LTS"
I mean, it's a great idea, and a lot of people have asked about it in
forums, reddit, twitter, fedoraforums and the list goes on. I thing that if
someone can make it happens is the awesome Fedora Developers team,
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
On Fri, 16 Nov 2018 00:18:35 +0100, you wrote:
>Also, I don't really understand where this need for a "fedora LTS"
>comes from. I've always thought of RHEL / CentOS as filling that role.
>I agree that there could probably be more collaboration between these
>three projects (especially CentOS and
> "MM" == Matthew Miller writes:
MM> Let's talk about something new and exciting.
I assume that you mean "very much not new and about as exciting as the
fifteenth viewing of an episode of the Joy of Painting".
I know it's been a while. Maybe it's been long enough that a
significant number
On Thu, Nov 15, 2018 at 11:10 PM Matthew Miller
wrote:
>
> On Thu, Nov 15, 2018 at 06:55:45PM +0100, Jiri Eischmann wrote:
> > That's my thinking, too. Having releases supported for 7 months is not
> > really worth it, let's rather switch to a stable rolling release for
> > those who want the
On Thu, Nov 15, 2018 at 04:19:29PM -0500, Matthew Miller wrote:
> I think the very, very high fast rate I'm seeing in the mirror stats (see
Too excited! "Very high fast upgrade rate." :)
--
Matthew Miller
Fedora Project Leader
___
devel mailing list
On Thu, Nov 15, 2018 at 10:45:26AM -0500, Neal Gompa wrote:
> He's proposing Debian-style source code forking into git repos and
> having the build description merged into that source tree. It's
> usually referred to as merged-source builds.
>
> Basically, we no longer use pristine sources as
On Thu, Nov 15, 2018 at 06:55:45PM +0100, Jiri Eischmann wrote:
> That's my thinking, too. Having releases supported for 7 months is not
> really worth it, let's rather switch to a stable rolling release for
> those who want the latest and greatest. LTS will be there for the rest.
> And the
On Thu, Nov 15, 2018 at 10:22:16AM -0700, Greg Bailey wrote:
> beta appears to have multiple versions of php, perl, nodejs, and
> other packages. I've not yet used Fedora modules nor RHEL 8 beta,
> but I bring this up to see if that model meets the needs for Fedora
> users who are looking for
On Thu, Nov 15, 2018 at 12:30 PM Colin Walters wrote:
>
> The doc does assume that the reader has some familiarity with
> the rpmdistro-gitoverlay project, yes. I'll look at tweaking that
> doc to mention looking at the toplevel README.
I looked at the top-level README but I gotta admit I was
On 11/15/2018 8:19 AM, John Florian wrote:
I totally agree, but we are talking about radical changes here and I
think we should keep all options on the table. If some particular
path forward is overwhelmingly desirable, that is the time to decide
if the push is worth it, not earlier IMHO. If
* Ken Dreyer:
> On Thu, Nov 15, 2018 at 5:02 AM Florian Weimer wrote:
>> Make it cheap to maintain branches. I expect that one what to achieve
>> this would be to build directly out of Git, with synthesized release
>> numbers and changelogs. This way, you can apply a lot of fixes to
>>
On Thu, Nov 15, 2018, at 12:38 PM, Ken Dreyer wrote:
> I am sorry to be such a noob, but I read the words on that page, they
> sound exciting, but I am lost. What does "mirror git repositories like
> rpmdistro-gitoverlay does" mean? I could use a really clear
> step-by-step walkthrough of how I
Neal Gompa píše v St 14. 11. 2018 v 07:54 -0500:
> 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
Gerald Henriksen píše v Čt 15. 11. 2018 v 10:22 -0500:
> On Thu, 15 Nov 2018 14:38:12 +0100, you wrote:
>
> > I understand this argument, but I think more and more desktop users
> > are being trained that updates happen on a schedule they didn't
> > choose
> > and are hard to avoid. This is how
On Thu, Nov 15, 2018 at 9:40 AM Colin Walters wrote:
> On Thu, Nov 15, 2018, at 10:57 AM, Matthew Miller wrote:
> > I think to do this we would need to have our own, controlled local git
> > mirror.
>
> This is step 2 in
>
On 11/13/2018 04:36 PM, Matthew Miller wrote:
Hi everyone! Let's talk about something new and exciting. Since its
first release fifteen years ago, Fedora has had a 13-month lifecycle
(give or take). That works awesomely for many cases (like, hey, we're
all here), but not for everyone. Let's talk
> As can be clearly seen from the breadth of the update streams, once F+2
> is released, F+1 still gets a moderate number of updates, but F only
> gets major bugs fixed, at best. Some maintainers care more, some less,
> but it's pretty obvious that our "oldstable" release is not where the
>
On Thu, Nov 15, 2018, at 10:57 AM, Matthew Miller wrote:
> On Thu, Nov 15, 2018 at 07:57:54AM -0700, Ken Dreyer wrote:
> > One of the problems I've encountered with this approach is that the
> > upstream Git repo links to (a lot of) submodules. If you're lucky
> > those submodules point at Git
On 11/14/18 7:54 PM, mcatanz...@gnome.org wrote:
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
On Thu, Nov 15, 2018 at 07:57:54AM -0700, Ken Dreyer wrote:
> One of the problems I've encountered with this approach is that the
> upstream Git repo links to (a lot of) submodules. If you're lucky
> those submodules point at Git repos and sha1s that don't disappear
> over time. It doesn't really
Matthew Miller píše v Út 13. 11. 2018 v 18:36 -0500:
> Hi everyone! Let's talk about something new and exciting. Since its
> first release fifteen years ago, Fedora has had a 13-month lifecycle
> (give or take). That works awesomely for many cases (like, hey, we're
> all here), but not for
On Thu, Nov 15, 2018 at 10:37 AM Stephen John Smoogen wrote:
>
> On Thu, 15 Nov 2018 at 07:48, Florian Weimer wrote:
> >
> > * Matthew Miller:
> >
> > > 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
On Thu, 15 Nov 2018 14:38:12 +0100, you wrote:
>I understand this argument, but I think more and more desktop users
>are being trained that updates happen on a schedule they didn't choose
>and are hard to avoid. This is how most mobile operating systems
>function.
iOS prompts you for the
On Wed, 14 Nov 2018 14:04:23 -0500, you 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 and then they
On Thu, Nov 15, 2018 at 5:02 AM Florian Weimer wrote:
> Make it cheap to maintain branches. I expect that one what to achieve
> this would be to build directly out of Git, with synthesized release
> numbers and changelogs. This way, you can apply a lot of fixes to
> multiple branches without
On Thu, 15 Nov 2018 01:33:36 +, you wrote:
>The major OS competitor has moved to a 6 month release cadence, so that
>needs to be taken into account.
And Microsoft is experiencing troubles, and a lot of push back that
they are so far ignoring. Not all of the troubles are necessarily
from the
On Thu, 15 Nov 2018 at 07:48, Florian Weimer wrote:
>
> * Matthew Miller:
>
> > 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
On Wed, Nov 14, 2018 at 6:47 PM 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 it
On Thu, Nov 15, 2018 at 12:00 AM Kevin Fenzi wrote:
>
> 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
On Thu, Nov 15, 2018 at 7:24 AM Neal Gompa wrote:
>
> It's a new unknown feature of rpkg (and thus fedpkg) to let you
> configure `fedpkg build` to build packages for multiple koji targets
> at once from a single branch. If you choose to have a single "master"
> branch instead of a branch for
On Wed, 14 Nov 2018 at 11:34, wrote:
>
> 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
* Przemek Klosowski:
> I wonder if RedHat could be persuaded to modify their process to adopt
> a Fedora release instead of forking it, and backport into that
> release---let's call it "Fedora LTS a.k.a. CentOS Release Candidate"
> (FLAC-RC :). It would require perhaps more effort on the part of
On Thu, Nov 15, 2018 at 5:44 AM Pierre-Yves Chibon wrote:
>
> On Wed, Nov 14, 2018 at 11:36:44AM -0500, Owen Taylor wrote:
> > 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
* Brendan Conoboy:
> Does Fedora remaining on the same kernel for a longer period of time
> open up useful opportunities? EG, if the same kernel were the default
> for a longer period of time would that help make it suitable for
> factory installs?
It would certainly help with factory installs
1 - 100 of 169 matches
Mail list logo
