subject:"Fedora Lifecycles\: imagine longer\-term possibilities"

* 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 system rename detection.  Nothing works perfectly.  But any
system only needs to beet the accuracy of the information that
developers record manually, and that is a more tractable problem.

> If a packager cherry-picks patches, he looses upstream's commit IDs. If
> an upstream uses non-descriptive commit messages (e.g. five commits with
> the same "A bug fix" subject), commit messages are not uniq. If the
> packager needs to ammend patches (the commit bodies) to resolve conflicts
> (i.e. porting back the fixes by rebasing the patches), the code changes
> are not uniq. If an upstream releases a new version after a year, the
> packager won't probably remember all the cherry-picked fixes.
>
> How can a packager identify which commits originates from the upstream
> and which are uniq to Fedora and must be carried across rebases to
> a new release?

Without tooling?  The same way as today.  Look at the commit and see if
it is upstream, using commit subject, author email and date for fuzzy
matching if necessary, and commit IDs if listed in the commit message.

Even that's an improvement over what people record in patch files today.
Without -x, git cherry-pick will not immediately mangle the subject,
email and date.  With -x, you have the commit ID (but which may not be
reliable if it comes from the wrong branch).

Tooling can do better and look at the actual changes to match them with
seemingly unrelated upstream changes.

> A tempting answer could be use merge-commits extensively. However, would
> that really help? I must admit I'm not fond of merge-commits and I don't
> have much experience with them.

You could merge in the upstream history with the remaining
downstream-specific patches on top, yes.  But it's not necessary to do
it this way.

> If I imagine a dist-git tree full of intermingled upstream and Fedora
> commits, I don't know how I as a packager would package a new upstream
> release. Should I just blindy believe in "git merge"? I have a few bad
> experiences with git losing diff chunks on the way. How could I keep
> the packaging accountable and verifiable?

At the minimum: git merge plus diff against the upstream, to see what
downstream changes remain.  And then perhaps add new commits to revert
spurious differences from upstream.  Or use the “merge the rebased tree”
approach I mentioned.

The interesting question is whether we'd preserve that history
downstream, when rebasing.  Historically, it's a full rebase to Fedora
for almost all packages, and it's up to package maintainers to
re-instantiate all the downstream customization.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-12-06 Thread Petr Pisar

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
>> > has won.
>> >
>> Can you give us some example of a rename detection that works?
>> 
>> If a packager cherry-picks patches, he looses upstream's commit IDs.
>
> You should essentially always use 'git cherry-pick -x $HASH' this causes
> the commit message to have a line appended:
>
> (cherry picked from commit d6b27d3e4c40946efa79e91d134616b41b1666c4)
>
I did not know about the -x option. Thanks. I used to ammend the
original commit ID manually.

However, this is essentially the "explicit rename recording" that
Florian claims is not needed anymore.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-12-06 Thread Kamil Dudka

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 some example of a rename detection that works?
> 
> If a packager cherry-picks patches, he looses upstream's commit IDs. If
> an upstream uses non-descriptive commit messages (e.g. five commits with
> the same "A bug fix" subject), commit messages are not uniq. If the
> packager needs to ammend patches (the commit bodies) to resolve conflicts
> (i.e. porting back the fixes by rebasing the patches), the code changes
> are not uniq. If an upstream releases a new version after a year, the
> packager won't probably remember all the cherry-picked fixes.
> 
> How can a packager identify which commits originates from the upstream
> and which are uniq to Fedora and must be carried across rebases to
> a new release?
> 
> A tempting answer could be use merge-commits extensively. However, would
> that really help? I must admit I'm not fond of merge-commits and I don't
> have much experience with them.
> 
> If I imagine a dist-git tree full of intermingled upstream and Fedora
> commits, I don't know how I as a packager would package a new upstream
> release. Should I just blindy believe in "git merge"? I have a few bad
> experiences with git losing diff chunks on the way. How could I keep
> the packaging accountable and verifiable?
> 
> -- Petr

It is not covered by any policy or supported tooling but, just to help
myself with future maintenance, I always append "Upstream-commit: "
to the commit message whenever I take a patch (commit) from the upstream
git repository.

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-12-06 Thread Daniel P . Berrangé

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 of a rename detection that works?
> 
> If a packager cherry-picks patches, he looses upstream's commit IDs.

You should essentially always use 'git cherry-pick -x $HASH' this causes
the commit message to have a line appended:

(cherry picked from commit d6b27d3e4c40946efa79e91d134616b41b1666c4)

If you cherry-pick from a commit that was in turn a cherry-pick, you'll
get a long series of annotations so you can see the chain of picks.

IMHO this is one of those annoying git cases where the commonly desired
behaviour is not in fact the 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-12-06 Thread 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?

If a packager cherry-picks patches, he looses upstream's commit IDs. If
an upstream uses non-descriptive commit messages (e.g. five commits with
the same "A bug fix" subject), commit messages are not uniq. If the
packager needs to ammend patches (the commit bodies) to resolve conflicts
(i.e. porting back the fixes by rebasing the patches), the code changes
are not uniq. If an upstream releases a new version after a year, the
packager won't probably remember all the cherry-picked fixes.

How can a packager identify which commits originates from the upstream
and which are uniq to Fedora and must be carried across rebases to
a new release?

A tempting answer could be use merge-commits extensively. However, would
that really help? I must admit I'm not fond of merge-commits and I don't
have much experience with them.

If I imagine a dist-git tree full of intermingled upstream and Fedora
commits, I don't know how I as a packager would package a new upstream
release. Should I just blindy believe in "git merge"? I have a few bad
experiences with git losing diff chunks on the way. How could I keep
the packaging accountable and verifiable?

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-12-06 Thread Matthew Miller

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 branches which track respective
[...]
> That sounds very nice.
> 
> Is there a place to discuss this approach?

I would suggest *this list*, although perhaps if it's something other than
lifecycle a new thread (so it doesn't get lost).


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

* 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 life.  Currently, Fedora 28 glibc
is at ~90 upstream patches.  Fedora 27 glibc was at ~190 upstream
patches at end of life (depending whether you count the last update that
didn't make it before EOL).  The few Fedora-specific patches come on top
of that.

For comparison, Red Hat Enterprise Linux 7 glibc is currently at around
880 patches.  Most of them a straight upstream backports, as in Fedora.

The overhead from managing those patches used to be substantial, but we
have mostly automated it, in a different way from the kernel and Red
Hat's middleware products, because Fedora would not allow us to use
established downstream practices.  Unfortunately, our automation is
still somewhat brittle and incomplete.  It still takes around seven
minutes to prepare the sources for a totally trivial upstream backport
of a single patch, something that should ideally be a single “git
cherry-pick” command (which would also leave less room for mistakes).
Of course, in seven minutes, you can fill in a lot of patch
documentation that allows you to figure out later what you did and why.

I'm worried that this kind of pointless work makes it hard to attract
talent.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

* 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 those to older branches
(if they even have release branches as such).

> It's an easy trap to start having vendor trees and maintain your own
> functionality independent from upstream.

And how does the current dist-git prevent that?  I know packages which
have managed to fall into the fork trap even with dist-git.

> Fundamentally, I don't want having patches to be too easy, because
> then people _will_ do that. Fedora should strive to remain close to
> upstream projects and interact with them to make things better[1].

To be honest, that's an awful attitude.

Do you want me to spend time on packaging work instead of glibc
maintenance?  Do you really think that's a good use of my time?

Do you really think an unavoidable conflict each time you merge parallel
development into a source RPM provides value?

> And the thing is, it's not like I'm unfamiliar with merged source
> models. I've worked in distributions that operated that way, and the
> consequence is almost always that things are patched and changed
> without ever interacting with upstream. Of course, that's their choice
> to do so, but most distributions do not have "upstream-first" as a
> specific goal.

We do that in Fedora, too.

A recent example is the switch to the C.UTF-8 locale, which is not
upstream *at all*.  It was pointed out at the time, and the issue was
completely ignored.

> In addition, it may seem like it makes things easier (and maybe
> faster), but it actually makes things much harder and slower for
> everyone else. Merged source trees make it so that it's stupid easy to
> have light forks of everything, which means people will just patch and
> change things without consequence. That makes it much harder to
> identify changes for rebasing to newer versions, what's safe to drop,
> and so on.

That's just a matter of tooling.  A lot of information can be recovered
from Git history, and it's going to be easier to do this in a single
repository than with copied patches, without tooling that enforces that
the patches actually contain what they say.

The point is to keep that history around.  With the current model, the
information might theoretically be available somewhere, but with the
split between Fedora, branches, wildly differing patch management
practices, in addition to all the upstream differences we encounter,
it's extremely difficult to recover.

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.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

* 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 encountering mandatory conflicts.
>
> We are aiming for something similar what you just described. I created this 
> wiki page to describe the work briefly:
>
> https://fedoraproject.org/wiki/CI/source-git
>
> The actualy work is happening here now:
>
> 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 branches which track respective
> Fedora versions -- you can easily cherry pick fixes. We would validate
> every pull request in such repo and stuff would get merged only when
> it passes testing. Right now we are trying to write minimal code to
> make such thing work, evaluate it and present at devconf.cz to get
> some more feedback.

That sounds very nice.

Is there a place to discuss this approach?

I assume you still generate a flattened source tarball and inject that
into the RPM spec file?

I do wonder if it would be preferably to write the source RPM directly
(from a plain working tree, without history), with non-flattened paths,
and archive that in Koji for reproducibility.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-30 Thread adda ella

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 list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-28 Thread Brian (bex) Exelbierd

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
> need to ship them official Fedora starting points. "Just pick any",
> spend months QAing, and then get told you didn't choose the right
> starting point won't fly with them.

I don't think that formal releases and "pick any random thing you
like" represents the full range of options here.  We have a "stable
stream and we have a beta stream" is neither of those but does provide
clarity.

regards,

bex

>
> --
> Nicolas Mailhot



-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-28 Thread Nicolas Mailhot


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 months QAing, and then get told you didn't choose the right 
starting point won't fly with them.


--
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-26 Thread Brian (bex) Exelbierd

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:
>> > >
>> > > > 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 yearly updates, and it can be avoided if you
>> > > really want.
>> > >
>> > > macOS requires you to specifically choose the yearly update, though
>> > > they may have changed with Mojave.
>> > >
>> > > Not sure about Android, but the fact that Google has had to twist
>> > > things into a knot to try and get updates out to users indicates that
>> > > upgrades to Android aren't being pushed out for the most part.
>> > >
>> > > Windows is the only one forcing upgrades, and it is perhaps one of
>> > > the
>> > > reasons that hardware vendors are showing more interest in Linux as
>> > > people are now more willing to consider anything other than Windows.
>> > >
>> > > Really, the only place where forced upgrades are happening, are
>> > > accepted, and seem to actually work are on the application side and
>> > > that is because, demonstrated by the web browsers, frequent updates
>> > > can be done unobtrusively and reliably.
>> >
>> > And with the named examples are you gonna get any support and updates
>> > if you decide to hold off an upgrade to a newer OS? I doubt.
>> > I can certainly hold off upgrade to Android 9 on my phone, but that
>> > doesn't mean I'm gonna get any further updates for Android 8 from the
>> > phone vendor.
>> > There is a huuuge difference between "not forcing upgrades" and
>> > "providing supported and secure way to stay on the current release".
>>
>> I think this tied up with one of the major problems we are trying to
>> solve with Fedora Modularity, the "Too Fast, Too Slow" problem.
>
>
> I think identifying which components move too slow or too fast would be a 
> good start - even if those lists might depend on the specific user or 
> use-case.

I think this is a great way to differentiate various
spins/labs/editions, however the OS as a whole needs to be able to
allow as much as possible to flex as much as possible.  I think that
trying to define a core beyond "boots the machine" quickly leads to an
endless rabbit hole.

>> I am not sure it is bad for Fedora to only have a single supported
>> "release."  If you refuse an upgrade, you're on your own.  If you
>> refuse it because you're going on a trip, have a presentation, etc.
>> and plan to do it later, you generally don't care.  If you do it
>> because you don't want your system to change, I am not sure Fedora
>> should be your distribution of choice (I'll introduce you to my
>> friends CentOS and RHEL).
>>
>> If we did a "stable rolling release base" that, described simply and
>> incompletely, had a beta and stable option where you knew your
>> hardware would work and your apps would run I think most users,
>> desktop and server, would be happy.
>
>
> What about aliasing fedora-N to "rolling-beta", and fedora-N-1 to 
> "rolling-stable" (similar to what Debian does)? Every 6 months or so, 
> rolling-stable users would get an upgrade to a fedora release that's been 
> well-used and -tested for about 6 months. (Which I guess is what some people 
> already do manually.)

I agree that we need a beta vs stable pathway, but I am not sure
having a release helps us.  We can do version numbers if we need them
for marketing, but I think some of what appeals about rolling releases
is that upgrades are a non-event.  We've basically accomplished that
with Fedora today, except that we still make a big deal out of hte
upgrade and hte new version number.  Let's push it further to
non-event status and instead talk about updates as new features and
benefits, not a new version.  (this is poorly worded - I am in a
rush).

regards,

bex

>
> We only need to make sure that the upgrade path always works for, say, the 
> last 4 fedora releases (or however many we need to support upgrading from). 
> Upgrades from N-2 to N are already supposed to work (I think), so this 
> shouldn't be too hard.
>
> (Also, silverblue would make this really easy, by "just" automatically 
> switching to the new N-1 branch every 6 months, when N-2 hits EOL).
>
> That way, the number of supported fedora releases stays the same, and only 
> the upgrade path needs to be reliable for longer.
>
> Fabio
>
>> We use the "beta" to find
>> hardware regressions and to signal hardware we are dropping support
>> for or adding new support for, and we use stable for people who want
>> to get things done.  Layer on Modules. containers and Flatpaks and we
>> have the apps moving on their own speed on this

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-23 Thread Florian Weimer

* 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 LTS a.k.a. CentOS Release Candidate"
>> > (FLAC-RC :). It would require perhaps more effort on the part of
>> > RedHat to avoid breakage in the middle of their development cycle, but
>> > that's probably a good CI practice anyway.
>> 
>> I'm not sure if the substantial changes in minor releases of Red Hat
>> Enterprise Linux would be acceptable to device vendors.  Red Hat
>> Enterprise Linux is a commercially supported distribution, but includes
>> substantially more changes than typical LTS releases.
>
> What's "typical LTS", then?

What Debian does for stable releases, and what Red Hat Enterprise Linux
is like on the EUS branches (which are not available through CentOS).
This mostly means: critical and import fix backports only.  I believe
Ubuntu is similar for their longer-lived releases.

From a device vendor perspective, this is important because it keeps
their maintenance costs down because it's less likely they have to
adjust their customizations very much.  If the graphics stack rebases
once every year, that's a much greater risk and requires more resources.

Of course, every vendor wants an initial rebase, to get support for
their hardware and the value-add software they have written (which may
well include a customer kernel or at least kernel modules).  And there
the problems begin.

I'm not saying that Fedora should do anything here.  Quite the contrary,
I think what device vendors want is not very useful to users, unless all
what they need is upstream already.  But then we should be able to keep
updating Fedora without causing problems for these devices, shoudln't
we?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-21 Thread Daniel P . Berrangé

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 projects. It's an easy trap to start having vendor
> > > trees and maintain your own functionality independent from upstream.
> > > Fundamentally, I don't want having patches to be too easy, because
> > > then people _will_ do that. Fedora should strive to remain close to
> > > upstream projects and interact with them to make things better[1].
> > >
> > > And the thing is, it's not like I'm unfamiliar with merged source
> > > models. I've worked in distributions that operated that way, and the
> > > consequence is almost always that things are patched and changed
> > > without ever interacting with upstream. Of course, that's their choice
> > > to do so, but most distributions do not have "upstream-first" as a
> > > specific goal.
> >
> > IMHO this is an overly negative view. It is making a presumption
> > that package maintainers are in general bad at what they do and
> > must be made to jump through hoops to "force" them to do the
> > right thing, no matter what the cost to good maintainers.
> >
> 
> This is a fairly realistic view, because I assume packagers are
> inherently lazy when it comes to maintenance. That is, they'll take
> the easiest path possible. And that's perfectly rational.

That's an argument for merged source trees, as it makes maint
easier allowing maintainers to get more work done in less time.

> 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.

Well we just fundamentally disagree - heavy patch loads are not an
inherantly bad thing that needs discouraging. They're only bad if
they are full of non-upstreamed stuff. If they're pulling bug fixes
into Fedora to improve our quality they are a very good thing.

> > IOW, when patches are a burden, the maintainers are less likely
> > to fix bugs present in Fedora, even if the fix is available
> > upstream. This is counter to what our users want/expect.
> >
> 
> You're assuming that packages have stupid high patch loads like
> libvirt and qemu do. Most don't. And really, the fact you guys just
> backport a bunch instead of just bumping to new versions is something
> I've never really understood.

libvirt / qemu really don't have a stupid high patch load in Fedora
because Fedora's 6 month cycle means they're never very far behind
upstream. Most of the patches to QEMU tend to be CVE backports.

Rebasing to new versions inside the stable releases is not a
straightforward thing. There is always a risk of regression
when doing that and users get very upset of a previously working
guest OS stops booting due to rebasing in middle of a stable
release.  We have rebased in the past but not any more because
not rebasing leads to a more stable offering on balance.

> > > I have not yet seen a practical example of merged source trees
> > > improving the quality of package maintenance.
> >
> > I'll have to disagree on this. I've found merged source trees to make
> > it significantly quicker and more reliable for me to get fixes from
> > upstream pulled back into Fedora packages.
> >
> 
> Is that because upstream is too slow to release fixes, or is that
> because you don't like bumping to new versions?

Upstream QEMU releases once every 4 months and libvirt monthly. Even
if we did change our minds & decide to rebase, it is still too long
to wait for pulling in security fixes and other critical functional
fixes.

> Merged source trees make it much easier to not update the software.
> But split source trees (like our current model) encourage fixes to be
> pushed upstream and bend workflows towards updating to newer versions
> because that's easier.

I will always prefer to rebase to newer versions if I think it is
viable without too high a risk of regressions. Even if rebasing
frequently there's still a need to maintain patches and anything
that makes that easier is a win. Use of merged source trees for
maint doesn't have any bearing on the willingness to take rebases
or leave patches downstream-only.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Dominik 'Rathann' 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 LTS a.k.a. CentOS Release Candidate"
> > (FLAC-RC :). It would require perhaps more effort on the part of
> > RedHat to avoid breakage in the middle of their development cycle, but
> > that's probably a good CI practice anyway.
> 
> I'm not sure if the substantial changes in minor releases of Red Hat
> Enterprise Linux would be acceptable to device vendors.  Red Hat
> Enterprise Linux is a commercially supported distribution, but includes
> substantially more changes than typical LTS releases.

What's "typical LTS", then? If you want fewer changes then you're
looking at backporting security fixes only and that becomes a very
tedious task as time passes. And you want to talk Fedora community into
doing this? Good luck. I did such backports for a handful of EPEL
packages and it was a chore. I'd have to be paid a heapload of money to
work on such things on a daily basis.

I've seen these discussions repeat on fedora-devel over the years.
I don't expect it to be any different this time. Fedora LTS is
RHEL/CentOS, period. A rolling release would be nice to have, but
improving Rawhide would meet that objective just as well.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Dominik 'Rathann' Mierzejewski

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 something like this could make sense for Fedora as well, to
> ship two kernel streams. "kernel" that has latest kernel, and
> "kernel-lts" that has the LTS kernel that was latest when this Fedora
> version was first released. "kernel" would get continuously rebased to
> latest version, and "kernel-lts" would just stay on the same version the
> whole life cycle.
> 
> If some classes of users (hardware vendors) prefer LTS kernel, and some
> classes of users (people installing their computers themselves and
> wanting latest hardware support) prefer latest kernel, we should be able
> to make both happy.

Who's going to maintain kernel-lts? Having two kernel packages means
twice the testing. How are you suggesting QA and Release Engineering
handle that without additional manpower?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Neal Gompa

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 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 fixes to
> > >>> > multiple branches without encountering mandatory conflicts.
> > >>>
> > >>> We are aiming for something similar what you just described. I created 
> > >>> this wiki page to describe the work briefly:
> > >>>
> > >>> https://fedoraproject.org/wiki/CI/source-git
> > >>>
> > >>> The actualy work is happening here now:
> > >>>
> > >>> 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 branches which track respective 
> > >>> Fedora versions -- you can easily cherry pick fixes. We would validate 
> > >>> every pull request in such repo and stuff would get merged only when it 
> > >>> passes testing. Right now we are trying to write minimal code to make 
> > >>> such thing work, evaluate it and present at devconf.cz to get some more 
> > >>> feedback.
> > >>>
> > >>> Hopefully we would utilize clime's work to help with changelogs and 
> > >>> release numbers: https://pagure.io/rpkg-util/pull-request/15
> > >>
> > >>
> > >> So that would be cool if my work is actually used. I recommend looking 
> > >> at https://pagure.io/rpkg-util/blob/master/f/macros specifically if you 
> > >> could use that.
> > >>
> > >> I planned to open a PR for python-rpkg do enable this functionality in 
> > >> Fedora but I am being delayed by work on rpkg-3.0, which is yet another 
> > >> *pkg client.
> > >>
> > >> Anyway, if there is some interest in making this available in Fedora 
> > >> soon, I can happily do it first. Just kick (contact) me.
> > >> To be clear, the macros can only do the second point from "What and 
> > >> why?" at https://github.com/user-cont/source-git.
> > >
> > >
> > > The README was changed meawhile so the second point from here: 
> > > https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md
> > >
> >
> > The problem with merged source trees (aka source-git) is that it
> > implies forking projects. It's an easy trap to start having vendor
> > trees and maintain your own functionality independent from upstream.
> > Fundamentally, I don't want having patches to be too easy, because
> > then people _will_ do that. Fedora should strive to remain close to
> > upstream projects and interact with them to make things better[1].
> >
> > And the thing is, it's not like I'm unfamiliar with merged source
> > models. I've worked in distributions that operated that way, and the
> > consequence is almost always that things are patched and changed
> > without ever interacting with upstream. Of course, that's their choice
> > to do so, but most distributions do not have "upstream-first" as a
> > specific goal.
>
> IMHO this is an overly negative view. It is making a presumption
> that package maintainers are in general bad at what they do and
> must be made to jump through hoops to "force" them to do the
> right thing, no matter what the cost to good maintainers.
>

This is a fairly realistic view, because I assume packagers are
inherently lazy when it comes to maintenance. That is, they'll take
the easiest path possible. And that's perfectly rational.

> I think we should design our systems around a positive viewpoint,
> where package maintainers are in general good at what they do
> and make life as easy as possible for those people.
>

If we designed our systems around "positive viewpoints", then email
based code contribution would have completely died out. We wouldn't
have aggravating systems like Gerrit. We wouldn't really look at CI
much, either.

All of those things are around the "negative" or "pessimistic" viewpoint.

With email based contribution, it's designed around forcing people to
sift through mail list archives to figure out what's going on, and
forcing other people to review changes on a patch by patch basis,
rather than as a whole series. Gerrit is a step up from that, but
still imposes pain on both sides specifically because it assumes that
individual patches are bad. These models are all about inflicting pain.

CI systems are designed around the fact that most people do not test
or validate their code changes to make sure they work. Or if they do,
they don't quite hit all the cases. And CI deals with that.

You're confusing this with trust. And yes,

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Daniel P . Berrangé

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:
> >>> >
> >>> >
> >>> > 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 conflicts.
> >>>
> >>> We are aiming for something similar what you just described. I created 
> >>> this wiki page to describe the work briefly:
> >>>
> >>> https://fedoraproject.org/wiki/CI/source-git
> >>>
> >>> The actualy work is happening here now:
> >>>
> >>> 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 branches which track respective 
> >>> Fedora versions -- you can easily cherry pick fixes. We would validate 
> >>> every pull request in such repo and stuff would get merged only when it 
> >>> passes testing. Right now we are trying to write minimal code to make 
> >>> such thing work, evaluate it and present at devconf.cz to get some more 
> >>> feedback.
> >>>
> >>> Hopefully we would utilize clime's work to help with changelogs and 
> >>> release numbers: https://pagure.io/rpkg-util/pull-request/15
> >>
> >>
> >> So that would be cool if my work is actually used. I recommend looking at 
> >> https://pagure.io/rpkg-util/blob/master/f/macros specifically if you could 
> >> use that.
> >>
> >> I planned to open a PR for python-rpkg do enable this functionality in 
> >> Fedora but I am being delayed by work on rpkg-3.0, which is yet another 
> >> *pkg client.
> >>
> >> Anyway, if there is some interest in making this available in Fedora soon, 
> >> I can happily do it first. Just kick (contact) me.
> >> To be clear, the macros can only do the second point from "What and why?" 
> >> at https://github.com/user-cont/source-git.
> >
> >
> > The README was changed meawhile so the second point from here: 
> > https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md
> >
> 
> The problem with merged source trees (aka source-git) is that it
> implies forking projects. It's an easy trap to start having vendor
> trees and maintain your own functionality independent from upstream.
> Fundamentally, I don't want having patches to be too easy, because
> then people _will_ do that. Fedora should strive to remain close to
> upstream projects and interact with them to make things better[1].
> 
> And the thing is, it's not like I'm unfamiliar with merged source
> models. I've worked in distributions that operated that way, and the
> consequence is almost always that things are patched and changed
> without ever interacting with upstream. Of course, that's their choice
> to do so, but most distributions do not have "upstream-first" as a
> specific goal.

IMHO this is an overly negative view. It is making a presumption
that package maintainers are in general bad at what they do and
must be made to jump through hoops to "force" them to do the
right thing, no matter what the cost to good maintainers.

I think we should design our systems around a positive viewpoint,
where package maintainers are in general good at what they do
and make life as easy as possible for those people.

No matter what we do there will always be maintainers who don't
do a good job at sending stuff back upstream. We see that today
in places but they are a minority. Most people learn pretty quickly
that updating downstream-only patches to work with new versions
is painfull and so it is in their own interests to get stuff
upstream.

Even today though, we could  & should do more to identify where
we have problems. ie something that looks at patches applied in
Fedora, and reports on how long they have existed for, and across
how many version rebases they've existed. This could show places
where extra help / push is needed to get stuff back upstream.

> In addition, it may seem like it makes things easier (and maybe
> faster), but it actually makes things much harder and slower for
> everyone else. Merged source trees make it so that it's stupid easy to
> have light forks of everything, which means people will just patch and
> change things without consequence. That makes it much harder to
> identify changes for rebasing to newer versions, what's safe to drop,
> and so on.
> 
> I know this because it was a problem where I work before I banished
> merged source trees where I work, and it remains an issue for Linux
> distributions that operate this way too.

You can't actually "banish" merged source trees in practice. At most
you end up pushing them

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Neal Gompa

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
>>> > 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 conflicts.
>>>
>>> We are aiming for something similar what you just described. I created this 
>>> wiki page to describe the work briefly:
>>>
>>> https://fedoraproject.org/wiki/CI/source-git
>>>
>>> The actualy work is happening here now:
>>>
>>> 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 branches which track respective Fedora 
>>> versions -- you can easily cherry pick fixes. We would validate every pull 
>>> request in such repo and stuff would get merged only when it passes 
>>> testing. Right now we are trying to write minimal code to make such thing 
>>> work, evaluate it and present at devconf.cz to get some more feedback.
>>>
>>> Hopefully we would utilize clime's work to help with changelogs and release 
>>> numbers: https://pagure.io/rpkg-util/pull-request/15
>>
>>
>> So that would be cool if my work is actually used. I recommend looking at 
>> https://pagure.io/rpkg-util/blob/master/f/macros specifically if you could 
>> use that.
>>
>> I planned to open a PR for python-rpkg do enable this functionality in 
>> Fedora but I am being delayed by work on rpkg-3.0, which is yet another *pkg 
>> client.
>>
>> Anyway, if there is some interest in making this available in Fedora soon, I 
>> can happily do it first. Just kick (contact) me.
>> To be clear, the macros can only do the second point from "What and why?" at 
>> https://github.com/user-cont/source-git.
>
>
> The README was changed meawhile so the second point from here: 
> https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md
>

The problem with merged source trees (aka source-git) is that it
implies forking projects. It's an easy trap to start having vendor
trees and maintain your own functionality independent from upstream.
Fundamentally, I don't want having patches to be too easy, because
then people _will_ do that. Fedora should strive to remain close to
upstream projects and interact with them to make things better[1].

And the thing is, it's not like I'm unfamiliar with merged source
models. I've worked in distributions that operated that way, and the
consequence is almost always that things are patched and changed
without ever interacting with upstream. Of course, that's their choice
to do so, but most distributions do not have "upstream-first" as a
specific goal.

In addition, it may seem like it makes things easier (and maybe
faster), but it actually makes things much harder and slower for
everyone else. Merged source trees make it so that it's stupid easy to
have light forks of everything, which means people will just patch and
change things without consequence. That makes it much harder to
identify changes for rebasing to newer versions, what's safe to drop,
and so on.

I know this because it was a problem where I work before I banished
merged source trees where I work, and it remains an issue for Linux
distributions that operate this way too.

When patches are a burden, you will only do it when needed, and you
feel more compelled to try to avoid it. Ironically, that makes it
easier to move faster and update more frequently.

I have not yet seen a practical example of merged source trees
improving the quality of package maintenance.

[1]: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Michal Novotny

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 release
>> > numbers and changelogs.  This way, you can apply a lot of fixes to
>> > multiple branches without encountering mandatory conflicts.
>>
>> We are aiming for something similar what you just described. I created
>> this wiki page to describe the work briefly:
>>
>> https://fedoraproject.org/wiki/CI/source-git
>>
>> The actualy work is happening here now:
>>
>> 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 branches which track respective Fedora
>> versions -- you can easily cherry pick fixes. We would validate every pull
>> request in such repo and stuff would get merged only when it passes
>> testing. Right now we are trying to write minimal code to make such thing
>> work, evaluate it and present at devconf.cz to get some more feedback.
>>
>> Hopefully we would utilize clime's work to help with changelogs and
>> release numbers: https://pagure.io/rpkg-util/pull-request/15
>
>
> So that would be cool if my work is actually used. I recommend looking at
> https://pagure.io/rpkg-util/blob/master/f/macros specifically if you
> could use that.
>
> I planned to open a PR for python-rpkg do enable this functionality in
> Fedora but I am being delayed by work on rpkg-3.0, which is yet another
> *pkg client.
>
> Anyway, if there is some interest in making this available in Fedora soon,
> I can happily do it first. Just kick (contact) me.
> To be clear, the macros can only do the second point from "What and why?"
> at https://github.com/user-cont/source-git.
>

The README was changed meawhile so the second point from here:
https://github.com/user-cont/source-git/blob/3f0875dcaa08a48562d19879cf53104bcac5cdd4/README.md


>
> As for Fabio's question below if this would imply mirroring upstream Git
> repos in our DistGit: If rpkg macros are employed (linked above), then
> both use-cases (mirroring and uploading tarballs) will be possible. It
> will depend on packager's decision for each individual package and you
> could switch between these two anytime. It would also actually mean that
> development stays on DistGit and is encouraged there.
>
> M.
>
>
>>
>>
>>
>> Tomas
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Fabio Valentini

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 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 yearly updates, and it can be avoided if you
> > > really want.
> > >
> > > macOS requires you to specifically choose the yearly update, though
> > > they may have changed with Mojave.
> > >
> > > Not sure about Android, but the fact that Google has had to twist
> > > things into a knot to try and get updates out to users indicates that
> > > upgrades to Android aren't being pushed out for the most part.
> > >
> > > Windows is the only one forcing upgrades, and it is perhaps one of
> > > the
> > > reasons that hardware vendors are showing more interest in Linux as
> > > people are now more willing to consider anything other than Windows.
> > >
> > > Really, the only place where forced upgrades are happening, are
> > > accepted, and seem to actually work are on the application side and
> > > that is because, demonstrated by the web browsers, frequent updates
> > > can be done unobtrusively and reliably.
> >
> > And with the named examples are you gonna get any support and updates
> > if you decide to hold off an upgrade to a newer OS? I doubt.
> > I can certainly hold off upgrade to Android 9 on my phone, but that
> > doesn't mean I'm gonna get any further updates for Android 8 from the
> > phone vendor.
> > There is a huuuge difference between "not forcing upgrades" and
> > "providing supported and secure way to stay on the current release".
>
> I think this tied up with one of the major problems we are trying to
> solve with Fedora Modularity, the "Too Fast, Too Slow" problem.


I think identifying which components move too slow or too fast would be a
good start - even if those lists might depend on the specific user or
use-case.

I am not sure it is bad for Fedora to only have a single supported
> "release."  If you refuse an upgrade, you're on your own.  If you
> refuse it because you're going on a trip, have a presentation, etc.
> and plan to do it later, you generally don't care.  If you do it
> because you don't want your system to change, I am not sure Fedora
> should be your distribution of choice (I'll introduce you to my
> friends CentOS and RHEL).
>
> If we did a "stable rolling release base" that, described simply and
> incompletely, had a beta and stable option where you knew your
> hardware would work and your apps would run I think most users,
> desktop and server, would be happy.


What about aliasing fedora-N to "rolling-beta", and fedora-N-1 to
"rolling-stable" (similar to what Debian does)? Every 6 months or so,
rolling-stable users would get an upgrade to a fedora release that's been
well-used and -tested for about 6 months. (Which I guess is what some
people already do manually.)

We only need to make sure that the upgrade path always works for, say, the
last 4 fedora releases (or however many we need to support upgrading from).
Upgrades from N-2 to N are already supposed to work (I think), so this
shouldn't be too hard.

(Also, silverblue would make this really easy, by "just" automatically
switching to the new N-1 branch every 6 months, when N-2 hits EOL).

That way, the number of supported fedora releases stays the same, and only
the upgrade path needs to be reliable for longer.

Fabio

We use the "beta" to find
> hardware regressions and to signal hardware we are dropping support
> for or adding new support for, and we use stable for people who want
> to get things done.  Layer on Modules. containers and Flatpaks and we
> have the apps moving on their own speed on this base.  Yes, it creates
> a matrix, but it one we have been working on CI to support already and
> one that I think users will actually embrace.  They don't need to know
> the whole matrix, just how to adjust if the defaults aren't what they
> want.
>
> I think this gets us:
>   * what we think the hardware vendors need (continuous support)
> without blowing up our version count
>   * smaller QA targets for various pieces (and we are already planning
> all of these pieces)
>   * a stable leading edge solution that by "pinning" your app version
> feels like a rolling release and a traditional release at the same
> time
>   * reduce our work on keeping releases active and some of our
> backporting footprint
>   * increases the footprint of people testing and using our innovation in
> the OS
>
> regards,
>
> bex
>
> >
> > Jiri
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread 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 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 yearly updates, and it can be avoided if you
> > really want.
> >
> > macOS requires you to specifically choose the yearly update, though
> > they may have changed with Mojave.
> >
> > Not sure about Android, but the fact that Google has had to twist
> > things into a knot to try and get updates out to users indicates that
> > upgrades to Android aren't being pushed out for the most part.
> >
> > Windows is the only one forcing upgrades, and it is perhaps one of
> > the
> > reasons that hardware vendors are showing more interest in Linux as
> > people are now more willing to consider anything other than Windows.
> >
> > Really, the only place where forced upgrades are happening, are
> > accepted, and seem to actually work are on the application side and
> > that is because, demonstrated by the web browsers, frequent updates
> > can be done unobtrusively and reliably.
>
> And with the named examples are you gonna get any support and updates
> if you decide to hold off an upgrade to a newer OS? I doubt.
> I can certainly hold off upgrade to Android 9 on my phone, but that
> doesn't mean I'm gonna get any further updates for Android 8 from the
> phone vendor.
> There is a huuuge difference between "not forcing upgrades" and
> "providing supported and secure way to stay on the current release".

I think this tied up with one of the major problems we are trying to
solve with Fedora Modularity, the "Too Fast, Too Slow" problem.  I am
not sure it is bad for Fedora to only have a single supported
"release."  If you refuse an upgrade, you're on your own.  If you
refuse it because you're going on a trip, have a presentation, etc.
and plan to do it later, you generally don't care.  If you do it
because you don't want your system to change, I am not sure Fedora
should be your distribution of choice (I'll introduce you to my
friends CentOS and RHEL).

If we did a "stable rolling release base" that, described simply and
incompletely, had a beta and stable option where you knew your
hardware would work and your apps would run I think most users,
desktop and server, would be happy.  We use the "beta" to find
hardware regressions and to signal hardware we are dropping support
for or adding new support for, and we use stable for people who want
to get things done.  Layer on Modules. containers and Flatpaks and we
have the apps moving on their own speed on this base.  Yes, it creates
a matrix, but it one we have been working on CI to support already and
one that I think users will actually embrace.  They don't need to know
the whole matrix, just how to adjust if the defaults aren't what they
want.

I think this gets us:
  * what we think the hardware vendors need (continuous support)
without blowing up our version count
  * smaller QA targets for various pieces (and we are already planning
all of these pieces)
  * a stable leading edge solution that by "pinning" your app version
feels like a rolling release and a traditional release at the same
time
  * reduce our work on keeping releases active and some of our
backporting footprint
  * increases the footprint of people testing and using our innovation in the OS

regards,

bex

>
> Jiri
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Michal Novotny

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 fixes to
> > multiple branches without encountering mandatory conflicts.
>
> We are aiming for something similar what you just described. I created
> this wiki page to describe the work briefly:
>
> https://fedoraproject.org/wiki/CI/source-git
>
> The actualy work is happening here now:
>
> 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 branches which track respective Fedora
> versions -- you can easily cherry pick fixes. We would validate every pull
> request in such repo and stuff would get merged only when it passes
> testing. Right now we are trying to write minimal code to make such thing
> work, evaluate it and present at devconf.cz to get some more feedback.
>
> Hopefully we would utilize clime's work to help with changelogs and
> release numbers: https://pagure.io/rpkg-util/pull-request/15

So that would be cool if my work is actually used. I recommend looking at
https://pagure.io/rpkg-util/blob/master/f/macros specifically if you could
use that.

I planned to open a PR for python-rpkg do enable this functionality in
Fedora but I am being delayed by work on rpkg-3.0, which is yet another
*pkg client.

Anyway, if there is some interest in making this available in Fedora soon,
I can happily do it first. Just kick (contact) me.
To be clear, the macros can only do the second point from "What and why?"
at https://github.com/user-cont/source-git.

As for Fabio's question below if this would imply mirroring upstream Git
repos in our DistGit: If rpkg macros are employed (linked above), then
both use-cases (mirroring and uploading tarballs) will be possible. It will
depend on packager's decision for each individual package and you
could switch between these two anytime. It would also actually mean that
development stays on DistGit and is encouraged there.

M.

>
>
>
> Tomas
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread Fabio Valentini

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
> > multiple branches without encountering mandatory conflicts.
>
> We are aiming for something similar what you just described. I created
> this wiki page to describe the work briefly:
>
> https://fedoraproject.org/wiki/CI/source-git
>
> The actualy work is happening here now:
>
> 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 branches which track respective Fedora
> versions -- you can easily cherry pick fixes. We would validate every pull
> request in such repo and stuff would get merged only when it passes
> testing. Right now we are trying to write minimal code to make such thing
> work, evaluate it and present at devconf.cz to get some more feedback.
>

So you'd move to mirroring upstream git repositories? I personally wouldn't
want to do that for my packages ... I like the current workflow with
uploading the official tarballs to the fedora lookaside cache - it feels
like a cleaner solution than effectively light-forking basically every open
source project in existence ...

Additionally, what's the effect on disk usage? git repositories can get
quite large.

Fabio


> Hopefully we would utilize clime's work to help with changelogs and
> release numbers: https://pagure.io/rpkg-util/pull-request/15
>
>
> Tomas
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-20 Thread 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 encountering mandatory conflicts.

We are aiming for something similar what you just described. I created this 
wiki page to describe the work briefly:

https://fedoraproject.org/wiki/CI/source-git

The actualy work is happening here now:

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 branches which track respective Fedora versions -- you can easily 
cherry pick fixes. We would validate every pull request in such repo and stuff 
would get merged only when it passes testing. Right now we are trying to write 
minimal code to make such thing work, evaluate it and present at devconf.cz to 
get some more feedback.

Hopefully we would utilize clime's work to help with changelogs and release 
numbers: https://pagure.io/rpkg-util/pull-request/15


Tomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-19 Thread Kalev Lember


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 streams. "kernel" that has latest kernel, and
"kernel-lts" that has the LTS kernel that was latest when this Fedora
version was first released. "kernel" would get continuously rebased to
latest version, and "kernel-lts" would just stay on the same version the
whole life cycle.

If some classes of users (hardware vendors) prefer LTS kernel, and some
classes of users (people installing their computers themselves and
wanting latest hardware support) prefer latest kernel, we should be able
to make both happy.

--
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-19 Thread Luya Tshimbalanga

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. Let's talk about how we might address >
some of the users and use cases we're missing out on. > > When I talk to
people about this, I often get "hey, you should do LTS > or go to
rolling releases.” As I've said before, on the surface that's > a weird
thing to say, since the actual user impact of those two > different
things is mostly _opposite_. So, digging in, it often really > means "I
don't want the pain and fear of big OS upgrades". > > We've addressed
that in several ways: first, making upgrades better. > (Thanks everyone
who has worked on that.) A Fedora release-to-release > update is
normally not much more trouble than you might get some random > Tuesday
with a rolling release. Second, we have some things like Fedora > Atomic
Host and upcoming Fedora CoreOS and IoT which both implement a > rolling
stream on top of the Fedora release base. And finally, there's > the
coming-someday plans for gating Rawhide, making that a better >
proposition for people who really want to live on the edge. > > 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 tickbox, they don't even look at us >
seriously. I'd love to change these things. To do that, we need >
something that lasts for 36-48 months. > > 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 balance this with getting people new stuff > fast as well?
> > > > The biggest issues are proper documentations and manpower.
Before planning a long term release, improving the existing
infrastructure accepting new contributors and active maintenance of
packages  (say adding a co-maintainer)with a guideline easy to read and
understand should be the main priority. Case in the point with the
current wiki hard to navigate when it comes to look at the information
leading to an outdated version.

Additionally, have more polishing on the entire Fedora operating system
is a bonus i.e. presentation (looking at the marketing department, one
of the strong point from Ubuntu) and solid foundation.

Luya




0x5E528174D8A2609A.asc
Description: application/pgp-keys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-19 Thread Nicolas Mailhot

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, that's kind of my point. Packaging changes (not at the core
> level, like with the other thread) should not be Fedora-based, they
> should be in coordination *using macro packages* across the entire
> ecosystem. 

I'm not talking about using macros to ease changes I'm talking about
macros used directly in rpm specs because they save packager time and
effort. You don't get more core than that, if the macros are not there
the specs do not build. And spec ifdefs just create more packager work
than if the macro had not been written in the first place (that's one
reason the number of epel packagers is far smaller than the number of
Fedora packagers).

> (Again, Group tag removal seems an obvious example.)

That would take a specific organisation, to track macro changes, and
organise their backport whenever possible. FPC as it is organised today
does not have the required manpower.

Some macros are just lua and shell code easily backported, others
require an explicit rebuild of the tip rpm to old stable (should not be
a problem because rpm is backwards-compatible but we forbid ourselves
that right now), others backports are plain impossible because they
depend on a specific (other than rpm) component update. EPEL backports
would almost certainly collide with old macro versions in the RH EL part
and on lack of capabilities of ancient shell/rpm.

> And coming from an EL6 perspective, what "old rpm deficiencies" are
> you 
> referring to? Optional Recommends might be nifty new features, but 
> somehow we're getting along without them still fine.

What you call getting along fine is mostly slowing down Fedora
progression so the mismatch with EL does not get completely awful (as
your first message clearly stated).

>  (And, judging from 
> reports, the semantics and kinks haven't been entirely worked out of 
> those yet regardless.) If a core rpm forklift can be done safely onto
> an 
> old release, then that's an option to be kept on the table (even in a 
> stable release), but I'm hard pressed to think of any "deficiency"
> per se. 

Just a stupid thing like Fedora rpm adding end of lines by default to
echo warn and err has cost me hours patching the end of lines back in my
el backport. And I don't blame Fedora rpm for fixing this, I blame
whoever though EL-side that it would be ok to differ from the Fedora rpm
behaviour for years.

> 
> If you're discussing things like 3K-character-long java arguments,
> then 
> I agree with you that that's painful. But I fail to see how the core 
> needs of any build system (or install system) can be any more complex 
> than arbitrary shell, and these sections already *are* arbitrary
> shell. 

Before you get to the arbitrary shell part you need to pass the rpm
macro argument parser. It does not understand long options (even if you
have enough letters available for single-character flags "nice" letters
will collide when composing macros). It does not understand repeated
flags (only one flag value possible per call). Realistically for any
semi-complex macro you'll end up defining a magic rpm variable where you
put the arguments you need, and have the macro read this variable
instead of using macro arguments, because any other argument passing
attempt will flounder on the rpm argument processor.

And that's not exotic argument passing invented by awful java devs, even
dnf uses all of those.

> I'd like to never have to tweak CFLAGS= in a %build, but it
> occasionally does happen. That doesn't mean it's a design flaw --
> that's why code is allowed to be there. 

Yes, classical rpm works ok for C/C++ programs. That's pretty much the
only class of content that does not need long lines of shoehorning in
spec files. Want to bare any non C/C++ package from the distro so rpm
does not need to change?

> In a worst-case-scenario, one can always 
> standardize on an external helper to adjust or modify things during 
> execution (which has the added benefit of bench-testability and code 
> re-use) and use a macro to call that.
> 
> I feel like this mirrors the debate between imperative initscripts
> and  declarative unit files. Macros are great, and macros calling 
> distro-defined helpers work, but a religious purge of shell does not 
> really seem to be a win.

Then you volunteer to review and audit all those wonderful shell lines
in the tens of thousands of Fedora specs? I though not. Writing
thousands of lines of shell code in specs is trivial. Reviewing and
maintaining the result is not.

> > Most notably, all the dead-stupid %setup/%sources/Tag
> > processing, that you know any rpm novice will misunderstand and get
> > wrong, even before you attempt explanations. Those warts were merely
> >

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-19 Thread Stephen John Smoogen

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 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,
> > >> 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 tickbox, they don't even look at us
> > >> seriously. I'd love to change these things. To do that, we need
> > >> something that lasts for 36-48 months.
> > >
> > > this sounds like a very valid problem.
> > >
> > > But if this was fixed, what number of manufacturers would adopt Fedora
> > > and how many installations do they ship (eg per year)?  Could it be
> > > fixed in another way, like a special OEM Fedora release?
> >
> > And why haven't these manufacturers already adopted CentOS which is
> > definitely around longer than 36-48 months?
> >
>
> 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

Those manufacturers can't really influence Windows any either. They
instead know that they will sell enough laptops with Windows on them
that they won't take a bath. There is also complicated financial
methods where Microsoft seems to supplement laptop sales so that it is
cheaper for them to ship with windows than to ship a system with no
OS. 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)

These are usually the bigger reasons why most larger OEM's haven't
been interested in putting CentOS or even Ubuntu on a large set of
systems. They know that the number of systems they will sell are at
most 1% of all sales.. and there isn't a large enough incentive to do
the various work they need to do that. So you end up needing a vendor
who is going to go all in (the System76's) or you get someone who is
going to offer a specific model set they know they can do
cost-effectively but aren't going to put too much into it. [AKA if the
engineers working on it love MCC Linux.. then its going to be MCC
Linux.]

In the end, for Fedora to be on a laptop by default someone is going
to have to say 'we are betting the farm to do this and will do the
work to make that happen'. I also think that we are focusing on one
part of the original proposal... It wasn't the entire reason for doing
some sort of LTS somewhere. It is just the one we can probably pick
holes in the easiest :).

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-19 Thread Japheth Cleaver


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 packaging" means doing things at odds with
or
in an incompatible way other distros (whether downstream,
"downstream",  or not) this is not a feature, or very nice.

I think you do not realise how much old rpm is holding us back, and how
much we limit ourselves in Fedora, and make ourselves more work, just to
cater to those old rpm limitations. A small number of people, that
include Jason Tibbitts, perform unappreciated heroic wonders all year
round to limit the damage old rpm deficiencies inflict on Fedora and
EPEL, and if you think the situation is imperfect, well it would be
terrible without them.

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, that's kind of my point. Packaging changes (not at the core level, 
like with the other thread) should not be Fedora-based, they should be 
in coordination *using macro packages* across the entire ecosystem. 
(Again, Group tag removal seems an obvious example.)


And coming from an EL6 perspective, what "old rpm deficiencies" are you 
referring to? Optional Recommends might be nifty new features, but 
somehow we're getting along without them still fine. (And, judging from 
reports, the semantics and kinks haven't been entirely worked out of 
those yet regardless.) If a core rpm forklift can be done safely onto an 
old release, then that's an option to be kept on the table (even in a 
stable release), but I'm hard pressed to think of any "deficiency" per 
se. (%trans processing and %build conditionals strike me as things it 
would've be important to backport.)



Classical rpm targets and works well for C/C++ projects that use
autotools, a static small list of dependencies, and release as an
archive. A growing part of the distribution does not fit this model any
more. git and the internet blew away any limit on the number and cadence
of dependencies for every language, including C/C++. Non C/C++ languages
do not fit in the C/C++ macro model. Those new parts needs the same
level of rpm support as previous projects, which means writing new
macros, that build on other new macros, and it all falls appart if you
can not rely on some of those other macros existing because of a time-
jump in el land.

Classical rpm macro argument processing is severely deficient, not even
on par with shell getopts-level of argument processing, let alone the
argparse-level many languages now sport. That creates a huge impedance
mismatch with modern commands that expect more elaborate argument
syntax. You can not drive them from rpm macros, you end up putting lists
of arguments in variables to pass them to commands behind the macro
argument parser. That should be fixed.


If you're discussing things like 3K-character-long java arguments, then 
I agree with you that that's painful. But I fail to see how the core 
needs of any build system (or install system) can be any more complex 
than arbitrary shell, and these sections already *are* arbitrary shell. 
I'd like to never have to tweak CFLAGS= in a %build, but it occasionally 
does happen. That doesn't mean it's a design flaw -- that's why code is 
allowed to be there. In a worst-case-scenario, one can always 
standardize on an external helper to adjust or modify things during 
execution (which has the added benefit of bench-testability and code 
re-use) and use a macro to call that.


I feel like this mirrors the debate between imperative initscripts and 
declarative unit files. Macros are great, and macros calling 
distro-defined helpers work, but a religious purge of shell does not 
really seem to be a win.




Most notably, all the dead-stupid %setup/%sources/Tag
processing, that you know any rpm novice will misunderstand and get
wrong, even before you attempt explanations. Those warts were merely
annoying when dealing with a few thousands of distro packages, they have
a real cost now the distro has grown.
How is this processing "dead-stupid"? I'm seriously asking here. It's 
not difficult, and it shouldn't be too much to ask that someone be able 
to figure out the syntax of a simple recipe file like this. I agree we 
were in an RPM-documentation deadzone for a while there, but I feel like 
there are plenty of examples and guides now for novice RPM users. 
Certainly seems easier to make an .rpm than a .deb.


-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-19 Thread Mátyás Selmeci

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 to be
> the real solution.  Instead, I think, it's to piggyback onto the already
> long RHEL lifecycle but provide isolated pieces of "instability"
> (i.e. new stuff) to people who want them.
> 
> Or more simply, don't try to slow Fedora down.  Let Fedora be Fedora and
> instead leverage Fedora to speed RHEL up in selected areas where people
> want it.
> 
> MM> As noted elsewhere in this thread, many packagers are already doing
> MM> this: maintaining a slow stream for EPEL or for RHEL as part of
> MM> their day job, and a fast stream in Fedora.
> 
> So let RHEL be the core bits, moving as fast or as slow as Red Hat wants
> to support.  And let someone who wants "the new stuff" layer things over
> that.  Fedora could provide the layers, which move as fast as Fedora
> does.
> 
> Of course, the practicalities of that and the potential combinatorial
> explosion of options and interdependencies might render the whole idea
> pointless.  But that's supposed to be what the whole module system
> solves.  Or is it the flatpak system?  Maybe both.  And I believe those
> are both conveniently supported by RHEL8.
So basically something EPEL-like that doesn't have the "don't mess
with the base OS" restriction?  That would be really nice.  The long
time between RHEL releases (which seems to be getting worse, too)
makes supporting it a real pain for my group.

-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-18 Thread Gerald Henriksen

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 extending the lifecyle?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-18 Thread Neal Gompa

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.
>
> that must be why they ship a completly closed source windows

But for Windows, ODMs/OEMs benefit from the ecosystem of components
already building and targeting for that platform. And even Microsoft
does provide toolkits and assistance for major PC makers to better
support the Windows platform. And the Windows release lifecycle is
directly set up to support PC makers.

Fedora has a wonderful advantage in that our ethos and practice in
developing the distribution[1] often means we're directly plugged in
with the various upstreams and can help make things better. We can
provide that ecosystem value for PC makers, and by that token, we can
add major value over other Linux distributions and offer a positive
relationship to PC makers to encourage them to ship Linux on their
PCs, specifically Fedora.

[1]: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-18 Thread Neal Gompa

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, Nov 13, 2018 at 06:36:38PM -0500, 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 tickbox, they don't even look at us
> >> seriously. I'd love to change these things. To do that, we need
> >> something that lasts for 36-48 months.
> >
> > this sounds like a very valid problem.
> >
> > But if this was fixed, what number of manufacturers would adopt Fedora
> > and how many installations do they ship (eg per year)?  Could it be
> > fixed in another way, like a special OEM Fedora release?
>
> And why haven't these manufacturers already adopted CentOS which is
> definitely around longer than 36-48 months?
>

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. If we had an equivalent
to Fedora Legacy/openSUSE Evergreen to support a specific release for
an extended period of time, we could also allow ODMs/OEMs to be part
of that process to help improve support of their equipment with Linux
and that effort would be able to be pushed upstream with guidance from
Fedora to benefit all Linux distributions. And while most people think
the relationship is Red Hat -> Fedora, it's actually the other way
around. Fedora can be an integration point for PC makers to help those
people to benefit the Linux ecosystem as a whole.

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.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-18 Thread Tony Nelson

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 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 tickbox, they don't even look  
at us

> seriously. I'd love to change these things. To do that, we need
> something that lasts for 36-48 months.

this sounds like a very valid problem.

But if this was fixed, what number of manufacturers would adopt Fedora
and how many installations do they ship (eg per year)?  Could it be
fixed in another way, like a special OEM Fedora release?

Is this the only problem that we're trying to solve or are there  
others?

I would suggest fixing the "problem" in a completely different way.
There seems to be a class of customer that wants the very latest thing,
often, but for each such thing to hold still and be maintained for 3 to
7 years.  That isn't Fedora, or even RHEL.

Fedora can be updated and upgraded with good reliablility now.  So,
instead, continue to make updates and version upgrades more and more
reliable, and revertable when they don't work, as MSWindows has been
doing.  Get more users within those customers so they trust that
reliablility.  Then those customers can choose, in a business way, to
install Fedora for their customers, who will get and keep the latest
and greatest, and Fedora has captialized on its strengths.

--

TonyN.:'   
  '  
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-18 Thread Orion Poplawski


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 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 tickbox, they don't even look at us
seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.


this sounds like a very valid problem.

But if this was fixed, what number of manufacturers would adopt Fedora
and how many installations do they ship (eg per year)?  Could it be
fixed in another way, like a special OEM Fedora release?


And why haven't these manufacturers already adopted CentOS which is 
definitely around longer than 36-48 months?


--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-18 Thread Richard W.M. Jones

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,
> 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 tickbox, they don't even look at us
> seriously. I'd love to change these things. To do that, we need
> something that lasts for 36-48 months.

this sounds like a very valid problem.

But if this was fixed, what number of manufacturers would adopt Fedora
and how many installations do they ship (eg per year)?  Could it be
fixed in another way, like a special OEM Fedora release?

Is this the only problem that we're trying to solve or are there others?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-18 Thread Leigh Scott

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: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-18 Thread David Tardon

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 see how we're going to be able to compete with that,
> > not 
> > unless our Fedora LTS is just CentOS with different branding.
> > 
> > Michael
> 
> I don't consider RHEL7 or CentOS7 are true LTS releases, they are
> more like tame fedora releases now.
> Each point release has major changes, 7.6 switched to mesa/libglvnd.
> 

Do you think that such major changes wouldn't happen in a Fedora LTS?

D.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-17 Thread Gerald Henriksen

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 that is a good source of future
developers/packagers/testers/users.

Which thus results in perhaps another issue to consider, release
dates.

What is the best time for these manufacturers to have a release?

It has been mentioned that they would likely need a release for 6
months before releasing hardware with it, and that would likely be
similar to any organization looking to roll it out onto desktops.

So should Fedora, if it goes down this path, look at having (September
-6) as a goal, to allow for the start of the school year and then the
approaching Christmas shopping season?  Or maybe (August - 6) to allow
for back to school?

A need for an early March / late February release is perhaps just as
important a question given the changes that would require in release
planning as whether to do a LTS style release.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-17 Thread Gerald Henriksen

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 cycle leads to problems for several years worth of hardware
>> releases.
>> 
>> If you are a hardware vendor would you want to be releasing a laptop
>> running CentOS 7.x today, with its outdated versions of much of the
>> software (that is a value to the enterprise server market, but less so
>> consumer)?
>
>But the same goes for ANY LTS distribution!
>
>No distro is going to do LTS releases with 37 month support every 6 months. 
>It would mean supporting 7 releases at once!

Of course not, which is one of the reasons why moving to a 12 month
release cycle may be a better idea, with a sort of LTS release maybe
every 2 years.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-17 Thread Leigh Scott

> 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 LTS is just CentOS with different branding.
> 
> Michael

I don't consider RHEL7 or CentOS7 are true LTS releases, they are more like 
tame fedora releases now.
Each point release has major changes, 7.6 switched to mesa/libglvnd.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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
> or 
> in an incompatible way other distros (whether downstream,
> "downstream",  or not) this is not a feature, or very nice.

I think you do not realise how much old rpm is holding us back, and how
much we limit ourselves in Fedora, and make ourselves more work, just to
cater to those old rpm limitations. A small number of people, that
include Jason Tibbitts, perform unappreciated heroic wonders all year
round to limit the damage old rpm deficiencies inflict on Fedora and
EPEL, and if you think the situation is imperfect, well it would be
terrible without them.

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.

Classical rpm targets and works well for C/C++ projects that use
autotools, a static small list of dependencies, and release as an
archive. A growing part of the distribution does not fit this model any
more. git and the internet blew away any limit on the number and cadence
of dependencies for every language, including C/C++. Non C/C++ languages
do not fit in the C/C++ macro model. Those new parts needs the same
level of rpm support as previous projects, which means writing new
macros, that build on other new macros, and it all falls appart if you
can not rely on some of those other macros existing because of a time-
jump in el land.

Classical rpm macro argument processing is severely deficient, not even
on par with shell getopts-level of argument processing, let alone the
argparse-level many languages now sport. That creates a huge impedance
mismatch with modern commands that expect more elaborate argument
syntax. You can not drive them from rpm macros, you end up putting lists
of arguments in variables to pass them to commands behind the macro
argument parser. That should be fixed.

Classical rpm has all kinds of weird warts to accommodate what people
though would be the way to the future in the 90’s. Even though they
created a brilliant design (mostly), they were far from omniscient or
always right (and much too influenced by perl). After 20 years, living
in the real future, it should not be iconoclastic to revisit some of
their decisions. Most notably, all the dead-stupid %setup/%sources/Tag
processing, that you know any rpm novice will misunderstand and get
wrong, even before you attempt explanations. Those warts were merely
annoying when dealing with a few thousands of distro packages, they have
a real cost now the distro has grown.

And so on.

There's no reason rpm can not adapt to another decade of newness. But it
needs to adapt. EL6 (or 7) rpm is not up to the task as is. All the
project people that say distro packaging sucks loads, are not dead
wrong. They're too prideful to put forward the thousand of rpm papercuts
that made them look for something else, real men (and women) do not
complain about papercuts, but those papercuts exist beneath the showy
bogus arguments they usually put forward.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Jason L Tibbitts III

> "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 piggyback onto the already
long RHEL lifecycle but provide isolated pieces of "instability"
(i.e. new stuff) to people who want them.

Or more simply, don't try to slow Fedora down.  Let Fedora be Fedora and
instead leverage Fedora to speed RHEL up in selected areas where people
want it.

MM> As noted elsewhere in this thread, many packagers are already doing
MM> this: maintaining a slow stream for EPEL or for RHEL as part of
MM> their day job, and a fast stream in Fedora.

So let RHEL be the core bits, moving as fast or as slow as Red Hat wants
to support.  And let someone who wants "the new stuff" layer things over
that.  Fedora could provide the layers, which move as fast as Fedora
does.

Of course, the practicalities of that and the potential combinatorial
explosion of options and interdependencies might render the whole idea
pointless.  But that's supposed to be what the whole module system
solves.  Or is it the flatpak system?  Maybe both.  And I believe those
are both conveniently supported by RHEL8.

As a practical example, take KDE.  I view the recent dropping of KDE
from RHEL as a net positive because now you can easily get a KDE desktop
on RHEL that actually gets close to the actual current state of KDE
instead of being something ancient.  So stable kernel and "core stuff",
fresh desktop.  Toss in an updated firefox, vim, emacs, zsh and
libreoffice and I guess for my daily driving I'd probably never notice
that the deep innards are a few years behind.  As long as it actually
supports the hardware

This still takes volunteer effort which I just don't think is available
currently, though it's way less than maintaining a Fedora release for
extra years.  And it needs a willingness to mess with the base RHEL
which we have so far not ever permitted.  I imagine that doing any of
this would put you well out of any support contract you might have, but
if done with finesse... maybe not.  And if CentOS is the base then
that's not a concern at all.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Japheth Cleaver


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 releases that can never evolve but which
still hold back progress in Rawhide is just too much.

Really, this is what our downstream distributions RHEL and CentOS are
for.  That was the answer then and I don't see why it doesn't still
apply.


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 or 
in an incompatible way other distros (whether downstream, "downstream", 
or not) this is not a feature, or very nice.


The use of *-rpm-macros packages to try to standardize deltas across 
distros helps, but calls out for a more organized and systemic, 
cross-distro and cross-release ecosystem approach. It's ugly enough now 
that IMHO any LTS discussion needs to take this into consideration even 
more.


"Let's remove Group tags from Rawhide specs because we don't like them, 
even though every other distro uses them and they're staying in RPM" is 
not a particularly positive recent example of Fedora stewardship over 
packaging, and I'm sure any EL6 sysadmin can provide more examples from 
the last decade.


-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Josh Boyer

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
> the current long term support kernels are supported.  And even before
> that, when kernel development worked in a rather different way, 2.0, 2.2
> and 2.4 were all maintained as "stable releases" long after development
> had moved on to newer things.  The concept of "stable" Linux kernels
> maintained for years predates 2011 by quite some time.

The meaning of "official" is that it was proposed and accepted by the
kernel community as an organized and agreed upon approach.  The
relevance it has over the -ac or Adrian Bunk kernels is that it means
it has the weight of the entire developer community behind it, as
opposed to being driven by a single developer.

You know, kind of like the difference between a person doing a Fedora
LTS, and the Fedora community doing an LTS.  It's important the
community buys into it to really let it scale and grow and improve.

> In any case, that hardly matters because the context that's important is
> how Fedora viewed those kernels in previous discussions about longer
> Fedora release lifecycles.  I don't think there were any objections to
> them based on some notion of being "official".  Linux itself was a lot
> less "official" in general back then.  We knew that there were kernel
> releases which could be used for the duration of a longer lifecycle but
> that it wouldn't really help with the fundamental issues.  That
> statement applies today as much as it did at the BU FUDCon in 2007.

I disagree with your conclusion here.  Having the weight of the
upstream kernel community behind an LTS kernel back then could have
very well impacted the decision.  Would it have meant Fedora LTS
became a real thing back then?  Probably not, as it's only a single
factor.  But as a former Fedora kernel maintainer, I would totally
evaluate today's LTS kernels in a much more serious manner than
previous attempts.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Jason L Tibbitts III

> "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, when kernel development worked in a rather different way, 2.0, 2.2
and 2.4 were all maintained as "stable releases" long after development
had moved on to newer things.  The concept of "stable" Linux kernels
maintained for years predates 2011 by quite some time.

In any case, that hardly matters because the context that's important is
how Fedora viewed those kernels in previous discussions about longer
Fedora release lifecycles.  I don't think there were any objections to
them based on some notion of being "official".  Linux itself was a lot
less "official" in general back then.  We knew that there were kernel
releases which could be used for the duration of a longer lifecycle but
that it wouldn't really help with the fundamental issues.  That
statement applies today as much as it did at the BU FUDCon in 2007.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Kevin Kofler

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 hardware
> releases.
> 
> If you are a hardware vendor would you want to be releasing a laptop
> running CentOS 7.x today, with its outdated versions of much of the
> software (that is a value to the enterprise server market, but less so
> consumer)?

But the same goes for ANY LTS distribution!

No distro is going to do LTS releases with 37 month support every 6 months. 
It would mean supporting 7 releases at once!

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Iñaki Ucar

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 (the first kernel that I recall anyone
> calling some equivalent of "LTS") was released 12.5 years ago, while FC5
> was fresh.  I do recall its existence being considered in the
> discussions that happened in the FC6 timeframe, though I wasn't involved
> in all of those.  It was a very interesting time with the core-extras
> merge and the community finally having a say in the maintenance of every
> piece of the distro.  Obviously the release cadence and lifecycle was a
> big topic.
>
>  - J<
>

AFAIK, that wasn't officially supported. Official LTS support started
around 2011.

Iñaki

>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Jason L Tibbitts III

> "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") was released 12.5 years ago, while FC5
was fresh.  I do recall its existence being considered in the
discussions that happened in the FC6 timeframe, though I wasn't involved
in all of those.  It was a very interesting time with the core-extras
merge and the community finally having a say in the maintenance of every
piece of the distro.  Obviously the release cadence and lifecycle was a
big topic.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Matthew Miller

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 do hope you have some
> recollection of it.  Put simply, Fedora has had this discussion before.
> A number of times.  Going back to FC1 and what the release cycle would
> look like.  At one point it was basically an endless thread that lasted
> the better part of a year.

Okay, sure, how about: something we haven't talked about seriously in a
long, long while. That proposal from Jeroen is from 2011. I think that's
long enough that it's okay to look again.

> 1) A lot of people would love to consume such a release.
> > 2) Not nearly as many actual maintainers would want to do so.
> 
Yep, yep.

> 3) At minimum, we need a kernel.  Which means we need a kernel team.  I
>doubt the current kernel team would be any more enthusiastic about
>either backporting everything, maintaining packages of the extended
>lifetime kernel packages (assuming those even line up with the
>release schedule) or pushing the current kernel back to the
>equivalent of... Fedora 25 or so.

I think things are different here for several reasons:

1) Upstream LTS kernel now.
2) Investments in Fedora kernel CI may change the landscape
3) See Brendan's comment on "middle layer" stability. Faster moving kernel
   may be just fine.
3) Depending on outcome of our community conversation, Red Hat may be
   willing to put in some resources.

> 4) Someone has to do release engineering.  Even in the earlier days this
>was seen as something that wasn't going to happen.

Right; that was basically a "what Red Hat is willing to fund" thing. Fedora
Legacy demonstrated that it's possible but very very hard to sustain without
ongoing funded positions. But this is not necessarily a blocker going
forward.

> And now we're bigger, and there are more big systems that would need
> maintenance.  Oh, and we have a security team now; they'd have to deal
> with issues in those old releases.  And more big package sets like
> Python and Node and Go and whatever, some of which amount to a larger
> number of packages than made up the entirety of one of the old Fedora
> releases.  Hello, Python SIG?  Good luck finally getting rid of
> python2.  You get two more years of support backporting security fixes
> and you don't even get paid for it.

I agree that we can't possibly commit to long-term maintenance for the whole
distro. That's part of why I've been on about all this rings and modularity
stuff. :)

> 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 releases that can never evolve but which
> still hold back progress in Rawhide is just too much.

I don't think we'd necessarily be held back in that same way. "RPM never
changes" wouldn't need to be something we'd hold to. ("RPM not replaced with
pacman" is a different story.)

> Really, this is what our downstream distributions RHEL and CentOS are
> for.  That was the answer then and I don't see why it doesn't still
> apply.

There are sectors where this is important where those distros aren't the
best fit. Red Hat is not interested in an end-user desktop market. Red Hat
isn't making an edge-devices IoT thing. And there is a lot of academic use
where Fedora is a better fit than either but which we are not selected due
to bad alignment with university IT needs.

> 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
> lifecycle that also gets all the new stuff.  That's seems like a
> contradiction in terms.

It's the fundamental contradiction that all operating systems face: users
complain "too fast and too slow!" at the same time.

As noted elsewhere in this thread, many packagers are already doing this:
maintaining a slow stream for EPEL or for RHEL as part of their day job, and
a fast stream in Fedora. SUSE manages to integrate this together with Leap;
because of our multi-brand puzzle, we've been kind of blocked from taking
advantage of what we have. But that's really an artificial block; it's all
open source, all very similar technology, and all in the same family, even!

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Jiri Eischmann

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 people who really could be happily
> > running
> > Fedora but since we don't check the tickbox, they don't even look
> > at 
> > us
> > seriously. I'd love to change these things. To do that, we need
> > something that lasts for 36-48 months.
> 
> "Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years"
> 
> https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18.04-lts-linux-support-to-10-years.html
> 
> I just don't see how we're going to be able to compete with that,
> not 
> unless our Fedora LTS is just CentOS with different branding.

As I understand it the intend is not to compete with Ubuntu who has a
longer support, but to have long enough support to be a viable option
for hardware vendor etc. IMHO anything above 5 years doesn't matter
much on desktop, especially laptops. So Ubuntu could have 15 years of
support, but it wouldn't mean that Fedora with 3-4 years couldn't
compete with it.

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 hardware problems
>   * you have a Z-era window where upgrades to the current tip should
> not
> require hardware changes
>   * any software state older than the latest installation state may
> require long reboots in automated upgrade environments

And of course that also means hardware manufacturers can design and sell
hardware pre-installed with Fedora installation states, and market them
with a customer usefulness period of Z-era minus their own
integration/production time.

And N/Z are not driven by the upstream or packager level of investment,
but by the maturity of the Fedora installation and upgrade tech, and the
means you give to QA to make sure Fedora commitments are kept.

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 merged-source builds.
> > 
> > Basically, we no longer use pristine sources as inputs for package
> > builds.
> 
> Although, arguably, what constitutes a "pristine source" has changed.
> Release tarballs are often an afterthought -- or something generated
> automatically by GitHub -- while the tagged git tree is what the
> upstream project themselves consideres to be the true authoritative
> source.

That’s a simplistic view. A lot of projects are branched, forked, split,
merged, renamed, rebased and rehosted to death, you do not have any
single authoritative upstream git repository to track, any package
update can imply switching to a new upstream repository source.

Releases as in “snapshot of upstream code state” have not vanished at
all, nor been deprecated in favour of clean regular tags in a single
authoritative long-term upstream repo that could be imported and
completed in a Fedora-side fork. What happened is that the thing you
need to snapshot before starting the packaging has become a lot more
transient and mutating.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 period” (and
Microsoft gave up on that approach too). Hell Fedora cadencing was
designed around the stated needs of the GNOME project, RH employs key
GNOME devs, and GNOME requires releng exemptions for pretty much every
Fedora release. That tells loads about the utter lack of respect
upstreams have for Fedora cadencing attempts.

Rings have always been an unicorn concept, we can’t even manage to keep
our comps up to date for christsakes, any solution that posits a perfect
package classification and breakup in modules or rings, and is
maintained long term, is utterly utopic except for very small tightly
controlled parts of the distribution. And don’t forget rings/modules add
a version/time axis that is not required in comps.

So the basic question is how to conciliate a rolling release with the
needs of hardware sellers.

I'd say that requires:

* releasing initial installation states one or several times a year (1,
2, 3, or 4). Anything exposed in the official installer is part of this
state. Anything added post-install or some other way does not get a
Fedora commitment.

* committing to making unattended full upgrades work from any
intermediary state, more recent than the last Nth installation state, to
the most recent installation state
  * reboots in upgrade environments are permitted, as long as those envs
do not require human intervention
  * requiring users to blow up their disk with a new clean install
because we don’t want to automate part of the upgrade is not permitted
  * that means testing to death upgrade paths from any state between n-1 
and n to the initial-n state for every n value, and making sure the
resulting initial-n is consistent with the initial-n values taken into
account in the rest of the testing
  * that means testing to death any N-1 chain of jumps from initial-n to
initial-n+1

* committing to making unattended point upgrades work from any state
past the latest installation state to the current upgrade tip

* committing that any hardware combo, that works in the Yth installation
state, will still work at least till the Y+Z state, unless stated
otherwise (and yes that requires identifying bad hardware that will stop
being supported during the Z-step era, and defining at Y release time
the free memory/disk/cpu margins that need to be taken for Z-step to be
viable, 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 hardware problems
  * you have a Z-era window where upgrades to the current tip should not
require hardware changes
  * any software state older than the latest installation state may
require long reboots in automated upgrade environments

* and because all this is too restrictive to some, and mightily hard to
do without any early bird testing, you add a dev mode that unlocks early
access to rawhide-style packages and installation options that may not
work for N/Z windows. In dev mode there are no commitment to length of
hardware support, and the only supported upgrade paths are point
upgrades within the current upgrade cycle.

That gives packagers two package streams to care about, devel and
stable, which is pretty much what a lot of them do today.

And that only answers the “how to get more users” question.

The “how to get more packagers” question requires investing heavily in
rpm and buildsys tech to automate aggressively all the steps that should
not require manual packager processing, but do today.

ie have people look at guidelines/review/updates, and ask themselves
systematically “is there any part of the work the packager is doing that
does not absolutely require human brains and could be automated one way
or another”. And then make this automation happen. ie clean up the years
of technical debt produced by “volunteer packager time is free, rhel
packagers do what they’re ordered to, rpm is mature, make no radical
changes”. rpm and deb “won”, no distro based on another tech succeeded
in reaching mass appeal for years, that does not mean they are done. The
software env changed a lot since rpm was designed. It needs a serious
refresh, and not “this is how we’ve been doing things since forever”.

Make it easier and cheaper for packagers to produce good packages,
you'll have more packagers and a more attractive distro. Contrary to
popular thinking making easier to produce garbage has little appeal
except to people that just want to be rid of the deployment chore.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Iñaki Ucar

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 when we had per-branch ACLs.  But that never happened,
> and as there was no effort to actually compose updates for those
> releases, it doesn't matter much anyway.

In this respect (the kernel), it's true that something changed
compared to a decade ago: there was no LTS support upstream then. Now,
there is.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Vít Ondruch


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
>> lifecycle that also gets all the new stuff.  That's seems like a
>> contradiction in terms.
>
> This last paragraph you could already apply to EPEL and this is
> specifically reason why I don't bother to maintain anything in EPEL.
>

Just to clarify, I don't mind backporting security patches into Ruby
1.8.7 in RHEL6, but if there were since that time Ruby 1.9.3, 2.0.0,
2.1, 2.2, 2.3, 2.4 and 2.5 in modules, SCLs or whatever else, I can tell
you that would become quickly PITA. I am not even mentioning the whole
Ruby ecosystem 


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Vít Ondruch


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 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 do hope you have some
> recollection of it.  Put simply, Fedora has had this discussion before.
> A number of times.  Going back to FC1 and what the release cycle would
> look like.  At one point it was basically an endless thread that lasted
> the better part of a year.
>
> For the life of me I simply can't remember the various proposals called
> their releases, though.
>
> One example of what I'm talking about is
> https://kanarip.fedorapeople.org/Fedora%20Extended%20Lifecycle%20Support%20-%20The%20why,%20the%20what,%20the%20how%20and%20the%20who.pdf
> but that came after I stopped paying attention to this kind of thing.
>
> In the end the discussions I recall seemed to come down to a few basic
> things.
>
> 1) A lot of people would love to consume such a release.
>
> 2) Not nearly as many actual maintainers would want to do so.
>
> 3) At minimum, we need a kernel.  Which means we need a kernel team.  I
>doubt the current kernel team would be any more enthusiastic about
>either backporting everything, maintaining packages of the extended
>lifetime kernel packages (assuming those even line up with the
>release schedule) or pushing the current kernel back to the
>equivalent of... Fedora 25 or so.
>
> 4) Someone has to do release engineering.  Even in the earlier days this
>was seen as something that wasn't going to happen.
>
> 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 when we had per-branch ACLs.  But that never happened,
> and as there was no effort to actually compose updates for those
> releases, it doesn't matter much anyway.
>
> And now we're bigger, and there are more big systems that would need
> maintenance.  Oh, and we have a security team now; they'd have to deal
> with issues in those old releases.  And more big package sets like
> Python and Node and Go and whatever, some of which amount to a larger
> number of packages than made up the entirety of one of the old Fedora
> releases.  Hello, Python SIG?  Good luck finally getting rid of
> python2.  You get two more years of support backporting security fixes
> and you don't even get paid for it.
>
> 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 releases that can never evolve but which
> still hold back progress in Rawhide is just too much.


Nice summary.


>
> Really, this is what our downstream distributions RHEL and CentOS are
> for.  That was the answer then and I don't see why it doesn't still
> apply.
>
> 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
> lifecycle that also gets all the new stuff.  That's seems like a
> contradiction in terms.


This last paragraph you could already apply to EPEL and this is
specifically reason why I don't bother to maintain anything in EPEL.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-16 Thread Miroslav Suchý

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 Desktop.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Orion Poplawski


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 hard to avoid.  This is how most mobile operating systems
function.


iOS prompts you for the yearly updates, and it can be avoided if you
really want.

macOS requires you to specifically choose the yearly update, though
they may have changed with Mojave.

Not sure about Android, but the fact that Google has had to twist
things into a knot to try and get updates out to users indicates that
upgrades to Android aren't being pushed out for the most part.

Windows is the only one forcing upgrades, and it is perhaps one of
the
reasons that hardware vendors are showing more interest in Linux as
people are now more willing to consider anything other than Windows.

Really, the only place where forced upgrades are happening, are
accepted, and seem to actually work are on the application side and
that is because, demonstrated by the web browsers, frequent updates
can be done unobtrusively and reliably.


And with the named examples are you gonna get any support and updates
if you decide to hold off an upgrade to a newer OS? I doubt.
I can certainly hold off upgrade to Android 9 on my phone, but that
doesn't mean I'm gonna get any further updates for Android 8 from the
phone vendor.
There is a huuuge difference between "not forcing upgrades" and
"providing supported and secure way to stay on the current release".

Jiri


For macOS, Apple tends to support the most recent 3 releases with 
security updates as shown in https://support.apple.com/en-us/HT201222


However for iOS it does seem to pretty much be a linear stream of updates.

--
Orion Poplawski
Manager of NWRA Technical Systems  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Eduard Lucena

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, but
actually my concern is in how to avoid the comparison, or being called
copycats, or put in doubt both originality and innovation. I know is
probably too early, but give it a thought from the point of view of the
marketing: How we can advertise a product that others have?

Br,

El jue., 15 nov. 2018 a las 21:46, Jason Tibbitts ()
escribió:

> > "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 of the developers here don't remember it.  I am
> pretty sure you were around, though, so I do hope you have some
> recollection of it.  Put simply, Fedora has had this discussion before.
> A number of times.  Going back to FC1 and what the release cycle would
> look like.  At one point it was basically an endless thread that lasted
> the better part of a year.
>
> For the life of me I simply can't remember the various proposals called
> their releases, though.
>
> One example of what I'm talking about is
>
> https://kanarip.fedorapeople.org/Fedora%20Extended%20Lifecycle%20Support%20-%20The%20why,%20the%20what,%20the%20how%20and%20the%20who.pdf
> but that came after I stopped paying attention to this kind of thing.
>
> In the end the discussions I recall seemed to come down to a few basic
> things.
>
> 1) A lot of people would love to consume such a release.
>
> 2) Not nearly as many actual maintainers would want to do so.
>
> 3) At minimum, we need a kernel.  Which means we need a kernel team.  I
>doubt the current kernel team would be any more enthusiastic about
>either backporting everything, maintaining packages of the extended
>lifetime kernel packages (assuming those even line up with the
>release schedule) or pushing the current kernel back to the
>equivalent of... Fedora 25 or so.
>
> 4) Someone has to do release engineering.  Even in the earlier days this
>was seen as something that wasn't going to happen.
>
> 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 when we had per-branch ACLs.  But that never happened,
> and as there was no effort to actually compose updates for those
> releases, it doesn't matter much anyway.
>
> And now we're bigger, and there are more big systems that would need
> maintenance.  Oh, and we have a security team now; they'd have to deal
> with issues in those old releases.  And more big package sets like
> Python and Node and Go and whatever, some of which amount to a larger
> number of packages than made up the entirety of one of the old Fedora
> releases.  Hello, Python SIG?  Good luck finally getting rid of
> python2.  You get two more years of support backporting security fixes
> and you don't even get paid for it.
>
> 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 releases that can never evolve but which
> still hold back progress in Rawhide is just too much.
>
> Really, this is what our downstream distributions RHEL and CentOS are
> for.  That was the answer then and I don't see why it doesn't still
> apply.
>
> 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
> lifecycle that also gets all the new stuff.  That's seems like a
> contradiction in terms.
>
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


-- 
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread mcatanzaro

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 tickbox, they don't even look at 
us

seriously. I'd love to change these things. To do that, we need
something that lasts for 36-48 months.


"Canonical Extends Ubuntu 18.04 LTS Linux Support to 10 Years"

https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18.04-lts-linux-support-to-10-years.html

I just don't see how we're going to be able to compete with that, not 
unless our Fedora LTS is just CentOS with different branding.


Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 fedora), but trying to introduce
>"fedora LTS", basically as a competitor to CentOS - won't help.

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 hardware
releases.

If you are a hardware vendor would you want to be releasing a laptop
running CentOS 7.x today, with its outdated versions of much of the
software (that is a value to the enterprise server market, but less so
consumer)?

>Additionally, fedora explicitly targets a rather specific audience
>("developers and makers of all kinds"). Trying to "grow" fedora by
>making it less appealing to its current core audience (which most of
>the proposals I read in this thread would seem to do), seems
>misguided.

But is Fedora targetting that audience, and if so is it doing it
sucessfully?  An awful lot of OSS seems to be developed on Ubuntu, and
thus is only supported on Ubuntu by the developers with Fedora as an
afterthought if at all.

I suspect the reality is that developers today aren't looking for a
"bleeding edge" system like Fedora but rather a system that offers a
compromise between the fast releases of Fedora and the glacial
releases of Red Hat, something that has decent current hardware
support and a reasonably up to date desktop environment - in other
words what these hardware vendors want.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Jason Tibbitts

> "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 of the developers here don't remember it. I am
pretty sure you were around, though, so I do hope you have some
recollection of it. Put simply, Fedora has had this discussion before.
A number of times. Going back to FC1 and what the release cycle would
look like. At one point it was basically an endless thread that lasted
the better part of a year.

For the life of me I simply can't remember the various proposals called
their releases, though.

One example of what I'm talking about is
https://kanarip.fedorapeople.org/Fedora%20Extended%20Lifecycle%20Support%20-%20The%20why,%20the%20what,%20the%20how%20and%20the%20who.pdf
but that came after I stopped paying attention to this kind of thing.

In the end the discussions I recall seemed to come down to a few basic
things.

1) A lot of people would love to consume such a release.

2) Not nearly as many actual maintainers would want to do so.

3) At minimum, we need a kernel. Which means we need a kernel team. I
doubt the current kernel team would be any more enthusiastic about
either backporting everything, maintaining packages of the extended
lifetime kernel packages (assuming those even line up with the
release schedule) or pushing the current kernel back to the
equivalent of... Fedora 25 or so.

4) Someone has to do release engineering. Even in the earlier days this
was seen as something that wasn't going to happen.

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 when we had per-branch ACLs. But that never happened,
and as there was no effort to actually compose updates for those
releases, it doesn't matter much anyway.

And now we're bigger, and there are more big systems that would need
maintenance. Oh, and we have a security team now; they'd have to deal
with issues in those old releases. And more big package sets like
Python and Node and Go and whatever, some of which amount to a larger
number of packages than made up the entirety of one of the old Fedora
releases. Hello, Python SIG? Good luck finally getting rid of
python2. You get two more years of support backporting security fixes
and you don't even get paid for it.

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 releases that can never evolve but which
still hold back progress in Rawhide is just too much.

Really, this is what our downstream distributions RHEL and CentOS are
for. That was the answer then and I don't see why it doesn't still
apply.

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
lifecycle that also gets all the new stuff. That's seems like a
contradiction in terms.

- J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Fabio Valentini

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 latest and greatest. LTS will be there for the rest.
> > And the rolling release version can also serve as a stream of apps for
> > LTS releases. We can build the latest Firefox with the latest stable
> > Fedora bits and provide it on LTS releases as a flatpak. A single build
> > for all releases. The model may actually even be easier for
> > maintainers.
>
> I think the very, very high fast rate I'm seeing in the mirror stats (see
> https://twitter.com/mattdm/status/1063058469903839232) recently supports the
> idea of a rolling release to cater to a lot of our audience. I wouldn't
> necessarily have said that three years ago -- look at the upgrade curve for
> f23 at the left side of the graph.
>

I'd argue that the fast upgrade rate to fedora 29 indicates that we -
as a distro - are doing things right, and make upgrades pain- and
fearless (which is what matters). There will always be people who
don't care to upgrade. The only solution I see for this situation is
something like Silverblue with automatic updates and upgrades on
reboot.

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 fedora), but trying to introduce
"fedora LTS", basically as a competitor to CentOS - won't help.

Additionally, fedora explicitly targets a rather specific audience
("developers and makers of all kinds"). Trying to "grow" fedora by
making it less appealing to its current core audience (which most of
the proposals I read in this thread would seem to do), seems
misguided.

Just my 2¢.
Fabio

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 inputs for package builds.

Although, arguably, what constitutes a "pristine source" has changed.
Release tarballs are often an afterthought -- or something generated
automatically by GitHub -- while the tagged git tree is what the upstream
project themselves consideres to be the true authoritative source.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 rolling release version can also serve as a stream of apps for
> LTS releases. We can build the latest Firefox with the latest stable
> Fedora bits and provide it on LTS releases as a flatpak. A single build
> for all releases. The model may actually even be easier for
> maintainers.

I think the very, very high fast rate I'm seeing in the mirror stats (see
https://twitter.com/mattdm/status/1063058469903839232) recently supports the
idea of a rolling release to cater to a lot of our audience. I wouldn't
necessarily have said that three years ago -- look at the upgrade curve for
f23 at the left side of the graph.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 something along the lines of "Fedora LTS"?

It's definitely a tool we have in the box, at least.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Ken Dreyer

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 equally lost.
And it says it "is no longer under active development", so I'm not
sure what the status is.

> rpmdistro-gitoverlay *replaces* koji, it isn't something you can use
> on a "traditional package".

Thanks, this was one of the missing pieces for me :) It would help to
expand this out in that document.

> Anyways, it's pretty simple, rpmdistro-gitoverlay does a recursive
> git mirror in to src/ - and recursive here includes submodules, for
> exactly the reason you raised.  A number of important real-world
> modules use them (including ostree/rpm-ostree).

I see, so it's dynamically re-writing the .gitmodules file(s) on each build?

We had something like this in Ceph,
https://github.com/ceph/autobuild-ceph/blob/master/use-mirror.sh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Japheth Cleaver


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 the proposal, whatever 
it be, is great and everyone  agrees its great, the seriousness will 
be automatic.  Fedora has a long history of catering to some niche 
ideals that parts of our community are dead against.  It's awesome 
that Fedora is so flexible, but if we're going to fiddle with the 
release model, lets find something we *all* get behind and be happier 
with for the next 15 years, however radical it might look like right now.


This becomes even more important when one takes into account Fedora's 
position as the defacto head of the overall Red Hat -based distro 
community, notwithstanding the Penrose Triangle presentiation... 
EL-rebuild users (CentOS and SL) being on the far side of a 
mostly-opaque hardening process are doubly removed from meaningful 
input, and if a Fedora LTS of any type (rings, alternating intervals, 
etc) is to address any of those needs, all RH-ecosystem users probably 
have input worth soliciting.


I would submit that "Fedora" deciding an LTS policy might beg the 
question. Maybe the answer is there being a stable/LTS upstream that 
"Fedora" can itself (as one among peers) derive and override from, 
Debian->Ubuntu style.


-jc

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Florian Weimer

* 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
>> multiple branches without encountering mandatory conflicts.
>>
>> There is no technical reason why the payload in an SRPMs cannot contain
>> the full exploded upstream source tree, with an RPM spec file in the
>> root.
>
> 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 capture the entire "source" like I get
> with an upstream release tarball.

You wouldn't have to actually merge the upstream history.  You can still
merge against tarball contents or other kinds of imports.

What is needed is some form of branch contents tracking, though.  But we
struggle with this at least for Red Hat Enterprise Linux in the current
model, too, because each time we rebase from Fedora, we use some
downstream customizations—some unnecessary, some less so.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Colin Walters

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 might do this for a traditional
> package.

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.

rpmdistro-gitoverlay *replaces* koji, it isn't something you can use
on a "traditional package".

Anyways, it's pretty simple, rpmdistro-gitoverlay does a recursive
git mirror in to src/ - and recursive here includes submodules, for
exactly the reason you raised.  A number of important real-world
modules use them (including ostree/rpm-ostree).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Jiri Eischmann

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 doing
> > > rebases for everything I maintain rather than trying to backport
> > > anything. Admittedly this would somewhat negate the supposed
> > > benefit
> > > of having stable long life releases, but its either that or the
> > > releases bitrot accumulating more & more bugs & security flaws.
> > 
> > I agree, this would lead to too much workload on the maintainers if
> > we
> > just add a new long-lived branch. There's already rawhide, F29,
> > F28, F27
> > which is already quite a lot of branches to maintain.
> > 
> > However, I think this could work if we change how long we maintain
> > the
> > non-LTS branches.
> > 
> > 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 same number of branches as now, just that one is LTS.
> > 
> 
> That's basically the Ubuntu model. They do 9 months for regular
> releases, and 5 years (originally 3 years) for LTS releases.
> 
> However, what could also work would be something along the lines of
> openSUSE Evergreen[1] model (prior to the shift to openSUSE Leap +
> Tumbleweed), where the community decides on a version to stabilize
> and
> maintain for bugfixes for an extended period of time. If we wanted to
> talk about having extended lifecycles, I think this would be a
> workable model. This would be similar to the original Fedora Legacy
> project (if anyone remembers that!).

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 rolling release version can also serve as a stream of apps for
LTS releases. We can build the latest Firefox with the latest stable
Fedora bits and provide it on LTS releases as a flatpak. A single build
for all releases. The model may actually even be easier for
maintainers.

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Jiri Eischmann

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 most mobile operating systems
> > function. 
> 
> iOS prompts you for the yearly updates, and it can be avoided if you
> really want.
> 
> macOS requires you to specifically choose the yearly update, though
> they may have changed with Mojave.
> 
> Not sure about Android, but the fact that Google has had to twist
> things into a knot to try and get updates out to users indicates that
> upgrades to Android aren't being pushed out for the most part.
> 
> Windows is the only one forcing upgrades, and it is perhaps one of
> the
> reasons that hardware vendors are showing more interest in Linux as
> people are now more willing to consider anything other than Windows.
> 
> Really, the only place where forced upgrades are happening, are
> accepted, and seem to actually work are on the application side and
> that is because, demonstrated by the web browsers, frequent updates
> can be done unobtrusively and reliably.

And with the named examples are you gonna get any support and updates
if you decide to hold off an upgrade to a newer OS? I doubt.
I can certainly hold off upgrade to Android 9 on my phone, but that
doesn't mean I'm gonna get any further updates for Android 8 from the
phone vendor.
There is a huuuge difference between "not forcing upgrades" and
"providing supported and secure way to stay on the current release".

Jiri 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Ken Dreyer

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
> https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md

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 might do this for a traditional
package.

- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Greg Bailey


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 about how we might address
some of the users and use cases we're missing out on.


I'm mostly a CentOS user with various 3rd party repositories like EPEL 
and IUS configured for things like newer python, etc.  I'm an occasional 
Fedora user (and packager for half a dozen or so packages).  I've 
considered switching to a Fedora desktop but have yet to take the step 
of reloading my primary workstation with Fedora (since I can't directly 
upgrade from CentOS).



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 balance this with getting people new stuff
fast as well?


I saw the announcement for RHEL 8 beta and downloaded the ISO to see 
what's on it.  It looks like it supports Application Streams, which I 
assume is the same thing or related to Fedora modules?  The RHEL 8 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 something along the lines of "Fedora LTS"?


-Greg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Samuel Rakitničan

> 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
> maintainers are. Now imagine how well we would support F-4 (36 months)
> or F-6 (48 months). I'd guess "not at all".
> 
> I don't see this going anywhere without a lot of new maintainers.
> 
> Zbyszek

How about keeping the number of supported releases the same, just change the 
support window for them. For example have one release that is supported for 6 
months, and then have one release that is supported for longer.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Colin Walters



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 repos and sha1s that don't disappear
> > over time. It doesn't really capture the entire "source" like I get
> > with an upstream release tarball.
> 
> I think to do this we would need to have our own, controlled local git
> mirror.

This is step 2 in
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/reworking-fedora-releng.md
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread John Florian


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 
release we want to showcase. Why is it necessary to have a 
Fedora 30 to be able to realize this update. What is so 
difficult about providing this for Fedora 29. I'm trying to 
understand why these upstream updates can't be decoupled from the 
Fedora release schedule.


It's all a matter of QA. The freeze, the blocker bug process, and the 
quantity of users who test the stuff for us. We'd need major changes 
to our updates process to account for this in a mid-release update. 
The blocker bugs process would be needed, for a single bodhi update. 
At leas t a month or two of testing (during which new versions of the 
update will be released, so the update will have to go through some 
iterations). And lots and lots of testers: currently we get those for 
free because tons of people help us test beta releases of Fedora, I 
think far more than run updates-testing.
I think if we did this right, however it looks, multiple testing repos, 
rings, modularity, whatever... we might easily attract more testers than 
we have now.  I think this whole problem can usually be distilled down 
to, "I want LTS for everything because I hate breakage and I hate tech 
treadmills because I've already got too much to do.  Except for Foo, the 
version every other distro has is too old and I'm willing to get dirty 
if necessary because Foo is what matters to me."


This is all doable and solvable. Not a blocker. But if we don't take 
it seriously and make some big changes in how we release updates, it 
won't go well. Not well at all. So I'd recommend against it, unless 
there is some major benefit available from doing so.


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 the proposal, whatever it be, is 
great and everyone  agrees its great, the seriousness will be 
automatic.  Fedora has a long history of catering to some niche ideals 
that parts of our community are dead against.  It's awesome that Fedora 
is so flexible, but if we're going to fiddle with the release model, 
lets find something we *all* get behind and be happier with for the next 
15 years, however radical it might look like right now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 capture the entire "source" like I get
> with an upstream release tarball.

I think to do this we would need to have our own, controlled local git
mirror.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Jiri Eischmann

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 everyone. Let's talk about how we might
> address
> some of the users and use cases we're missing out on.
> 
> When I talk to people about this, I often get "hey, you should do LTS
> or go to rolling releases.” As I've said before, on the surface
> that's
> a weird thing to say, since the actual user impact of those two
> different things is mostly _opposite_. So, digging in, it often
> really
> means "I don't want the pain and fear of big OS upgrades".
> 
> We've addressed that in several ways: first, making upgrades better.
> (Thanks everyone who has worked on that.) A Fedora release-to-release
> update is normally not much more trouble than you might get some
> random
> Tuesday with a rolling release. Second, we have some things like
> Fedora
> Atomic Host and upcoming Fedora CoreOS and IoT which both implement a
> rolling stream on top of the Fedora release base. And finally,
> there's
> the coming-someday plans for gating Rawhide, making that a better
> proposition for people who really want to live on the edge.
> 
> 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 tickbox, they don't even look at
> us
> seriously. I'd love to change these things. To do that, we need
> something that lasts for 36-48 months.
> 
> 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 balance this with getting people new
> stuff
> fast as well?

We've done a really good job stabilizing Fedora, but based on
observations and conversations with users I think the model has been
getting to its limit in terms of userbase. There are simply too many
deplyoments which require a different kind of stability than the
current Fedora can offer (things may not break, but they still change
and change often). That's why I think LTS is an opportunity for us to
grow.
If we want to have an LTS I think we have to give up something. It'd be
really difficult to do it on the top of the 6-month releases. An idea
I've been entertaining recently is something like this:

- unstable rolling release (Rawhide)
- stable rolling release (basically gated Rawhide with stable versions
of components) - for the early adopters who want the latest and
greatest
- LTS
It would definitely need multiple groups with different treatment:
Ring 1 - kernel+base user space, stability is the highest priority, if
any rebases, then very well tested.
Ring 2 - e.g. desktop environments, rebases allowed, but well tested
and planned, perhaps aligned with some minor releases of Fedora LTS
(.1, .2,...).
Ring 3 - rolling release components, those can be based on the stable
rolling release Fedora and shipped via Flatpak/modules... maintainers
can then only support one version for all releases of Fedora, this can
be a viable mode for most desktop apps.

Jiri
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread Neal Gompa

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 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, from my statistics, there's a lot of 3-year-old (and older!)
> > > Fedora out on the web today. But that aside, let's say we wanted to do it
> > > right *and* still keep the distro exciting and fun to hack on.
> > >
> > > What person-power and procedures would we need to add?
> >
> > 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 conflicts.
> >
> > There is no technical reason why the payload in an SRPMs cannot contain
> > the full exploded upstream source tree, with an RPM spec file in the
> > root.
>
> What do  you mean that the fully exploded upstream source tree? Is it
> the entire 'git' repository with all branches in it or just a tar ball
> of a particular branch?
>
> [The git repository can grow to hundreds of gigabytes which would make
> every update a huge SRPM file for a small change.]
>

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 inputs for package builds.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 yearly updates, and it can be avoided if you
really want.

macOS requires you to specifically choose the yearly update, though
they may have changed with Mojave.

Not sure about Android, but the fact that Google has had to twist
things into a knot to try and get updates out to users indicates that
upgrades to Android aren't being pushed out for the most part.

Windows is the only one forcing upgrades, and it is perhaps one of the
reasons that hardware vendors are showing more interest in Linux as
people are now more willing to consider anything other than Windows.

Really, the only place where forced upgrades are happening, are
accepted, and seem to actually work are on the application side and
that is because, demonstrated by the web browsers, frequent updates
can be done unobtrusively and reliably.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

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 want people to buy
>support contracts for 3-5 years where the number of problems needed in
>year 3-5 are none. [This means that they want to have Fedora N for 3-6
>months before their laptops ship with it. So you ship them a frozen
>preload before you release to public. They also want any shipped to
>'last' for the warranty cycle because trying to deal with update
>questions when N eol's in the middle costs them a lot.]

I think this is the key that needs to be thought out before figuring
out if / how Fedora can meet that need.

Does this mean they need / want a new Fedora LTS every year, 2 years,
3 years?  If they want 3 to 5 years of support, and the hardware is
released 2 years in to a LTS release, does that extend it to a 7 year
LTS?

Is that really a viable Linux desktop market given how the desktops
currently develop?

Perhaps this is a discussion that needs to be expanded from just
Fedora to also include KDE and Gnome?

>This matches the majority of laptop buyers whether they are developers
>or home users. They cycle a laptop 4 to 5 years with 7-8 looking to be
>the new average. They also don't update their OS unless it does it
>auto-magically for them.  This is where the majority of profits for
>laptop sales come from so the manufacturers aim to please this segment
>most. There isn't a large margin on laptop sales anymore

I suspect the big problem is that it requires a total rethink of what
a distribution is and how it is created.

Because if you look at Windows, which is what this idea is really
talking about, yes the users are quite happy to never upgrade the OS
but that is to a large extent based on the fact that 3 or 4 years
after purchase they can still go and buy/download the latest
application and it will install and run.

That concept doesn't work very well currently with the lock step march
of an entire distro (which is essentially the OS and applications) to
newer, incompatible versions every 6 months.

Really, to support what the hardware vendors really want (even if they
aren't clearly saying it) involves moving anything non-core-os away
from the current packaging system (so for Fedora RPMS) and to some
sort of container that will work regardless of what the underlying
system is providing.

You have to be able to at the very least keep updating Firefox (as a
prime example) for that 5 years without forcing the upgrade of half
the os in the process.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities

2018-11-15 Thread 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
> multiple branches without encountering mandatory conflicts.
>
> There is no technical reason why the payload in an SRPMs cannot contain
> the full exploded upstream source tree, with an RPM spec file in the
> root.

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 capture the entire "source" like I get
with an upstream release tarball.

- Ken
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Lifecycles: imagine longer-term possibilities