Re: Fedora.next in 2014 -- Big Picture and Themes
On Wed, Jan 29, 2014 at 2:57 PM, Matthew Miller wrote: > > This doesn't mean I'm against doing Big Exciting New Things in general > > or Fedora.next in particular, but I do want to stand up for the value of > > just keeping your head down (hah, I know, Adam, practice what you > > preach) and doing good, dull engineering work. With your pocket > > protector firmly in place. > > This is all very convincing. But you also sent me a convincing message the > other week about Fedora's place on the innovation curve and, basically, the > difficulty of doing all that good dull work while being innovative. Stop > convincing me in different directions -- my head will fall off! > > Or, in seriousness, because I don't think they're *necessarily* in direct > conflict, what do you think we should do about all of the above? Our > mission > and branding, including our foundations, tend to steer away from the dull > and towards new shiny. In fact, whenever we do something that could be > characterized as head-down plodding forward progress instead of a bold > leap, > we hear *quite a bit* of sarcasm about the four foundations in the online > chatter. > So I recently had to carefully reread the foundations, and I was surprised to find the "First" foundation is not nearly as focused on timing as is generally assumed: > we provide the latest _in stable and robust_, useful, and powerful free software in our Fedora distribution. (emphasis mine) So, "new shiny"? Yes, please. "Bold leap"? Uncertain. "Bleeding edge"? Definitely not. (It could be argued that when the written from or the Foundations and their common understanding differs, it's the common understanding that is correct. I suppose the right way to go about it would be to dig out the archives of the discussions and Board minutes from that time to accurately understand the consensus of _that_ time, as opposed to the _current_ common understanding, which is, I think, primarily formed by the above-referenced sarcasm.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 7:06 PM, Tom Hughes wrote: > The roles stuff? I have, though I'm not sure if I just failing to get it > or something but I don't see anything there that looks especially useful to > a server administrator. > > Other than pulling in a group of packages it's not really clear to me what > a role does for me, If you are _already_ administering an existing setup, or have a custom automated deployment of a service, probably not much. When you need to deploy a new service, the roles should save you work because a lot of the "custom" work is really common to most deployments and shouldn't need to be custom; or if you were new to Linux system administration, the roles should simplify everything (but not make it impossible to deal with the details). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2014 12:06 PM, Björn Persson wrote: > Matthew Miller wrote: >> Our mission and branding, including our foundations, tend to >> steer away from the dull and towards new shiny. In fact, whenever >> we do something that could be characterized as head-down plodding >> forward progress instead of a bold leap, we hear *quite a bit* of >> sarcasm about the four foundations in the online chatter. > > Might it be time to add a fifth foundation, one of ferro-concrete, > to provide a firm footing? > An astounding array and assortment of alliteration alluding to our aspirations. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLpP4MACgkQeiVVYja6o6PIsQCfc3sScSaLgZmRzrw+jljUiYrj 8LcAn0EzaQz15jPET3d+bdKMEXUYgBFu =PPo/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Matthew Miller wrote: >Our mission and branding, including our foundations, tend to >steer away from the dull and towards new shiny. In fact, whenever we >do something that could be characterized as head-down plodding forward >progress instead of a bold leap, we hear *quite a bit* of sarcasm >about the four foundations in the online chatter. Might it be time to add a fifth foundation, one of ferro-concrete, to provide a firm footing? Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Wed, 2014-01-29 at 08:57 -0500, Matthew Miller wrote: > On Tue, Jan 28, 2014 at 06:15:49PM -0800, Adam Williamson wrote: > > Just to wax philosophical for a minute: I think there's a lot of value > > in building boring stuff that works well, and I might be weird, but I > > [snip eloquent defense of the virtues of boring basic distro work] > > > This doesn't mean I'm against doing Big Exciting New Things in general > > or Fedora.next in particular, but I do want to stand up for the value of > > just keeping your head down (hah, I know, Adam, practice what you > > preach) and doing good, dull engineering work. With your pocket > > protector firmly in place. > > This is all very convincing. But you also sent me a convincing message the > other week about Fedora's place on the innovation curve and, basically, the > difficulty of doing all that good dull work while being innovative. Stop > convincing me in different directions -- my head will fall off! I have a degree in history. I can argue any side of any issue at the drop of a hat, prior research unnecessary. ;) > Or, in seriousness, because I don't think they're *necessarily* in direct > conflict, Seriously, this is what I think. And in fact, they work together: it's actually quite fascinating that in Fedora we have a place where we can do fairly radical stuff to a 'boring, stable' platform like the OS. That's the strength of the distribution model, I guess: as we've noted before, Fedora often blazes the trail for big hairy changes to things that might otherwise be 'too important to touch'. > what do you think we should do about all of the above? Our mission > and branding, including our foundations, tend to steer away from the dull > and towards new shiny. In fact, whenever we do something that could be > characterized as head-down plodding forward progress instead of a bold leap, > we hear *quite a bit* of sarcasm about the four foundations in the online > chatter. > > So, should we look at reconciling that in some way? Part of *my* idea for > Fedora.next was that the base circle could focus more on this careful and > non-thrilling engineering work while the outer rings could do the > big-exciting things at the same time. (Or even have *some* parts of the > outer rings working on big-exciting, while other parts work on _even more > solid_.) > > *goes and gets coffee. not able to quite express what I mean. hope you > understand anyway* I do entirely, and actually I think we may be rather on the same wavelength for once =) I'm not good at marketing-type stuff, though, so I'm not sure I have an answer for you. I know I have this basic idea that we've outlined above, but that's a tricky message to communicate to people, and I'm not your guy for creative messaging stuff. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 01/29/2014 02:57 PM, Matthew Miller wrote: On Tue, Jan 28, 2014 at 06:15:49PM -0800, Adam Williamson wrote: Just to wax philosophical for a minute: I think there's a lot of value in building boring stuff that works well, and I might be weird, but I [snip eloquent defense of the virtues of boring basic distro work] This doesn't mean I'm against doing Big Exciting New Things in general or Fedora.next in particular, but I do want to stand up for the value of just keeping your head down (hah, I know, Adam, practice what you preach) and doing good, dull engineering work. With your pocket protector firmly in place. This is all very convincing. But you also sent me a convincing message the other week about Fedora's place on the innovation curve and, basically, the difficulty of doing all that good dull work while being innovative. Stop convincing me in different directions -- my head will fall off! Or, in seriousness, because I don't think they're *necessarily* in direct conflict, what do you think we should do about all of the above? Our mission and branding, including our foundations, tend to steer away from the dull and towards new shiny. In fact, whenever we do something that could be characterized as head-down plodding forward progress instead of a bold leap, we hear *quite a bit* of sarcasm about the four foundations in the online chatter. So, should we look at reconciling that in some way? Part of *my* idea for Fedora.next was that the base circle could focus more on this careful and non-thrilling engineering work while the outer rings could do the big-exciting things at the same time. (Or even have *some* parts of the outer rings working on big-exciting, while other parts work on _even more solid_.) *goes and gets coffee. not able to quite express what I mean. hope you understand anyway* Now I'm confused too. Env and Stack WG should do new and cool things, but most of us are doing the boring work (databases and languages maintenance). I believe we can do the boring stuff even in Fedora.next. Cool stuff will be somewhere above the boring. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 06:15:49PM -0800, Adam Williamson wrote: > Just to wax philosophical for a minute: I think there's a lot of value > in building boring stuff that works well, and I might be weird, but I [snip eloquent defense of the virtues of boring basic distro work] > This doesn't mean I'm against doing Big Exciting New Things in general > or Fedora.next in particular, but I do want to stand up for the value of > just keeping your head down (hah, I know, Adam, practice what you > preach) and doing good, dull engineering work. With your pocket > protector firmly in place. This is all very convincing. But you also sent me a convincing message the other week about Fedora's place on the innovation curve and, basically, the difficulty of doing all that good dull work while being innovative. Stop convincing me in different directions -- my head will fall off! Or, in seriousness, because I don't think they're *necessarily* in direct conflict, what do you think we should do about all of the above? Our mission and branding, including our foundations, tend to steer away from the dull and towards new shiny. In fact, whenever we do something that could be characterized as head-down plodding forward progress instead of a bold leap, we hear *quite a bit* of sarcasm about the four foundations in the online chatter. So, should we look at reconciling that in some way? Part of *my* idea for Fedora.next was that the base circle could focus more on this careful and non-thrilling engineering work while the outer rings could do the big-exciting things at the same time. (Or even have *some* parts of the outer rings working on big-exciting, while other parts work on _even more solid_.) *goes and gets coffee. not able to quite express what I mean. hope you understand anyway* -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, 2014-01-28 at 20:34 +0100, Robert M. Albrecht wrote: > Hi, > > > * Although it's certainly not the only reason, Fedora as _solely_ a hobbyist > >desktop is not ideal for an upstream for RHEL server and cloud products. > > No other system can be reinstalled / upgraded every six months. That > single fact IMHO kills all other use cases. Please stop repeating this argument. Fedora's lifecycle is ~13 months, not six. I have been running four production servers on Fedora for five years, and find this to work perfectly well. Upgrading them takes me a weekend every year. > If I need a stable Fedora-like server, I get CentOS. It's kind of a > Fedora-LTS. > > > * General trend in Linux towards the base distribution being "boring" and > >not mattering. I asked several dozen different people at a gigantic > > Amazon > >conference why everyone was using the distribution they chose instead of > >Fedora, and the answer was almost universally "oh, I don't care; that's > >not really an interesting question because there's nothing important at > >that level". > > All (of the big) distros are mature today. At the early days one chose > his distro by drivers, by installation-tool, by packages, ... > > Nowady every distro has a working installer, has a bazillion packages, > ... they basically all work. There's a huge range of stuff to fix at the distro level. Lately I want to clone myself ten times just to work on all the stuff I see that needs fixing. Just to wax philosophical for a minute: I think there's a lot of value in building boring stuff that works well, and I might be weird, but I wake up every day enthused by the prospect of doing it. The world needs its Lennarts, but it also needs its pocket-protector dorks who spend all day tightening the nuts and bolts on a platform that was "cool" ten years earlier and is now so boring, out of date, stable...and essential. It's not cool to work on a language that's been around and used in production for decades (Python, perl, GCC...), or an operating system installer, or a terminal app, or a text editor people have been using for thirty years. You won't get on Hacker News or get a breathless write-up in Wired. You won't get a massive VC funding round. But it is *important*. If you look at things that have been around forever and ever but are still actively and carefully tended - python, GCC, vim, emacs, apache, mariadb, etc etc etc etc etc etc etc - all the boring, 'stable' bits that you're talking about - and compare them to projects that are marginally maintained or not maintained at all, the difference is huge. And yes, it's much harder to sell the story "we work all day on carefully and painstakingly improving something you've been using for decades that already works pretty well" than the story "we're building something SHINY and NEW!", even if the first thing is vital to the world economy while the second is a lolcat generator. People do not always have their priorities correctly wired, and neither do journalists (rimshot, please!) But perceptions are not reality, and I do think that people *do* perceive the work done on 'boring', 'stable' projects, and differentiate between them. They don't do so as consciously or immediately or clearly as they look at SHINY NEW things, but they do. You see it happening gradually, over time, and usually not as explicit statements, but rather implied in other things. Yeah, we spend a lot of time building the 'boring' nuts and bolts of an operating system, and yeah, operating systems in general have got to the point where they're 'boring', 'stable' things. You can probably pick one blindfolded and be doing productive work on it in a half an hour (a browser and a text editor and you're good to go!), and maybe if you're asked about it straight up, you'll say the same kind of things as I'm replying to here: it's a boring space, there's no real difference between the choices any more, etc etc etc. But I don't think we should rely on that conscious perception. The nuts and bolts of this 'boring' operating system *are* important, and we *are* providing substantial value by working on them, and people *do* perceive that over time, even if they don't necessarily know it. Maybe we don't get our Wired write-up (except when we do something really crazy, or there's a giant political flamewar, or whatever), but that doesn't mean we're not doing good and important work. This doesn't mean I'm against doing Big Exciting New Things in general or Fedora.next in particular, but I do want to stand up for the value of just keeping your head down (hah, I know, Adam, practice what you preach) and doing good, dull engineering work. With your pocket protector firmly in place. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailm
Re: Fedora.next in 2014 -- Big Picture and Themes
On Mon, Jan 27, 2014 at 01:53:56PM +, Ian Malone wrote: > Cool. If I was to take this one step further then, an issue for Fedora > Jam is we were limited in the customisations the could be made for a > spin (e.g. defaulting users into certain groups to allow real time > audio). While there's not enough of the developer base to make it an > official product would there be a way to slot this into that > framework? Yes! Or at least I think so. This isn't worked out yet, but the idea I have is that spins other than the three initial target products will become "secondary products", akin to secondary arches. (If we feel like "secondary" seems too negative, we can come up with another word, but it works with architectures.) We would correspondingly relax the restriction of customizations. (I'm going to post about this in the Spins SIG for discussion.) -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 09:11:08PM -0500, Bill Nottingham wrote: > > I wasn't being dismissive. I have seen no plans to alter the core of > > how Fedora, at a package level, is built. In fact, if I did see a > > proposal that said "we're not going to ship repositories or RPMs" I'd > > be pretty damned upset, and I wouldn't support that. > To be fair, I do recall Matt's original rings proposal discussing a > core, different stacks on top of that, a 'commons' repository of packages, > and things like COPRs on the outside. While it's not proposing moving > away from repositories or RPMs, I did read that proposal as moving > away from the current paradigm of One Big Repo Of Everything in favor > of potentially multiple smaller repos. In that paradigm, things would > change somewhat for users even if they were ignoring the N products. I'm still not completely opposed to this. :) It would include managing relationships (dependencies and conflicts) between the COPRs-like repos as basically higher-level units than packages. That _would_ change the experience -- although they'd still be repositories and still RPMs, at least up until the application container level. The repositories wouldn't necesssarily be completely decoupled -- think of it more as policy separation like free and nonfree in... some other RPM distributions meant to layer on top of Fedora. They work together and can both be enabled at once (and packages from one can depend on packages from the other, but, for example, maybe not the other way around). But until we can really come up with clear reasons for a separation, I'm not pushing for it. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 10:00:25PM +0100, drago01 wrote: > > Right now, the version of Python installed has to be the version that is > > required for code in the base -- yum or dnf at the very least, possibly > > puppet or chef, maybe firewalld or cloud-init. If your code isn't > > Python3-ready when Fedora switches, what will you do? If you don't update, > > your code *will* break. > Isn't that a contradiction to what you said above "everything that > isn't a language runtime" and now > you are talking about python updates. That's an example where the language is very tightly tied into the base. But it's the case in general that all language environments we ship are tied to the set of packages we ship at that time. Occasionally we do compatibility packaging (python3 is actually an example of this), but in general it's pretty painful. This is kind of creaky -- I'll use Puppet as an example: we shipped it largely broken for several releases, because we updated Ruby to a version not supported upstream. And we probably also shipped code that required at least that new version. How do we decide in situations like this? The traditional Fedora approach is to error in favor of going forward. Because "first" is part of Fedora's fundamentals, I don't think we should stop that, but we also could find a way to accommodate. (And that's an example of something _within_ the distribution -- there's no concern at all for user code.) > > It is often the case that upstream code is tightly tied to particular > > versions of the language or language modules. That's the hard problem. And > > what about language modules which aren't yet packaged? Should everyone who > > wants to use Fedora to deploy their application have to go through creating > > RPMs for each? > Yeah I agree that this part needs fixing. Maybe automated packing > helps. We are to much focused on packing > and packages while a lot of that could be automated. You may not get > the "cleanest" spec files that way but > there was some distro created by Arjan I think that does it this way. Yeah, so I think we're on the same page here. > Yeah SCLs are a way to deal with this issue. But is it really > incompatible with how we did Fedora in the past? Traditionally, yes, although there's been some heroic guideline-writing recently. > Don't get me wrong I am not trying to "stop" Fedora.next I am just > trying to understand what toughs lead to it. > It looks like "ok there are problems lets do stuff differently and see > how it works out". I hope we are and can be more intentional than that. Conversations like this one help! -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 01:58:55PM -0700, Stephen John Smoogen wrote: > The biggest things I can see from Fedora.Next is working on solving 1,2,3 > by making it easier and faster to either port or carry your own versions of > the apps you need and making as much of the OS 'metric' as possible so that > it can be forgotten by the meta-os people. Yes to all of that. :) -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, Jan 25, 2014 at 11:20:33AM +0100, Thorsten Leemhuis wrote: > I for one waited (and still wait) for a text that gives a brief > overview; something like a four or five para text which outlines the > consequences and how Fedora will look like in the end. Something easy to > understand; so easy that people can grasp it who are not involved in > Fedora, but know what Linux is. Well, we're still working on that in a smaller sense -- developing a _part_ of that is the current task for the working groups. That will be done in a matter of weeks, and we can put together something that shows some of the specifics. But in a larger sense, there's no description of the end state because we're still figuring it out. We're trying to gather everyone's input and effort to make a coherent community plan. That's the point of this thread in the first place. > Then provide some more text that then goes into the details. But keep it > short and easy to read, too. Most of us have a stressful day and the > attention span is quite short. So even the longer stuff should not take > more than 10 minutes to read (or provide something to put 12 more hours > into a day, then the text can be a bit longer ;-) ). So eventually, yes, this would be a great thing to have. But right now, we have people on the one hand concerned that there are no specifics and on the other hand worried that there's some sort of sudden sealed deal. But really, the reason that there are no specifics is because it's simply still being worked on. We _have_ decided to go in a certain direction with the three target products and the env & stacks and base design working groups, but we will take the next steps as we get to them. Eventually, that _will_ lead to a place where the text you're looking for can exist. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 9:06 PM, Matthew Miller wrote: > On Tue, Jan 28, 2014 at 07:04:52PM +0100, drago01 wrote: >> This is again "hand wavy"(sorry for overusing this term). I can >> already have multiple language stacks >> for instance python, java, ruby and php on fedora (or pretty much any >> other distribution) just fine today. >> And I don't expect it to break when the "base layer" (whatever that >> means ... kernel? glibc? systemd?) changes. > > Everything that isn't the language runtime, basically. I'm answering this > second question first, because it helps answer the first part. > > Right now, the version of Python installed has to be the version that is > required for code in the base -- yum or dnf at the very least, possibly > puppet or chef, maybe firewalld or cloud-init. If your code isn't > Python3-ready when Fedora switches, what will you do? If you don't update, > your code *will* break. Isn't that a contradiction to what you said above "everything that isn't a language runtime" and now you are talking about python updates. OK in that case sure if you update the language runtime itself to a version that is not compatible with the deployed applications you have a problem. But the "base" itself has nothing to do with it (ignoring some odd fringe cases). > It is often the case that upstream code is tightly tied to particular > versions of the language or language modules. That's the hard problem. And > what about language modules which aren't yet packaged? Should everyone who > wants to use Fedora to deploy their application have to go through creating > RPMs for each? Yeah I agree that this part needs fixing. Maybe automated packing helps. We are to much focused on packing and packages while a lot of that could be automated. You may not get the "cleanest" spec files that way but there was some distro created by Arjan I think that does it this way. > SCLs are one attempt at this, and despite some issues seem to be fairly well > received. (See for example http://developerweek.com/awards/) There are > probably even better solutions out there. One thing I'm interested in > experimenting with is Docker images built with packages from SCLs, but > rebuilt so that the binary RPMS aren't SCL-enabled (and therefore put ruby > at /usr/bin/ruby regardless of the version). Another idea is to work with > the upstream packaging system so that when you gem install, an rpm is > actually transparently built locally from the rubygems.org packages. There > are certainly more ideas -- the Environments and Stacks Working Group is > working on this. Yeah SCLs are a way to deal with this issue. But is it really incompatible with how we did Fedora in the past? Don't get me wrong I am not trying to "stop" Fedora.next I am just trying to understand what toughs lead to it. It looks like "ok there are problems lets do stuff differently and see how it works out". -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 28 January 2014 13:38, Matthew Miller wrote: > On Tue, Jan 28, 2014 at 08:34:23PM +0100, Robert M. Albrecht wrote: > > >* Although it's certainly not the only reason, Fedora as _solely_ a > > > hobbyist desktop is not ideal for an upstream for RHEL server and > > > cloud products. > > No other system can be reinstalled / upgraded every six months. That > > single fact IMHO kills all other use cases. > > Fedora actually has a 13-month lifecycle, which is still fast but less > dramatic than that. And although that makes it *challenging*, it doesn't > preclude real use in non-desktop cases. I know because I've seen people in > real life doing all sorts of things, from high-performance computing to > running hosting services to high-frequency stock trading. > > Well on paper it has a 13 month lifecycle, but the perceptions are a lot shorter due to three factors: 1) If you have a complicated stack for applications then you are going to need 3-6 months to port, test and verify that it works with the latest perl, python, ruby, java, and haskell you ended up using to get your job done. 2) If you are really a part of the community, it feels like a 3 month life cycle because that is the time between X and X+1-alpha, and the constant and needed drumbeat that you test, use and promote X+1alpha so that it can be ready in 3 months time. 3) When you end up being on X-1 release, you quickly find your bugs being answered that you need to either move to X or X+1-beta to see if it is fixed there because the package maintainer only has so much attention to spend on things. The biggest things I can see from Fedora.Next is working on solving 1,2,3 by making it easier and faster to either port or carry your own versions of the apps you need and making as much of the OS 'metric' as possible so that it can be forgotten by the meta-os people. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, Jan 25, 2014 at 12:16:40PM +0100, Thorsten Leemhuis wrote: > > I will be giving a talk on Sunday, February 9th in at DevConf in Brno, > > CZ, and I'll post slides from that (probably here as text as well), and > > I assume there will be video. > That's great (I'll be there; Fosdem as well), but please allow me a side > note here: Videos and IRC logs are a great resource if you really care > about something and want to know all the details. But the ratio for > "time spend watching/reading vs. information gathered" is often quite > bad. That's why written, easy to read summaries are important. And I > think we got too few of them from Flock last year, which is one of the > reason why I had/have problems to fully understand Fedora.next. Oh, absolutely. The transcripts from the Flock talks that had them (see https://lwn.net/Articles/563213/) were awesome, but summaries are even better. I'll try to use the slides I have yet to put together as the basis of a post here (and maybe a wiki page update). > Agreed. For example, "+1/like"-Buttons for a mailing list would be good > afaics, to get a rough impression how people think (just wondering: will > hyperkitty or something from that camp of developers have this?). But > that's just one thing that springs to my mind and a different topic. FTR, yes, that's a key feature of hyperkitty. > To be honest: only a little bit. Fedora.next simply is so big (I'm > wondering if too much is cramped into it) and still vague in some parts > that I remain careful. But that's not unusual, I'm quite sceptic all the > time and more of a pessimist ;-) The big parts don't need to be done all at once. (Some of them might not need to be done at all.) Careful is good. > And for now I have something else I need to take care of first: > preparing my devconf talk :D Yes -- see you there! -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 08:34:23PM +0100, Robert M. Albrecht wrote: > >* Although it's certainly not the only reason, Fedora as _solely_ a > > hobbyist desktop is not ideal for an upstream for RHEL server and > > cloud products. > No other system can be reinstalled / upgraded every six months. That > single fact IMHO kills all other use cases. Fedora actually has a 13-month lifecycle, which is still fast but less dramatic than that. And although that makes it *challenging*, it doesn't preclude real use in non-desktop cases. I know because I've seen people in real life doing all sorts of things, from high-performance computing to running hosting services to high-frequency stock trading. > If I need a stable Fedora-like server, I get CentOS. It's kind of a > Fedora-LTS. Sure -- fine for some versions of what stable means. I don't think Fedora and CentOS directly compete -- they complement. > The real innovation is happening on the desktop: power management, > Wayland, Mesa, wifi/3g/4g, color-management, pulseaudio, ... I don't think I want to get into an argument about where real innovation is or isn't happening, but it's definitely happening in non-desktop areas as well. > I don't know anything about the statistics on Fedora contributors > and their jobs. But if there are lot of hobbyists, students, ... > these people are not able / interessted in large enterprise stuff > like OpenStack, ... they work on devel-tools like languages and > desktop-stuff, that's what they are using. We have a mix. But hobbyists and students and non-enterprise users are absolutely critical to who we are, regardless of the statistics. The desktop component isn't thrown out in Fedora.next. The Workstation WG PRD proposal specifically targets students, independent developers, small-company developers, and enterprise developers, but also has a section about welcoming other user segments. > If Fedora want's more innovation in those topics, Fedora must > possibly reallign the devel-community. Most enterprise-project like > libvirt, freeipa, Spacewalk, ... are done by Redhat-people ? Or am I > totaly mistaken there. We've got a lot of that, for sure, but we also have a lot of enterprise packages maintained by non-Red-Hatters. I'm not quite sure what you mean by "realign the devel community" -- can you elaborate? -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 07:04:52PM +0100, drago01 wrote: > This is again "hand wavy"(sorry for overusing this term). I can > already have multiple language stacks > for instance python, java, ruby and php on fedora (or pretty much any > other distribution) just fine today. > And I don't expect it to break when the "base layer" (whatever that > means ... kernel? glibc? systemd?) changes. Everything that isn't the language runtime, basically. I'm answering this second question first, because it helps answer the first part. Right now, the version of Python installed has to be the version that is required for code in the base -- yum or dnf at the very least, possibly puppet or chef, maybe firewalld or cloud-init. If your code isn't Python3-ready when Fedora switches, what will you do? If you don't update, your code *will* break. It is often the case that upstream code is tightly tied to particular versions of the language or language modules. That's the hard problem. And what about language modules which aren't yet packaged? Should everyone who wants to use Fedora to deploy their application have to go through creating RPMs for each? The situation is particularly bad with Ruby. We don't have popular system lifetime management software Foreman (http://theforeman.org/) packaged in Fedora because of dependency hell. (And that just got worse when we went to Ruby 4.) Now, we can say "well, Ruby sucks", but that's the basic problem. To some degree, the answer might be to just give the user the minimum plus the upstream package management tool (pip or gem or whatever), but to me that seems like giving up on our broad mission. We can do better. SCLs are one attempt at this, and despite some issues seem to be fairly well received. (See for example http://developerweek.com/awards/) There are probably even better solutions out there. One thing I'm interested in experimenting with is Docker images built with packages from SCLs, but rebuilt so that the binary RPMS aren't SCL-enabled (and therefore put ruby at /usr/bin/ruby regardless of the version). Another idea is to work with the upstream packaging system so that when you gem install, an rpm is actually transparently built locally from the rubygems.org packages. There are certainly more ideas -- the Environments and Stacks Working Group is working on this. But there's also a lot of handwaving. :) -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, 2014-01-28 at 19:04 +0100, drago01 wrote: > > Second, give people what they *do* care about: choices of language stacks > > above the base level, and a layer of separation so that there isn't a big > > impact when the base layer changes. To quote someone I talked to: No > > distribution does that well, so if you can, you'd really have something > > valuable to me. > > This is again "hand wavy"(sorry for overusing this term). I can > already have multiple language stacks > for instance python, java, ruby and php on fedora (or pretty much any > other distribution) just fine today. > > And I don't expect it to break when the "base layer" (whatever that > means ... kernel? glibc? systemd?) changes. > So in that case I didn't even get the problem itself so I cannot > comment much on the solution. From my perspective it isn't about the language stacks, its about the stacks within the languages. Fedora has a 18 month window. My servers run for years. I don't have time to update the entire server every 18 months. It just isn't feasible. (I'm also not fully virtualized and automated with ansible and friends yet). So given that I use CentOS since I know it will remain stable. The downside is that php is never updated on it. It has a really really old php 5.3, I want 5.4 but so many things are compiled against the 5.3 so its a huge amount of work. I'm SUPER intrigued by Fedora.next if it is trying to solve this issue. I can have a base OS, but pick the PHP 5.4 stack or 5.5 stack and/or upgrade *just* that part on a live server. I'd be super happy. I could upgrade my php stack but leave the os running happily. Less work. Eventually I'd expect bringing up a cloud instance with ansible provisioning and all that would also allow that. -- Nathanael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Hi, what is a role? Is database-server a usefull role? Or would that go more to owncloud-server or joomla-server ... This would then pull all packages in. And if Owncloud supports several databases, Fedora should make a choice and install only one of them. A user which cares so deeply to make a decision which database he want's will install it manually anyhow. Fedora is making these choices on other instances: you get x.org and not wayland. You get gcc and not llvm. You get systemd and not upstart. cu romal Am 28.01.14 19:06, schrieb Tom Hughes: On 28/01/14 17:33, Matthew Miller wrote: On Tue, Jan 28, 2014 at 03:33:43PM +, Tom Hughes wrote: > I think the reason that people have trouble defining what "Fedora Server" might mean is that it simply doesn't make a huge amount of sense as a thing. Yes, that has traditionally been the stumbling block. But have you looked at what the Fedora Server working group is coming up with? The roles stuff? I have, though I'm not sure if I just failing to get it or something but I don't see anything there that looks especially useful to a server administrator. Other than pulling in a group of packages it's not really clear to me what a role does for me, and I suspect that defining roles that are generally useful without pulling in more than people really want will be hard - the classic example being the "database server" role that was included in the examples and which was going to pull in both postgres and mysql. Well normally I want one or the other, but not both... Obviously that can be fixed by having "mysql server" and "postgres server" roles but at one point do you wind up with one role per package and basically back where you started? If I recall correctly there was also some talk of having each role provide some sort of configuration/management interface that plugged into a web console but frankly that's the last thing I want on a server I'm looking after. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Hi, * Although it's certainly not the only reason, Fedora as _solely_ a hobbyist desktop is not ideal for an upstream for RHEL server and cloud products. No other system can be reinstalled / upgraded every six months. That single fact IMHO kills all other use cases. If I need a stable Fedora-like server, I get CentOS. It's kind of a Fedora-LTS. * General trend in Linux towards the base distribution being "boring" and not mattering. I asked several dozen different people at a gigantic Amazon conference why everyone was using the distribution they chose instead of Fedora, and the answer was almost universally "oh, I don't care; that's not really an interesting question because there's nothing important at that level". All (of the big) distros are mature today. At the early days one chose his distro by drivers, by installation-tool, by packages, ... Nowady every distro has a working installer, has a bazillion packages, ... they basically all work. So non-technical topics become more relevant: is there a LTS-release, can I start with a free(beer) distro like centos and later change to a paid-support-modell (RHEL) without rebuilding all my configs and apps, how good is the documentation, ... The real innovation is happening on the desktop: power management, Wayland, Mesa, wifi/3g/4g, color-management, pulseaudio, ... Now, that might not be really _true_, but it's definitely an increasing perception. How can we either fight that perception, or make sure that Fedora expands to also do work in the "interesting" space? I don't know anything about the statistics on Fedora contributors and their jobs. But if there are lot of hobbyists, students, ... these people are not able / interessted in large enterprise stuff like OpenStack, ... they work on devel-tools like languages and desktop-stuff, that's what they are using. If Fedora want's more innovation in those topics, Fedora must possibly reallign the devel-community. Most enterprise-project like libvirt, freeipa, Spacewalk, ... are done by Redhat-people ? Or am I totaly mistaken there. cu romal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 28 January 2014 07:42, Matthew Miller wrote: > > * General trend in Linux towards the base distribution being "boring" and > not mattering. I asked several dozen different people at a gigantic > Amazon > conference why everyone was using the distribution they chose instead of > Fedora, and the answer was almost universally "oh, I don't care; that's > not really an interesting question because there's nothing important at > that level". Now, that might not be really _true_, but it's definitely an > increasing perception. How can we either fight that perception, or make > sure that Fedora expands to also do work in the "interesting" space? > > I think it is a real item but even as a perception, it is not something that could be fought. Perceptions are like the tide and if you are lucky you might be able to build tons of dikes and stop the tide rolling in, but most likely you just have to wait til it goes out again in 8-16 years. The big issues with it not being interesting anymore is that like every other technology it has to become more and more standardized to meet the scale of issues that people are trying to solve. Plumbing had to do this in the 1800's and electrical wiring had to do this in the 1900's and car parts had to do this in the 1950's [while all of these are very diversified, they are less so than they were and you can reasonably be assured that every car of a certain model has the same parts, etc.] What that means is that you end up with more and more stop energy to 'fix', 'change', 'innovate' on the lower levels because it becomes harder and harder to get those parts to work with the rest of the industry. So either the innovation moves up the the chain, it becomes smaller and more specialized, or it goes to do something completely new that becomes interesting to loads of people again. [Or in 8-16 years people all of a sudden go, hey X is a really cool thing.. and everyone goes to do that again.] So I expect the work we need to work on is higher up in the stack as that is where things are interesting. The cool kids don't want to work on the plumbing levels of a single computer (or even a cluster), they want to work on hundreds to thousands of computers and the distribution at that part is just like a 'kernel' to them.. so if we want to move up we need to work on the meta-distribution and how that works. [Of course this could just be the rantings of a cough medicine dope fiend.. ] -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 28/01/14 17:33, Matthew Miller wrote: On Tue, Jan 28, 2014 at 03:33:43PM +, Tom Hughes wrote: > I think the reason that people have trouble defining what "Fedora Server" might mean is that it simply doesn't make a huge amount of sense as a thing. Yes, that has traditionally been the stumbling block. But have you looked at what the Fedora Server working group is coming up with? The roles stuff? I have, though I'm not sure if I just failing to get it or something but I don't see anything there that looks especially useful to a server administrator. Other than pulling in a group of packages it's not really clear to me what a role does for me, and I suspect that defining roles that are generally useful without pulling in more than people really want will be hard - the classic example being the "database server" role that was included in the examples and which was going to pull in both postgres and mysql. Well normally I want one or the other, but not both... Obviously that can be fixed by having "mysql server" and "postgres server" roles but at one point do you wind up with one role per package and basically back where you started? If I recall correctly there was also some talk of having each role provide some sort of configuration/management interface that plugged into a web console but frankly that's the last thing I want on a server I'm looking after. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 6:47 PM, Matthew Miller wrote: > On Tue, Jan 28, 2014 at 04:19:38PM +0100, drago01 wrote: >> You forgot the part where you explain how / why Fedora.next solves all >> this issues. Some like "cloud and server usage" is more or less clear >> (focus product) but the rest is a bot hand weavy. For instance why >> should any of the changes make people suddenly care about the >> distribution they use if you think they don't. > > To address your "for instance" specifically, I think there's two concrete > steps (which I hope you can see in the Cloud PRD). > > First, emphasize unique things we have at the base level which *should* be > of interest. For example, SELinux around Docker containers makes them have > reasonable security (rather than just being resource division). No one else > has that, so it's a good selling point. (Or will be once it's actually > implemented.) Or, better integration of an orchestration layer (although > that's somethin that we are not readay to tackle yet.) OK that one makes sense. > Second, give people what they *do* care about: choices of language stacks > above the base level, and a layer of separation so that there isn't a big > impact when the base layer changes. To quote someone I talked to: No > distribution does that well, so if you can, you'd really have something > valuable to me. This is again "hand wavy"(sorry for overusing this term). I can already have multiple language stacks for instance python, java, ruby and php on fedora (or pretty much any other distribution) just fine today. And I don't expect it to break when the "base layer" (whatever that means ... kernel? glibc? systemd?) changes. So in that case I didn't even get the problem itself so I cannot comment much on the solution. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 01/28/2014 05:55 PM, Matthew Miller wrote: Yeah, what? I'm not sure if that's lack of coffee or if I can blame my computer in some way. I think that was supposed to be "That leaves little room to" or something like that. As for what I think... I expect the working groups will work with the QA team experts to define release criteria appropriate for their areas. That's what the board-approved plan says https://fedoraproject.org/wiki/Fedora.next/boardproposal#QA. I didn't anticipate that being controversial, but if it is in some way, I'm sure we can figure something out. Should not be controversial since it's simple really we will shrink our default release criteria and test cases if they exist in accordance with the output from the WG's either remove that completely or move that into their own defined release criteria which resides in the community's surrounding the WG's . JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 09:44:34AM -0800, Adam Williamson wrote: > > > And that's reasonable. But as we have defined Fedora server as "not > > > anything in particular", that drifts closer and closer to "not a > > > thing". That leaves define release criteria -- let alone blockers. > > Why do you think we in QA are going to be defining release criteria > > surrounding cloud workstation or server? > Matthew's sentence does not parse grammatically at all, which makes it > hard for me to figure out what I'm saying, but he didn't mention 'QA' at > all. Yeah, what? I'm not sure if that's lack of coffee or if I can blame my computer in some way. I think that was supposed to be "That leaves little room to" or something like that. As for what I think... I expect the working groups will work with the QA team experts to define release criteria appropriate for their areas. That's what the board-approved plan says https://fedoraproject.org/wiki/Fedora.next/boardproposal#QA. I didn't anticipate that being controversial, but if it is in some way, I'm sure we can figure something out. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 04:19:38PM +0100, drago01 wrote: > You forgot the part where you explain how / why Fedora.next solves all > this issues. Some like "cloud and server usage" is more or less clear > (focus product) but the rest is a bot hand weavy. For instance why > should any of the changes make people suddenly care about the > distribution they use if you think they don't. To address your "for instance" specifically, I think there's two concrete steps (which I hope you can see in the Cloud PRD). First, emphasize unique things we have at the base level which *should* be of interest. For example, SELinux around Docker containers makes them have reasonable security (rather than just being resource division). No one else has that, so it's a good selling point. (Or will be once it's actually implemented.) Or, better integration of an orchestration layer (although that's somethin that we are not readay to tackle yet.) Second, give people what they *do* care about: choices of language stacks above the base level, and a layer of separation so that there isn't a big impact when the base layer changes. To quote someone I talked to: No distribution does that well, so if you can, you'd really have something valuable to me. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, 2014-01-28 at 09:44 -0800, Adam Williamson wrote: > Matthew's sentence does not parse grammatically at all, which makes it > hard for me to figure out what I'm saying, "what he's saying", I meant. Good grief, my fingers and brain are not connected this morning. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, 2014-01-28 at 17:40 +, "Jóhann B. Guðmundsson" wrote: > On 01/28/2014 05:33 PM, Matthew Miller wrote: > > And that's reasonable. But as we have defined Fedora server as "not anything > > in particular", that drifts closer and closer to "not a thing". That leaves > > define release criteria -- let alone blockers. > > > > Why do you think we in QA are going to be defining release criteria > surrounding cloud workstation or server? Matthew's sentence does not parse grammatically at all, which makes it hard for me to figure out what I'm saying, but he didn't mention 'QA' at all. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 01/28/2014 05:33 PM, Matthew Miller wrote: And that's reasonable. But as we have defined Fedora server as "not anything in particular", that drifts closer and closer to "not a thing". That leaves define release criteria -- let alone blockers. Why do you think we in QA are going to be defining release criteria surrounding cloud workstation or server? JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 03:33:43PM +, Tom Hughes wrote: > I think the reason that people have trouble defining what "Fedora > Server" might mean is that it simply doesn't make a huge amount of > sense as a thing. Yes, that has traditionally been the stumbling block. But have you looked at what the Fedora Server working group is coming up with? > To me what I would want of "Fedora Server" is simply a solid base OS > and a solid set of package I can install on top of that depending on > what I want each particular server to do - sometimes that will be > postgres, sometimes it will be mysql and apache, sometimes it will > be exim and spamassassin. And that's reasonable. But as we have defined Fedora server as "not anything in particular", that drifts closer and closer to "not a thing". That leaves define release criteria -- let alone blockers. > The biggest reason for people preferring, say, Ubuntu over Fedora > for servers is probably not the existence of something called > "server" but rather the extended stable lifetime offered by LTS > releases. And that's on the table as a possibility, but it would take a lot of commitment from package maintainers. Another approach is to work on making upgrades less disruptive, so you don't need to fear the EOL -- just schedule an update and your stuff keeps working. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 04:19:38PM +0100, drago01 wrote: > > So that's some of my thoughts. More later -- gotta take the kids to the > > dentist now. :) > You forgot the part where you explain how / why Fedora.next solves all > this issues. Some like "cloud and server usage" is more or less clear > (focus product) but the rest is a bot hand weavy. I didn't forget. That's just a different part of the conversation. I'm happy to talk about that too, though. I'm advocating for certain things which I think *do* address these needs. I'll try to talk more about the particular connections as things come up, but you're right that it's somewhat handwavy, because... well, many of the specifics actually haven't come up yet, so it's a future conversation. Possibly a very near-future one -- let's go! I'm also happy to talk about other big issues that we as a community feel like we face as we go into our second decade. I don't imagine the list I sent is comprehensive (let alone universally-agreed on). And I'll definitely advocate for any ideas anyone has to address any of this. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 09:42:54AM -0500, Matthew Miller wrote: > So, here's some things I see. Oh, I forgot one... * There is a lot of excitement about containers right now. It's not a new idea, but one where a lot of things have come together to make containerization interesting and viable on Linux. We should be positioned to lead in this area. That means at minimum efforts around Docker and LinuxApps, but it could go beyond that. Look at what CoreOS and Boot-to-Docker are doing -- a very minimal base OS with even system services provided as containers. It's possible that it's just a fad, but it may also be the next big direction for Linux-based operating systems. Even if we don't lead here, we should be prepared to adapt. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 28/01/14 14:42, Matthew Miller wrote: * Fedora's drift towards being primarily a desktop OS (with other use areas considered secondarily if at all) ends up practically restricting uses which people really do want Fedora for. That's bad for people who want to use Fedora in innovative ways in server and cloud environments. Even though we have a lot of sysadmin users and there are many examples of real Fedora in production server environments, every time over the past decade that someone has tried to figure out what Fedora Server might actually mean, it's gotten stalled. This has left many sysadmins feeling like either Fedora isn't a place that they can meaningfully contribute, or else that their job is to be the Voice of No. Even when one doesn't want to just be the project's "stop energy", it sometimes felt like there was no other option. Fedora.next should *give* that option for postive contribution. I think the reason that people have trouble defining what "Fedora Server" might mean is that it simply doesn't make a huge amount of sense as a thing. A desktop has some kind of common meaning that everybody can agree on in terms of expecting a window manager and certain basic applications but everybody will want something different of a server, and indeed will want something different on each server. To me what I would want of "Fedora Server" is simply a solid base OS and a solid set of package I can install on top of that depending on what I want each particular server to do - sometimes that will be postgres, sometimes it will be mysql and apache, sometimes it will be exim and spamassassin. The thing is, for the most part, that is what we already have! The biggest reason for people preferring, say, Ubuntu over Fedora for servers is probably not the existence of something called "server" but rather the extended stable lifetime offered by LTS releases. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 3:42 PM, Matthew Miller wrote: > [...] > So that's some of my thoughts. More later -- gotta take the kids to the > dentist now. :) You forgot the part where you explain how / why Fedora.next solves all this issues. Some like "cloud and server usage" is more or less clear (focus product) but the rest is a bot hand weavy. For instance why should any of the changes make people suddenly care about the distribution they use if you think they don't. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, Jan 25, 2014 at 12:39:53PM +0100, Thorsten Leemhuis wrote: > Understood, but OTOH it makes me wonder if Fedora.next is a step to > big and needs to be split or something. Well, in practical implementation, it probably _will_ be done as incremental steps. For example, there's the possibility of decoupling the schedules of the base release from the products, but one of the few solid decisions we've already made is that that won't happen for F21. > point is needed obviously. But sometimes I miss a few introductions > words on the "why" we want all of that and how it's supposed to make > Fedora better. But that's obviously meta/abstract again, which I So, here's some things I see. * Fedora's drift towards being primarily a desktop OS (with other use areas considered secondarily if at all) ends up practically restricting uses which people really do want Fedora for. That's bad for people who want to use Fedora in innovative ways in server and cloud environments. Even though we have a lot of sysadmin users and there are many examples of real Fedora in production server environments, every time over the past decade that someone has tried to figure out what Fedora Server might actually mean, it's gotten stalled. This has left many sysadmins feeling like either Fedora isn't a place that they can meaningfully contribute, or else that their job is to be the Voice of No. Even when one doesn't want to just be the project's "stop energy", it sometimes felt like there was no other option. Fedora.next should *give* that option for postive contribution. * Although it's certainly not the only reason, Fedora as _solely_ a hobbyist desktop is not ideal for an upstream for RHEL server and cloud products. That doesn't mean that there isn't room for one, but if we would focus Fedora on just that, we'd become increasingly irrelevant to our biggest downstream -- and to the project sponsor. (And make no mistake -- that concern of mine comes from a point of view of caring about Fedora first, not just my employer, because we benefit from taking part in that whole ecosystem cycle in ways beyond just Red Hat's direct employee and monetary contributions.) One particularly underserved area for Fedora is RHEL customers who would benefit from Fedora in some key areas (possibly even in production!), as well as those who are interested in experimenting with and possibily even shaping the future of the downstream. * General trend in Linux towards the base distribution being "boring" and not mattering. I asked several dozen different people at a gigantic Amazon conference why everyone was using the distribution they chose instead of Fedora, and the answer was almost universally "oh, I don't care; that's not really an interesting question because there's nothing important at that level". Now, that might not be really _true_, but it's definitely an increasing perception. How can we either fight that perception, or make sure that Fedora expands to also do work in the "interesting" space? * Difficulty building things on top of Fedora. This means both end-users with their own applications and bigger more complicated applications like OpenStack which it would be nice to have in the Fedora universe. There is value in the perfect-crystal-castle-of-all-packages approach, but if we build that in one place while everyone is going by on the highway, we're not really fulfilling our mission of leading free and open source software -- we're doing cleanup from behind and not making the impact we could be. I strongly believe that we can make room for this in the Fedora Project overall, even for things that are not appropriate in the Fedora *distribution* in its traditional sense. * As you mentioned in an earlier thread, it would be nice if we could make it easier to contribute minor changes, including big changes to more obscure packages. We can't just be Wikipedia and allow anonymous editing of packages (for one thing, we don't have an easy rollback mechanism and consequences could be much more severe), but maybe we can find a way of loosening things up for the fringes -- maybe even a really large fringe -- while keeping the core distribution under closer care. (Going way back to last summer's discussion, the problem with the former distinction between Core and Extras was that Core wasn't really open and the distinction was based on who you worked for; I'm quite certain we won't make that mistake again. Also, the standards for Extras were higher than those for Core, which was of course backwards and an example of community showing the way. But all that doesn't mean that we can't take the lessons and do it right.) * Wanting to eat our cake and have it too when it comes to balancing innovation and change management. In order to move fast while not breaking everybody all the time, it helps to break things up into larger logical segments tha
Re: Fedora.next in 2014 -- Big Picture and Themes
On 01/27/2014 01:06 PM, Stephen Gallagher wrote: No. The Products will be defining an environment and a standard install set. They may have separate initial*installation* repositories if they need to provide different options to Anaconda, but beyond that the intent is for all of the Products to continue to draw from the same store of packages together. If (for example) we got ourselves into a situation where you couldn't install Fedora Server and then also install the GNOME desktop environment on that Server, this would be considered a major bug and one that we would need to reconcile immediately. So what exactly changes if the above step is considered a major bug? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 27 January 2014 13:06, Stephen Gallagher wrote: > On 01/27/2014 05:36 AM, Ian Malone wrote: >> does this mean there will be things unavailable on some 'products' >> that are not on others? > No. > > The Products will be defining an environment and a standard install > set. They may have separate initial *installation* repositories if > they need to provide different options to Anaconda, but beyond that > the intent is for all of the Products to continue to draw from the > same store of packages together. > > If (for example) we got ourselves into a situation where you couldn't > install Fedora Server and then also install the GNOME desktop > environment on that Server, this would be considered a major bug and > one that we would need to reconcile immediately. Cool. If I was to take this one step further then, an issue for Fedora Jam is we were limited in the customisations the could be made for a spin (e.g. defaulting users into certain groups to allow real time audio). While there's not enough of the developer base to make it an official product would there be a way to slot this into that framework? -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
>On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote: >> After hacking a simple tool which provides a GUI for a repository file >> it's possible to create repository packages complete with desktop and >> appdata file. I have some 5-10 such repository packages under way, my >> plan is to push them into rpmfusion. > http://rpmfusion.org/Contributors#Read_the_packaging_guidelines > "RPM Fusion follows the Fedora packaging guidelines, make sure you've > read and understood these: >Naming Guidelines > > > "Guidelines" is a link to > https://fedoraproject.org/wiki/Packaging:Guidelines : > "Configuration for package managers in Fedora MUST ONLY reference the > official Fedora repositories in their default enabled and disabled state > (see the yum repo configuration in the fedora-release package for the > canonical list). Unofficial and third-party repositories that contain > only packages that it is legal for us to direct people to in Fedora (see > the Forbidden items and Licensing:Main pages for an explanation of what > is legal) may be shipped in %{_docdir}. The idea is that the system > administrator would need to explicitly copy the configuration file from > doc into the proper location on the filesystem if they want to enable > the repository." > Presumably one is to s/Fedora/RPMFusion and Fedora/g/ when reading that > as applying to Fusion, but still, Fusion's policies would appear to > forbid you to ship packages that contain 'active' external repository > configuration. >> If there will be a way for users to aggregate appdata from different >> sources such as rpmfusion (don't fully really understand this process >> right now) users will be able to search and find also non-free items >> as long there is a packaged repository for them. It should work out of >> the box right now using old-school tools based on package metadata. >> Not ideal, but perhaps something. > So I found this point interesting in thinking about these issues this > morning. There was a post of Hughesie's (I think) in another thread > which was also illuminating: it suggested the design of Software is to > be a generic 'software' installer - to provide as much 'software' from > as many sources as possible, under the 'it's all just software' theory, > guess. > I think the assumption that this is obviously the right design is > interesting, because I strongly disagree - not just for legal or policy > reasons, but because that's most definitely *not* what I want. I > cut] --- Sorry for badly formatted reply - lost the original in my mailbox and only have this web UI right now :(. Anyway, I have submitted [1], a rpmfusion review request for dropbox-repo. A real case should hopefully provide a sound base for remaining things to discuss. --alec [1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152 On 1/27/14, Stephen Gallagher wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/27/2014 05:36 AM, Ian Malone wrote: >> So without, unfortunately, the time to read through reams of stuff >> on this and with my user hat on (don't think I've seen any >> discussion of this on the users list), if it means how fedora >> actually works is better thought out then that's a good thing, but >> does this mean there will be things unavailable on some 'products' >> that are not on others? At the minute you install a spin and can >> add whatever other packages. That's great if you want to do >> something like set up a quick web server for testing or stream some >> music without creating VMs everywhere. It sounds a bit like this >> plan may end up with finding you can't do X on a Fedora system >> because you installed the wrong flavour. >> > > No. > > The Products will be defining an environment and a standard install > set. They may have separate initial *installation* repositories if > they need to provide different options to Anaconda, but beyond that > the intent is for all of the Products to continue to draw from the > same store of packages together. > > If (for example) we got ourselves into a situation where you couldn't > install Fedora Server and then also install the GNOME desktop > environment on that Server, this would be considered a major bug and > one that we would need to reconcile immediately. > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlLmWdMACgkQeiVVYja6o6P0twCfRk46ssphyt3+iZUnbh/t4TrG > +FEAoINANDTuTrd+jEY8rFLydsna8obW > =bmho > -END PGP SIGNATURE- > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 05:36 AM, Ian Malone wrote: > So without, unfortunately, the time to read through reams of stuff > on this and with my user hat on (don't think I've seen any > discussion of this on the users list), if it means how fedora > actually works is better thought out then that's a good thing, but > does this mean there will be things unavailable on some 'products' > that are not on others? At the minute you install a spin and can > add whatever other packages. That's great if you want to do > something like set up a quick web server for testing or stream some > music without creating VMs everywhere. It sounds a bit like this > plan may end up with finding you can't do X on a Fedora system > because you installed the wrong flavour. > No. The Products will be defining an environment and a standard install set. They may have separate initial *installation* repositories if they need to provide different options to Anaconda, but beyond that the intent is for all of the Products to continue to draw from the same store of packages together. If (for example) we got ourselves into a situation where you couldn't install Fedora Server and then also install the GNOME desktop environment on that Server, this would be considered a major bug and one that we would need to reconcile immediately. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmWdMACgkQeiVVYja6o6P0twCfRk46ssphyt3+iZUnbh/t4TrG +FEAoINANDTuTrd+jEY8rFLydsna8obW =bmho -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 23 January 2014 21:57, Adam Williamson wrote: > On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote: >> On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson wrote: >> > On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: >> > >> >> > To be honest my concerns are more with my user hat on than my >> >> > contributor >> >> > hat - that we will lose the gold standard unified packaging standards >> >> > and >> >> > single source and mechanism for installing packages. >> >> >> >> I haven't seen anything from any WG that would suggest a deviation >> >> from RPM packaging guidelines or using separate repositories. It is a >> >> valid concern and one we need to keep an eye on. >> > >> > Um. As I read it, three out of four WGs - desktop, server, and cloud - >> > have at least discussed the possibility of implementing what are, in >> > essence, secondary package management layers. The details differ - 'app >> > bundles' for desktop, 'containers' or whatever for server and cloud - >> > but the effect is the same. >> >> Secondary being the key word. None of them are proposing alternate >> RPM repositories or changing the Fedora packaging guidelines. Tom was >> expressing that he is concerned the Fedora repos would go away or be >> of decreased quality. None of the WG proposals are altering those >> repos. They will still exist, much as they do today. > > The repos will still exist, but things will be different. At present, > the Fedora repos are the single unified official Fedora method for > deploying software on Fedora products. Any other method you can use to > deploy software is not an 'official Fedora' thing. > > If these plans go ahead, we will have multiple official/blessed methods > for deploying software on Fedora, potentially with different policies > about what software they can include and how that software should be > arranged, how dependencies should be handled, and all the rest of it. > Some of these methods will be shared between products, and some will > either only exist in certain products, or at least be clearly associated > with and 'owned' by those products. So without, unfortunately, the time to read through reams of stuff on this and with my user hat on (don't think I've seen any discussion of this on the users list), if it means how fedora actually works is better thought out then that's a good thing, but does this mean there will be things unavailable on some 'products' that are not on others? At the minute you install a spin and can add whatever other packages. That's great if you want to do something like set up a quick web server for testing or stream some music without creating VMs everywhere. It sounds a bit like this plan may end up with finding you can't do X on a Fedora system because you installed the wrong flavour. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, Jan 25, 2014 at 11:20:33AM +0100, Thorsten Leemhuis wrote: > Hi! > > On 23.01.2014 19:26, Josh Boyer wrote: > > On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis > > wrote: > > The packaging guidelines are very daunting. Automating as much of > > that as possible, either through spec creation tooling or package > > review tooling would help. > > I think it's not only the packaging guidelines imho, it's the whole > processes around package maintenance -- for existing packagers and > newcomers. > > I for example recently saw that a package I used to maintain long ago > was outdated in fedora 20. I chose to ignore it in the end, as I didn't > want to nag the current maintainers via bugzilla (yes, I should have > done that; sorry, was overly careful or lazy, but that's how people are > quite often afaics); I would have preferred to simply do a "fedpkg clone > foo; " and then submit it to rawhide, > without fearing somebody might yell at me(¹). IOW: like editing a > wikipedia page, even if that's in the end more work that simply filing a > bug. > > (¹) Yes, I still have provenpackager rights, so I could have done that, > but that wouldn't be considered appropriate under current rules In pkgdb2, I'm replacing the wording 'Owner' by 'Point of contact' for this exact reason, trying to get people to change their relation to 'their' package into a relation where they are simply the primary point of contact, not a big deal if someone updates it in rawhide w/o breaking too much. Hopefully with time it will help changing things :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 1/26/14, Aleksandar Kurtakov wrote: > I feel obligated to comment on this. JPackage and Fedora have taken > different routes years ago and installing JPackage rpm on top of Fedora will > likely break Fedora packages due to: > * additional OSGi metadata Fedora ships but JPackage doesn't > * different places of maven pom and depmap changes > * different major versions of the same package (aka maven package in > JPackage was 1.x (last I checked) but in Fedora it's 3.x) and etc. > > Would you please point to a place where jpackage is stated as compatible? > This is probably a legacy page which needs to be updated with current state > of affairs so people don't think they can mix and match freely. > > Alexander Kurtakov > Red Hat Eclipse team Oops, bad example it seems. Had the link at hand yesterday, don't find it now. Now let's drop jpackage in this discussion. It is obviously a bad example. But in a way, it's also a good one. Given your statement, I find it highly unlikely that a packaged jpackage repo would have survived a package review, if at all submitted. IMHO, this is really the important issue here. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Thorsten Leemhuis wrote: >On 25.01.2014 17:35, Adam Williamson wrote: >> On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote: >> >>> Debian, who has a similar stance on >>> non-free Software, does a way better job in that area than Fedora >does. >> Well, not really - they don't have a 'similar stance', they have an >> official non-free repository. That's kind of a significant >> difference. :) > >Ha, Debian and Fedora, the distributions, are imo not that different >after a standard install (but yes, there are differences as well - >patents strategy, Firmware). But yes, you are right, the Debian project >has a a official non-free repository, which is a significant difference >to the Fedora project. One that leads to a better user experience; >something that afics a lot of Fedora users and some Fedoraproject >developers want to see as well. Let's avoid personal examples. I also know many users and Fedora contributors that respect Fedora's foundations and would probably leave Fedora if these were to change. > That's why I think it would be good if >the the Fedora project might help/guide in that are, even if the >resulting repo and the main work is done outside of the Fedora project. I agree with guidance. I don't think anyone would object to help them, so that *they* can ship their software for Fedora in a more UX friendly way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
- Original Message - > From: "Alec Leamas" > To: "Development discussions related to Fedora" > > Sent: Sunday, January 26, 2014 11:22:36 AM > Subject: Re: Fedora.next in 2014 -- Big Picture and Themes > > On 1/25/14, Adam Williamson wrote: > > On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote: > > > > > >> After hacking a simple tool which provides a GUI for a repository file > >> it's possible to create repository packages complete with desktop and > >> appdata file. I have some 5-10 such repository packages under way, my > >> plan is to push them into rpmfusion. > > > > http://rpmfusion.org/Contributors#Read_the_packaging_guidelines > > I know this is controversial. I've also heard some rumours about > Fedora using something they call "Packaging Guidelines". Has anyone > some information on this topic? ;) > > Can we just for the sake of discussion leave this formal side of it, for now? > > > So I found this point interesting in thinking about these issues this > > morning. There was a post of Hughesie's (I think) in another thread > > which was also illuminating: it suggested the design of Software is to > > be a generic 'software' installer - to provide as much 'software' from > > as many sources as possible, under the 'it's all just software' theory, > > I guess. > > > > I think the assumption that this is obviously the right design is > > interesting, because I strongly disagree - not just for legal or policy > > reasons, but because that's most definitely *not* what I want. I don't > > want a 'greedy' software installer that just finds every piece of crap > > on the internet and offers it to me. I appreciate the curation that > > I don't know if this is Hughesie's vision. Anyway, it's certainly not > mine. Adding whatever software available out there to the repos is a > Bad Idea. Agreed > > That said,, IMHO we actually need to be better on delivering what > people need. Some of this is not in Fedora's repos. This is already > acknowledged here and there. E. g., rpmfusion has list of > repositories which are known to work with rpmfusion [1]. For fedora, > we have e. g. jpackage, which is stated s compatible in the Java GL. I feel obligated to comment on this. JPackage and Fedora have taken different routes years ago and installing JPackage rpm on top of Fedora will likely break Fedora packages due to: * additional OSGi metadata Fedora ships but JPackage doesn't * different places of maven pom and depmap changes * different major versions of the same package (aka maven package in JPackage was 1.x (last I checked) but in Fedora it's 3.x) and etc. Would you please point to a place where jpackage is stated as compatible? This is probably a legacy page which needs to be updated with current state of affairs so people don't think they can mix and match freely. Alexander Kurtakov Red Hat Eclipse team > > I'm trying to find some middle ground here. Instead of just enabling > repos, perhaps when installing something else, I'm trying a process > where each and every repository added is packaged separately. Hence, > here is also separate review for each repository. And even if > installed, it's not enabled until l explicitly configured by user.. > > I see all the problems when using things like pip, gem etc. However, > this is not anything like this. It's about letting users install > carefully selected repositories which are known to work with Fedora. > Doing it this way, we also create a difference to other repositories > which are not endorsed. Also this is something we need badly IMHO. > > It's also task which naturally belongs to rpmfusion, mostly the > non-free section. > > --alec. > > [1] http://rpmfusion.org/FedoraThirdPartyRepos > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 1/25/14, Adam Williamson wrote: > On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote: > > >> After hacking a simple tool which provides a GUI for a repository file >> it's possible to create repository packages complete with desktop and >> appdata file. I have some 5-10 such repository packages under way, my >> plan is to push them into rpmfusion. > > http://rpmfusion.org/Contributors#Read_the_packaging_guidelines I know this is controversial. I've also heard some rumours about Fedora using something they call "Packaging Guidelines". Has anyone some information on this topic? ;) Can we just for the sake of discussion leave this formal side of it, for now? > So I found this point interesting in thinking about these issues this > morning. There was a post of Hughesie's (I think) in another thread > which was also illuminating: it suggested the design of Software is to > be a generic 'software' installer - to provide as much 'software' from > as many sources as possible, under the 'it's all just software' theory, > I guess. > > I think the assumption that this is obviously the right design is > interesting, because I strongly disagree - not just for legal or policy > reasons, but because that's most definitely *not* what I want. I don't > want a 'greedy' software installer that just finds every piece of crap > on the internet and offers it to me. I appreciate the curation that I don't know if this is Hughesie's vision. Anyway, it's certainly not mine. Adding whatever software available out there to the repos is a Bad Idea. Agreed That said,, IMHO we actually need to be better on delivering what people need. Some of this is not in Fedora's repos. This is already acknowledged here and there. E. g., rpmfusion has list of repositories which are known to work with rpmfusion [1]. For fedora, we have e. g. jpackage, which is stated s compatible in the Java GL. I'm trying to find some middle ground here. Instead of just enabling repos, perhaps when installing something else, I'm trying a process where each and every repository added is packaged separately. Hence, here is also separate review for each repository. And even if installed, it's not enabled until l explicitly configured by user.. I see all the problems when using things like pip, gem etc. However, this is not anything like this. It's about letting users install carefully selected repositories which are known to work with Fedora. Doing it this way, we also create a difference to other repositories which are not endorsed. Also this is something we need badly IMHO. It's also task which naturally belongs to rpmfusion, mostly the non-free section. --alec. [1] http://rpmfusion.org/FedoraThirdPartyRepos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 25.01.2014 17:35, Adam Williamson wrote: > On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote: > >> Debian, who has a similar stance on >> non-free Software, does a way better job in that area than Fedora does. > Well, not really - they don't have a 'similar stance', they have an > official non-free repository. That's kind of a significant > difference. :) Ha, Debian and Fedora, the distributions, are imo not that different after a standard install (but yes, there are differences as well - patents strategy, Firmware). But yes, you are right, the Debian project has a a official non-free repository, which is a significant difference to the Fedora project. One that leads to a better user experience; something that afics a lot of Fedora users and some Fedoraproject developers want to see as well. That's why I think it would be good if the the Fedora project might help/guide in that are, even if the resulting repo and the main work is done outside of the Fedora project. CU knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, 25 Jan 2014 09:59:12 -0700 Kevin Fenzi wrote: > On Sat, 25 Jan 2014 12:16:40 +0100 > Thorsten Leemhuis wrote: > > ...snip... > > > Agreed. For example, "+1/like"-Buttons for a mailing list would be > > good afaics, to get a rough impression how people think (just > > wondering: will hyperkitty or something from that camp of developers > > have this?). But that's just one thing that springs to my mind and a > > different topic. > > Yes, hyperkitty does have this ability. ;) > > It's not been synced lately, so I can't +1 your post, but you can look > at our staging instance: > > https://lists.stg.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/2014// Oops. That should be: https://lists.stg.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/2014/1/ I somehow dropped the 1 there. ;( Sorry about that... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, 25 Jan 2014 12:16:40 +0100 Thorsten Leemhuis wrote: ...snip... > Agreed. For example, "+1/like"-Buttons for a mailing list would be > good afaics, to get a rough impression how people think (just > wondering: will hyperkitty or something from that camp of developers > have this?). But that's just one thing that springs to my mind and a > different topic. Yes, hyperkitty does have this ability. ;) It's not been synced lately, so I can't +1 your post, but you can look at our staging instance: https://lists.stg.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/2014// kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, 2014-01-25 at 08:43 -0800, Adam Williamson wrote: > "Guidelines" is a link to > https://fedoraproject.org/wiki/Packaging:Guidelines : > > "Configuration for package managers in Fedora MUST ONLY reference the > official Fedora repositories in their default enabled and disabled state > (see the yum repo configuration in the fedora-release package for the > canonical list). Unofficial and third-party repositories that contain > only packages that it is legal for us to direct people to in Fedora (see > the Forbidden items and Licensing:Main pages for an explanation of what > is legal) may be shipped in %{_docdir}. The idea is that the system > administrator would need to explicitly copy the configuration file from > doc into the proper location on the filesystem if they want to enable > the repository." > > Presumably one is to s/Fedora/RPMFusion and Fedora/g/ when reading that > as applying to Fusion, but still, Fusion's policies would appear to > forbid you to ship packages that contain 'active' external repository > configuration. Of course, it's interesting to read the above and then reflect on the situation of pip, rubygems, pear etc etc etc etc etc. Presumably the term 'package managers' is being interpreted very narrowly... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote: > After hacking a simple tool which provides a GUI for a repository file > it's possible to create repository packages complete with desktop and > appdata file. I have some 5-10 such repository packages under way, my > plan is to push them into rpmfusion. http://rpmfusion.org/Contributors#Read_the_packaging_guidelines "RPM Fusion follows the Fedora packaging guidelines, make sure you've read and understood these: Naming Guidelines Guidelines" "Guidelines" is a link to https://fedoraproject.org/wiki/Packaging:Guidelines : "Configuration for package managers in Fedora MUST ONLY reference the official Fedora repositories in their default enabled and disabled state (see the yum repo configuration in the fedora-release package for the canonical list). Unofficial and third-party repositories that contain only packages that it is legal for us to direct people to in Fedora (see the Forbidden items and Licensing:Main pages for an explanation of what is legal) may be shipped in %{_docdir}. The idea is that the system administrator would need to explicitly copy the configuration file from doc into the proper location on the filesystem if they want to enable the repository." Presumably one is to s/Fedora/RPMFusion and Fedora/g/ when reading that as applying to Fusion, but still, Fusion's policies would appear to forbid you to ship packages that contain 'active' external repository configuration. > If there will be a way for users to aggregate appdata from different > sources such as rpmfusion (don't fully really understand this process > right now) users will be able to search and find also non-free items > as long there is a packaged repository for them. It should work out of > the box right now using old-school tools based on package metadata. > Not ideal, but perhaps something. So I found this point interesting in thinking about these issues this morning. There was a post of Hughesie's (I think) in another thread which was also illuminating: it suggested the design of Software is to be a generic 'software' installer - to provide as much 'software' from as many sources as possible, under the 'it's all just software' theory, I guess. I think the assumption that this is obviously the right design is interesting, because I strongly disagree - not just for legal or policy reasons, but because that's most definitely *not* what I want. I don't want a 'greedy' software installer that just finds every piece of crap on the internet and offers it to me. I appreciate the curation that repositories provide, I tend my repository configuration carefully, and I really do only want to be offered software from my configured repositories as a matter of course, and yes, I do not expect that the packages from my configured repos will go and set up other repos, and I would be quite angry if they did. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, 2014-01-25 at 11:20 +0100, Thorsten Leemhuis wrote: > Debian, who has a similar stance on > non-free Software, does a way better job in that area than Fedora does. Well, not really - they don't have a 'similar stance', they have an official non-free repository. That's kind of a significant difference. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Hi! On 23.01.2014 22:45, Adam Williamson wrote: > On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote: > >> wikipedia page. Further: kororaproject.org, fedorautils-installer and >> similar project show that there are people that want to make Fedora >> better. But they do their work outside of Fedora and RPM Fusion; >> fixing the issues directly at the root would be better for all of us. > Those particular examples are very bad examples because they are doing > things Fedora explicitly chooses not to do, [...] See my reply in https://lists.fedoraproject.org/pipermail/devel/2014-January/194581.html as that hopefully better explains what I had up in my mind. > [...] > And the lead Korora dev is an active Fedora contributor. I know, but for me Korora, fedorautils-installer, and similar things are a sign that some problems in Fedora and RPM Fusion get circumvented in to many layers instead of being solved at their root. It reminds me of a kernel enhancement that is maintained outside of the Linux kernel: they often solve real problems and some users love them, but it's better for everyone to get a proper solution upstream, as that's the way to reach the masses and make things "simply work". Cu knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi! On 23.01.2014 22:33, Kevin Fenzi wrote: > On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis > wrote: >> On 03.01.2014 19:14, Matthew Miller wrote: >>> […] So those are my things. What do you think about them? What >>> else should be included? What different directions should we >>> consider? How will we make Fedora more awesome than ever in >>> the coming year? >> Okay, I'll bite (after thinking whether writing this mail is >> worth it): > Hey Thorsten! Glad you did. ;) :) >> I'm still undecided if I overall like Fedora.next or fear it. But >> more and more I tend to the latter position and wonder if it >> might be wise to slow things down: Do one more Fedora release the >> old style in round about June; that would give us more time to >> better discuss and work out Fedora.next and get contributors >> involved better in the planing. > This is not practical. Lots of people are thinking about a > fedora.next, qa folks are coding away, lots of people who normally > would be working on the next release are not. If we tell them to > stop all that and go back to normal, we could, but then fedora.next > will likely never ever happen. Understood, but OTOH it makes me wonder if Fedora.next is a step to big and needs to be split or something. > [...] The current problem I have with Fedora.next is that it's so > abstract. I understand that people who like PRD's and TPS want high > level descriptions of what we want to do with goals and visions and > such, and thats great. However, I'm a technical person. I like > concrete plans and pushing what we can do with the technology we > have at hand, or helping to make new technology to do what we want. > +1 you found really good words for what's a big part of the problem I have with Fedora.next > We are now down to the point where groups have written up their > PRD documents, and can get down to details. So, I am hopeful in the > next month or so we will gain a lot more interest in fedora.next > and more feedback as concrete deliverables are discussed, etc. > > That is my hope at least... we will see. :) Yeah, we'll see :D Your words otoh scratched another thought in my head: The PRD documents (and some of the other docs around Fedora.next) in great length talk a lot about "how" they want to do something. That up to a point is needed obviously. But sometimes I miss a few introductions words on the "why" we want all of that and how it's supposed to make Fedora better. But that's obviously meta/abstract again, which I myself criticized earlier. So maybe it's simply this ted talk that stuck in my head too much: http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action.html Cu knurd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS46KJAAoJEHK25u9MWD0tf8oQAKamRcqVt8XTbh8TmjfWxqqc AeP5MVmJnhE9TEbgsenZUex0xo3dnRaU9prdF/delAVgL7ahCbIPWgKtKT3IsqsA GHygf8d046PM2+z8lFH8IAinK5KhikmRki/xS+3IknHEPWUKmGcFtIG13L2C32w/ VEZ+/IF70NEa2xe7jtg0QzH4uungZfVH6Gsl2WcsjnjC0BiqU5vkVjdDWKWCt+GD taAL5pNbO1TsuAhnNa4PL/eHJehEGUo1UrLv4FDnPFLm4v6Wex9VScd6Z2XQ6VLu I2Lw5RqU5m0kNPa5k4+gEABqDrqObK6Q+akwX/c97Tcus52SwmIQA4yHGHsIQy2c hSeg/mQyzZHabob909EPu2y6/m49uEpmU8sgb7QqQzIk77rKaUQrGloPSOTrAs6j TSMtZX/DkF6VZIBATSTtOJD7pL3jvCWOb66ueA+MJqGZdB3WiuB7En+9JTrhjYSe mEs9KORkYgyQniVTlhtVG9tu8/OFvt8ud+iq+FlAVzyHAfDofpC+w7WnkSSn3Mit wEEgsvuYx630z+HY2+aBBViU+/11D1G8lVBJqGINogPRxopTpN9EPCbvAOnHmwd3 iOqsPzsUjZCviXasjIrrj91QDXduS/N3sFCam1dq2CqXF692ampEzAfavu/VX9yB jfSdBXA1/7Vk/MLXgB6E =BoBF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Hi! On 23.01.2014 20:57, Matthew Miller wrote: > On Thu, Jan 23, 2014 at 07:03:02PM +0100, Thorsten Leemhuis wrote: >> Okay, I'll bite (after thinking whether writing this mail is worth it): > Thanks. I hope that I can make you feel that it was. Thx for your answer – yes, I think it was worth it. But I hope I don't get a Fedora badge that says "started a discussion in devel@fedoraproject that made it to Phoronix" ;-) > [...] > I will be giving a talk on Sunday, February 9th in at DevConf in Brno, CZ, > and I'll post slides from that (probably here as text as well), and I assume > there will be video. That's great (I'll be there; Fosdem as well), but please allow me a side note here: Videos and IRC logs are a great resource if you really care about something and want to know all the details. But the ratio for "time spend watching/reading vs. information gathered" is often quite bad. That's why written, easy to read summaries are important. And I think we got too few of them from Flock last year, which is one of the reason why I had/have problems to fully understand Fedora.next. > [...] > But also, I want to go back to the first part of my message that you're > responding to. I don't think our current online communication structure > really works very well for the kind of contributor you're concerned about. > (Let alone working very well for more active contributors who still don't > have time to read every list or hang out on IRC 24/7.) I think we need to > fix that, whether we consider that part of Fedora.next or a separate big > initiative. Agreed. For example, "+1/like"-Buttons for a mailing list would be good afaics, to get a rough impression how people think (just wondering: will hyperkitty or something from that camp of developers have this?). But that's just one thing that springs to my mind and a different topic. In addition: A few days ago someone shared the article "Top 10 ways to ensure your best people will quit" on G+: http://www.ragan.com/Main/Articles/Top_10_ways_to_ensure_your_best_people_will_quit_47779.aspx I normally don't read or like things like that much, but I enjoyed this one. And I wondered if all of those points are relevant for Fedora as well. I tend to think they are. Point "3" for example made me wonder if every few months we should ask developers if they are happy with the current state and how things evolve. Obviously automated web based questioning system or something like that. Something simple could do for the start. That way we could get early warning signs if developers are unhappy, to do something before they leave. >> I have many more thoughts in my head, but I'll stop here, as those are >> basically the most important things that bother me right now when >> looking at Fedora and Fedora.next. > I appreciate it. Does anything I've said help you feel better about it? To be honest: only a little bit. Fedora.next simply is so big (I'm wondering if too much is cramped into it) and still vague in some parts that I remain careful. But that's not unusual, I'm quite sceptic all the time and more of a pessimist ;-) > [...] > I would like to hear more of your thoughts, too. In the past few months a few people encouraged be to write down how I'd design Fedora if I could. Maybe I should finally do that – but OTOH I'm not sure if that is worth the work and if it's really helpful for the curent debate. And for now I have something else I need to take care of first: preparing my devconf talk :D Cu & have a nice weekend everyone knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, Jan 25, 2014 at 11:20 AM, Thorsten Leemhuis wrote: > [cut] > > The Fedoraproject once again chose to leave non-free out of Fedora. I > appreciate that. I even think a lot of users understand why the > Fedoraproject acts like this (now and earlier, too). But: it utterly > hard to get non-free Software when running Fedora. That's what the > Fedora ecosystem IMHO needs to fix. Debian, who has a similar stance on > non-free Software, does a way better job in that area than Fedora does. > We need to catch up here and I think the Fedoraproject should drive > this, because it's important for the success of Fedora (and RHEL/CentOS) > that people can easily use it for what they want. > +1 Indeed. And to be frank it's not only about non-free software, it's just about anything which if not is "Not invented Here" at least is "Not Packaged Here". > And as the down-voted > proposal shows: There are developers within the Fedoraproject that are > willing to do the work; there are more in Korora, RPM Fusion and other > places. We just need to bring them together properly afiacs. > I'm also on this. After the lpf effort trying to cope with non-redistributable sw (skype, spotify, flash...) I'm now trying a simplistic way top make "foreign" repositories more visible and usable.: After hacking a simple tool which provides a GUI for a repository file it's possible to create repository packages complete with desktop and appdata file. I have some 5-10 such repository packages under way, my plan is to push them into rpmfusion. If there will be a way for users to aggregate appdata from different sources such as rpmfusion (don't fully really understand this process right now) users will be able to search and find also non-free items as long there is a packaged repository for them. It should work out of the box right now using old-school tools based on package metadata. Not ideal, but perhaps something. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Hi! On 23.01.2014 19:26, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis > wrote: > > […] Thx for your answer, just replying to some parts of it where I feel that making additional statements bring the discussion forward. >> What really gives me the creeps on those pages: "sub-committees of >> FESCo, with individual governance structures". Those afaics are three >> Product Working Groups Workgroups, two Fedora Rings Working Groups and >> the Inter-WG for coordination. That sounds like a awful lot of >> overhead an even more bureaucracy than we already have. And we imho >> have way to much already (part of it is my fault!) – something I had >> hoped Fedora.next would try to fix. > It is more overhead to a degree. On the other hand, the idea is to > enable people that are interested in specific areas to go forth and > create a Fedora deliverable that they think meets the needs of those > areas best, without having to pass everything through FESCo. FESCo > just doesn't scale like that. Sure, but I doubt that more committees are the best way to solve that. I'm wondering if a development approach that more resembles the Linux kernel would be better. Sure, the kernel also has people (not committees!) that steer things and some rules (a lot not written down, which has benefits imo). And in the end it's a lot "if you want something crazy new realized you can do that as long as you do not break the things others care about". More of that attitude and less rules/committees is something I'd like to see in Fedora. >> I these days wouldn't start contributing to Fedora, as all those rules >> and guidelines that the wiki provides would scare me off. That's what >> Fedora.next should fix imo, as we afaics need more contributors: I >> more often than a few years ago find packages in Fedora that are badly >> maintained or outdated. Contributing must be as easy as editing a > The packaging guidelines are very daunting. Automating as much of > that as possible, either through spec creation tooling or package > review tooling would help. I think it's not only the packaging guidelines imho, it's the whole processes around package maintenance -- for existing packagers and newcomers. I for example recently saw that a package I used to maintain long ago was outdated in fedora 20. I chose to ignore it in the end, as I didn't want to nag the current maintainers via bugzilla (yes, I should have done that; sorry, was overly careful or lazy, but that's how people are quite often afaics); I would have preferred to simply do a "fedpkg clone foo; " and then submit it to rawhide, without fearing somebody might yell at me(¹). IOW: like editing a wikipedia page, even if that's in the end more work that simply filing a bug. (¹) Yes, I still have provenpackager rights, so I could have done that, but that wouldn't be considered appropriate under current rules >> wikipedia page. Further: kororaproject.org, fedorautils-installer and >> similar project show that there are people that want to make Fedora >> better. But they do their work outside of Fedora and RPM Fusion; >> fixing the issues directly at the root would be better for all of us. > Small note: The two projects you use as an example are required to do > what they're doing (in part) outside of Fedora for legal reasons. I > don't believe Fedora.next will change how US law works, so it might > not be the best of examples. Hmmm. Maybe it were bad examples. But I guess I didn't actually explain the point I was trying to make properly. So here we go in different words after a few more quotes lines: > (And we have a Board meeting to discuss related things that are not > legally prohibited.) (for the archives: see https://lists.fedoraproject.org/pipermail/advisory-board/2014-January/012433.html for context and outcome; in short: the Fedora board voted against the proposal to allow 3rd party repos in the App installer) The Fedoraproject once again chose to leave non-free out of Fedora. I appreciate that. I even think a lot of users understand why the Fedoraproject acts like this (now and earlier, too). But: it utterly hard to get non-free Software when running Fedora. That's what the Fedora ecosystem IMHO needs to fix. Debian, who has a similar stance on non-free Software, does a way better job in that area than Fedora does. We need to catch up here and I think the Fedoraproject should drive this, because it's important for the success of Fedora (and RHEL/CentOS) that people can easily use it for what they want. And as the down-voted proposal shows: There are developers within the Fedoraproject that are willing to do the work; there are more in Korora, RPM Fusion and other places. We just need to bring them together properly afiacs. Obviously those developers need a place to do their work. I think RPM Fusion is that, as it's well established and something a lot of people all to Fedora anyway. But yes, RPM Fusion contains packages that are problematic u
Re: Fedora.next in 2014 -- Big Picture and Themes
On Fri, 2014-01-24 at 09:58 -0700, Eric Smith wrote: > On Jan 23, 2014 2:33 PM, "Kevin Fenzi" wrote: > > > > On Thu, 23 Jan 2014 19:03:02 +0100 > > Thorsten Leemhuis wrote: > > > I'm still undecided if I overall like Fedora.next or fear it. But > more > > > and more I tend to the latter position and wonder if it might be > wise > > > to slow things down: Do one more Fedora release the old style in > round > > > about June; that would give us more time to better discuss and > work > > > out Fedora.next and get contributors involved better in the > planing. > > > > This is not practical. Lots of people are thinking about a > > fedora.next, qa folks are coding away, lots of people who normally > > would be working on the next release are not. If we tell them to > stop > > all that and go back to normal, we could, but then fedora.next will > > likely never ever happen. > [...] > > The current problem I have with Fedora.next is that it's so > abstract. > > How are QA folks "coding away" for Fedora.next, rather than > traditional Fedora QA processes, if Fedora.next is "so abstract"? We're not really coding *for* Fedora.next, we're coding the new autoqa system (taskotron) which we need whether Fedora.next happens or not (I'm not suggesting seriously that it won't, I'm just making the point that taskotron is not at all dependent on .next). Where .next comes into it is that the longer cycle for F21 is kind of tied into the .next stuff, and in turn, the longer cycle is what's affording QA's tools folks the space and time to get taskotron into working order - our assessment was that we could get taskotron ready for F21 on the delayed schedule, but not on the 'regular' schedule. I believe some of the ideas encompassed by .next more or less assume the existence of a mature automated testing framework and certain tests within that framework, so .next may consider itself dependent on taskotron, but the dependency doesn't run the other way: we were working on taskotron before .next became a Thing at all, and we'd still be working on it if .next wasn't a Thing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Fri, 24 Jan 2014 09:58:07 -0700 Eric Smith wrote: > On Jan 23, 2014 2:33 PM, "Kevin Fenzi" wrote: > > > > On Thu, 23 Jan 2014 19:03:02 +0100 > > Thorsten Leemhuis wrote: > > > I'm still undecided if I overall like Fedora.next or fear it. But > > > more and more I tend to the latter position and wonder if it > > > might be wise to slow things down: Do one more Fedora release the > > > old style in round about June; that would give us more time to > > > better discuss and work out Fedora.next and get contributors > > > involved better in the planing. > > > > This is not practical. Lots of people are thinking about a > > fedora.next, qa folks are coding away, lots of people who normally > > would be working on the next release are not. If we tell them to > > stop all that and go back to normal, we could, but then fedora.next > > will likely never ever happen. > [...] > > The current problem I have with Fedora.next is that it's so > > abstract. > > How are QA folks "coding away" for Fedora.next, rather than > traditional Fedora QA processes, if Fedora.next is "so abstract"? Kevin covered most of it, but the short answer is that we have so much stuff in our backlog of qa tools and technical debt to pay off right now that the details of fedora.next aren't required to make progress. The primary focus for now is replacing autoqa with taskotron. There are a lot of moving parts in a decent, generic automation system and the base for those parts need to be replaced at the same time or not at all. Regardless of what happens with Fedora.next, there is a real need for better automation support to start running more checks on packages and other output and the delay between f20 and f21 will give us the time we need to at least get the basics in place. As a concrete example, a package-level check was recently proposed to help detect scriptlet errors like the one that caused the SELinux issue with F20. That type of check is just not possible to run sanely in autoqa due to its host-destructive nature. While destructive checks aren't in scope for the initial deployment of taskotron, it is a feature that we're planning on. I believe that releng is in a similar position - lots of improvements on the wishlist but the regular release cadence prevents work on anything substantial. However, I can't speak to what their specific plans are for the delay between f20 and f21. Tim signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 06:12 PM, Lars Seipel wrote: > On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote: >> Also possibly correct. However, that doesn't preclude the repos >> as we know them today from still existing, with still the same >> quality. > > Server, desktop or embedded board, in today's Fedora it's all the > same, just with a different package set installed. People (not all, > obviously) consider this a good thing. I just have to put a minimal > Fedora install on some machine and then build it from there. > > That's what Tom was getting at, I think. The discussions in the WGs > so far have hinted that it's not necessarily a reasonable > expectation that this will continue to be the case. An oft-cited > reason was that RPMs apparently can't provide the 'integration' > that is somehow wanted. > > I always considered it nice that there's only a single Fedora. I > thought that split products were mostly an artefact of commercial > differentiation and so Fedora users don't have to deal with "you > can't use this filesystem unless you have the Ultra Enterprise > Storage Edition" or stuff like that. ☺ > I agree with you. My stated (and oft-repeated) position in the Server WG is that the available package sets should not diverge between the Products so far as is feasible. What I'd like to see is mainly that we allow a limited set of intentionally-conflicting packages in the repository that allow us to provide different default configurations for the products. So for any package that has a configuration that might want different defaults for Server vs. Workstation, we would have it produce two sub-packages, one for each sensible default. To take the DHCP example elsewhere in the thread, we could have: dhcp-config-default-on Provides: dhcp-config Conflicts: dhcp-config-default-off dhcp-config-default-off Provides: dhcp-config Conflicts: dhcp-config-default-on The dhcp package would Requires: dhcp-config (and therefore not care which one it gets). Then we would have a release package for Fedora Server and Fedora workstation that would specifically Requires: the appropriate one (so that when yum/dnf resolution occurs, the right one gets selected). e.g. fedora-release-server-21 Requires: dhcp-config-default-off fedora-release-workstation-21 Requires: dhcp-config-default-on On a related note, I'd also strongly like to recommend that we start using the fedora-release-*-VERSION packages as meta-packages that contain strict Requires: defining a minimum set of packages necessary to qualify as "Fedora Server", "Fedora Cloud" or "Fedora Workstation". So for example in the Fedora Server, this might be the minimum set of packages necessary to have a system with SSHD and the infrastructure to deploy Fedora Server Roles. On Fedora Workstation, perhaps it defines the set of packages conforming to GnomeOS 3.14. The idea would be that you'd still have the option to reduce the set of packages on the system, but at that point you would be voluntarily exiting the set of tested functionality. (And this would be checkable with a simple 'rpm -q' call) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLit/0ACgkQeiVVYja6o6ONGgCghQXjNgPDx7y0s482LpSSTBHz vrYAn3YjuqAlh+jwi+08OqYsZL/k0B2G =6pJp -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/23/2014 06:13 PM, Matthew Miller wrote: > On Thu, Jan 23, 2014 at 02:16:23PM -0800, Adam Williamson wrote: >> Read all the above sequentially. My point is that although you >> are technically correct that no WG has proposed doing away with >> the repos, the RPM format, or yum/dnf, their plans - under a >> reasonable interpretation of the discussions so far - still >> invalidate the assumptions he is currently making: he can no >> longer assume that all he basically has to worry about is getting >> 'Fedora' installed somehow and he can then install whatever he >> likes. Broadly stated, it will no longer be valid to conceive of >> Fedora as a large package repository with some installation >> methods attached to it, whereas currently that's a pretty >> reasonable conceptual framework that I believe many people (not >> just Tom) employ. >> >> In other words, Tom was really correct. ;) > > Well, maybe. It really is the case that nothing is finalized and > it's a legitimate concern. This is why we (and here I'm using "we" > not in the royal sense but because it really wasn't just _me_) have > the Base Design, not just three separate product working groups. I > share the trepidation about adding more bureaucracy, but also seems > pretty important to keep a coherent shared base. > > It's possible that eventually it'll be kind of hard to go from > Fedora Workstation to Fedora Cloud, or from Fedora Cloud to Fedora > Workstation -- but that's not _really_ so different from how it is > now, where if you start from one of those and try to go to the > other, you're going to have to tear down a bunch of things first. > On the other hand, the Cloud WG made the ability to go from Fedora > Cloud to Fedora Server an explicit goal. > > Either way, I think it's pretty likely that someone who wants to > start with the base and build up will be able to with, with varying > possible degrees of difficulty. It may also end up that it's easier > to make and share specific, lightweight remixes, so that while you > don't necessarily build up in an install, you do it in a tool of > some sort -- that was part of Stephen Gallagher's original > "products" idea, if I'm remembering right. > That was originally one of my moonshot ideas, yeah. I've subsequently toned down on trying to push for that as I've been told from several directions that this would put a significant strain on release-engineering. I think it's still worth looking into way to improve our existing tooling (and make spin-generation not suck so that we could make it easier for spins to evolve to products), but I've stopped trying to trumpet it as a primary objective. >>> So yes, there may very well be different options. That doesn't >>> mean they can't also be the same if you choose not to use those >>> different things. >> Is that going to be a reasonably sustainable approach, though? >> It's at least possible that it won't. What if the Desktop >> 'product' starts caring much about shipping commonly-used desktop >> applications as 'app bundles' rather than packages? What if the >> Server 'product' implements Wordpress as a container image rather >> than a package? > > That might happen, although I would be shocked if anyone has > anything near workable for F21 timeframe. Or F22. But, would it be > so bad? People who are interested in packaging it in the > traditional way still could... or, at least _I_ hope so -- that's > been part of my version of the proposal since the beginning. > For what it's worth, I still want (personally) for us to be deploying using RPM for its other abilities (like maintaining a useful inventory of software on the system). However, I'm not ruling out the possibility that we might be willing to start shipping RPMs inside the Fedora Repositories that contain inside them essentially a docker or qcow image that we then deploy into an isolated environment to actually implement the Role functionality. Yes, this would be a big divergence from our current guidelines and would need serious discussion on feasibility. No, I'm not asserting this is the right way to do things, merely one possible approach to consider. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLitJAACgkQeiVVYja6o6ONLQCgneb9p7asfW8t7Nc1nO4eYhyP xlsAniHrICryRNJ4A/2NXP62BD8/eJaG =3S7P -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Jan 24, 2014 10:29 AM, "Kevin Fenzi" wrote: > The things they are working on have been known for years, but our 6 > month release cycle with no hope of being able to work on tooling > hasn't allowed them to do so. Thanks for the clarification. I'm certainly on board with lengthening a release cycle to give them opportunity to improve the QA infrastructure, irrespective of Fedora.next. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Fri, 24 Jan 2014 09:58:07 -0700 Eric Smith wrote: > On Jan 23, 2014 2:33 PM, "Kevin Fenzi" wrote: > > This is not practical. Lots of people are thinking about a > > fedora.next, qa folks are coding away, lots of people who normally > > would be working on the next release are not. If we tell them to > > stop all that and go back to normal, we could, but then fedora.next > > will likely never ever happen. > [...] > > The current problem I have with Fedora.next is that it's so > > abstract. > > How are QA folks "coding away" for Fedora.next, rather than > traditional Fedora QA processes, if Fedora.next is "so abstract"? The things they are working on have been known for years, but our 6 month release cycle with no hope of being able to work on tooling hasn't allowed them to do so. So, things like replacing autoqa with taskotron, investigating beaker and other items are likely to be very helpful in both a fedora.next and a 'traditional' fedora world. I'll stop talking for them, feel free to join them on the qa-devel list and offer your help. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Jan 23, 2014 2:33 PM, "Kevin Fenzi" wrote: > > On Thu, 23 Jan 2014 19:03:02 +0100 > Thorsten Leemhuis wrote: > > I'm still undecided if I overall like Fedora.next or fear it. But more > > and more I tend to the latter position and wonder if it might be wise > > to slow things down: Do one more Fedora release the old style in round > > about June; that would give us more time to better discuss and work > > out Fedora.next and get contributors involved better in the planing. > > This is not practical. Lots of people are thinking about a > fedora.next, qa folks are coding away, lots of people who normally > would be working on the next release are not. If we tell them to stop > all that and go back to normal, we could, but then fedora.next will > likely never ever happen. [...] > The current problem I have with Fedora.next is that it's so abstract. How are QA folks "coding away" for Fedora.next, rather than traditional Fedora QA processes, if Fedora.next is "so abstract"? I still don't understand what the Fedora.next "Products" accomplish that Spins don't/can't. Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Colin Walters wrote: >People have been constantly confused by whether "Fedora" does DHCP by >default over the years, because we've flipped it several times. When >we introduced it for clients/workstations, I consider it to have been a >*massive* win to be able to plug in an ethernet cable and have it Just >Work. Absolutely. That's the whole point of DHCP. >But it's very much the wrong thing to do for traditional servers where >you have 4 or more physical NICs. I don't see why. Either DHCP is the right thing, or else the admin is going to configure the NICs immediately and then it doesn't matter what the default is. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 23/01/14 18:48, Josh Boyer wrote: On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes wrote: Even the formation of the working groups was odd - the original decision to form them, as I read it, was that they were to explore the idea of doing these three streams but within days it seemed that the question was no longer whether to do them but rather how to do them. I can see how that would be confusing. I always understood it to be "these WGs will be formed and they will be tasked with figuring out how to create their respective products". Perhaps some lack of clarity in the proposal? I've been digging back through the list archives and various other sources trying to determine where my view of this was founded, but not with a hug amount of success so far. The best I have come up with is your report to the list of the board's decision: https://lists.fedoraproject.org/pipermail/devel/2013-August/187784.html Where we are told that the board "agree with the development of a working group to describe an implementation proposal for the future of Fedora" which sounds like the idea is to make a proposal for how to do things in the future, which might then be accepted or rejected. By the time Fesco is discussing the creation of those groups (for it has now become multiple groups) a week or two later the proposal the groups are being asked to create is not a proposal as to whether to change but rather a proposal for the specific way to do the change. In other words the question seems to have changed from "whether to do it" to "how to do it". Of course this is all reading a lot into that one initial sentence in your email. I think there were probably other things that helped build that view in my mind at the time but I can't find them right now. That's why I got the feeing a lot of contributors are simply waiting for more concrete details to emerge before deciding what to make of Fedora.next; or they simply at all don't care to much what the higher ups do, as getting involved on that level can cost quite a lot of time and can be frustrating (that's not a complaint, that's simply how it is often; wasn't much different in my days, but noticed that more when I wasn't that active an more myself). If they are waiting, what are they waiting for? If they don't care, and they just want to maintain a package or 30 packages, is there anything that you see in Fedora.next that would prevent them from doing that? There will always be varied level of participation, and I think we need to have a development model that encourages that and allows for growth. I don't think Fedora.next gets in the way of that, but I would love to have other opinions. To be honest my concerns are more with my user hat on than my contributor hat - that we will lose the gold standard unified packaging standards and single source and mechanism for installing packages. I haven't seen anything from any WG that would suggest a deviation from RPM packaging guidelines or using separate repositories. It is a valid concern and one we need to keep an eye on. Once again the facts don't entirely seem to chime with my memory... My memory was that each WG had been explicitly told that they could propose alternative packaging guidelines for their products. In fact a review of the original call for WG nominations suggests that only the end and stacks group were given that freedom, specifically they were tasked: "to work on policies and practices for software operating outside of Fedora's traditional packaging model Of course if you see env and stacks as sitting between base and the three product groups then that effectively impacts on all the products because if they start encouraging alternative packaging and policies then the product groups may use that and render it effectively impossible to run anything beyond a barebones system using the traditional Fedora model. A lot of the time I will have been reading all of these things coloured by knowing that they derive from the original Fedora.next proposal which appeared to be all about weakening packing guidelines and making it easier to shove stuff in and to encourage use of various upstream packaging systems in place of Fedora packaging. So there will have been an assumption in my mind that the real agenda all the time is to do that. Certainly that is still pretty much how I see the env and stacks group and that is certainly where my major concerns lie. The actual spins (or whatever you want to call them) aren't something that bother me at all, as they are to my mind largely irrelevant for anybody other than a new user. When I bring a new machine up I just want to get a base OS on and access to the package repository and what packages are installed by default doesn't really bother me. So... Fedora.next is essentially irrelevant to you? That's OK, it doesn't have to be relevant to everyone. And meeting the needs of existing users is definitely
Re: Fedora.next in 2014 -- Big Picture and Themes
On Fri, 2014-01-24 at 00:12 +0100, Lars Seipel wrote: > On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote: > > Also possibly correct. However, that doesn't preclude the repos as we > > know them today from still existing, with still the same quality. > > Server, desktop or embedded board, in today's Fedora it's all the same, > just with a different package set installed. People (not all, obviously) > consider this a good thing. Yes, but there are definite downsides to that. For example: https://bugzilla.redhat.com/show_bug.cgi?id=978081 People have been constantly confused by whether "Fedora" does DHCP by default over the years, because we've flipped it several times. When we introduced it for clients/workstations, I consider it to have been a *massive* win to be able to plug in an ethernet cable and have it Just Work. But it's very much the wrong thing to do for traditional servers where you have 4 or more physical NICs. (It ironically is back to being the right default for cloud guests) It's precisely this sort of thing that we can fix with the "multiple products" design. Now, the technical details behind product implementation matters a lot. If we're just saying they have different RPM sets, then it's certainly not hard to put NetworkManager-config-server in a "Server" comps group. But what should "minimal" do? One thing I think is cool about OSTree with respect to this problem domain - it allows each product to have *different* defaults for /etc (and /usr). And when you switch between trees, if you haven't changed the relevant file in /etc, you get the new default. Concretely, if you switch from fedostree/20/x86_64/workstation/gnome/core to fedostree/20/x86_64/server/docker-io you would *stop* doing DHCP by default. Or you will in a few hours after the next rpm-ostree rebuild, since I just pushed https://github.com/cgwalters/rpm-ostree/commit/514b73c944e8b07b3a627e50d44c900f7423fb1e =) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Josh Boyer (jwbo...@fedoraproject.org) said: > I wasn't being dismissive. I have seen no plans to alter the core of > how Fedora, at a package level, is built. In fact, if I did see a > proposal that said "we're not going to ship repositories or RPMs" I'd > be pretty damned upset, and I wouldn't support that. To be fair, I do recall Matt's original rings proposal discussing a core, different stacks on top of that, a 'commons' repository of packages, and things like COPRs on the outside. While it's not proposing moving away from repositories or RPMs, I did read that proposal as moving away from the current paradigm of One Big Repo Of Everything in favor of potentially multiple smaller repos. In that paradigm, things would change somewhat for users even if they were ignoring the N products. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 23:50 +0100, drago01 wrote: > On Thu, Jan 23, 2014 at 11:38 PM, Adam Williamson wrote: > > On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote: > > > >> > No, I don't disagree with you there. But the repos don't exist in a > >> > vacuum. Right now they are our way of shipping software in Fedora: our > >> > *only* way. If you want to install the Fedora-y version of a particular > >> > piece of software, you use the repositories. End of story. > >> > >> I can do "gem install foo" or "pip install foo" on current (and past) > >> fedora releases. > >> So no the story does not quite end here ;) > > > > Those are not Fedora-provided software. At the point you install and > > invoke gem or pip, you are making an explicit decision to use non-Fedora > > software. Which is, of course, perfectly fine: but it's not an analogous > > situation to there being alternative distribution methods *within the > > Fedora distribution*. > > Sure but people do that. We can either pretend they don't or try to > somehow deal with it. Currently we are exploring ways to deal with it. You're pivoting the discussion quite extensively at this point, and I'm not really sure you're pivoting it down an interesting path. Nothing I said, so far as I can see, implied that I'm endorsing "pretending people don't do that", nor do I think that's a reasonable characterization of the current situation. I'll just leave this fork there. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 02:16:23PM -0800, Adam Williamson wrote: > Read all the above sequentially. My point is that although you are > technically correct that no WG has proposed doing away with the repos, > the RPM format, or yum/dnf, their plans - under a reasonable > interpretation of the discussions so far - still invalidate the > assumptions he is currently making: he can no longer assume that all he > basically has to worry about is getting 'Fedora' installed somehow and > he can then install whatever he likes. Broadly stated, it will no longer > be valid to conceive of Fedora as a large package repository with some > installation methods attached to it, whereas currently that's a pretty > reasonable conceptual framework that I believe many people (not just > Tom) employ. > > In other words, Tom was really correct. ;) Well, maybe. It really is the case that nothing is finalized and it's a legitimate concern. This is why we (and here I'm using "we" not in the royal sense but because it really wasn't just _me_) have the Base Design, not just three separate product working groups. I share the trepidation about adding more bureaucracy, but also seems pretty important to keep a coherent shared base. It's possible that eventually it'll be kind of hard to go from Fedora Workstation to Fedora Cloud, or from Fedora Cloud to Fedora Workstation -- but that's not _really_ so different from how it is now, where if you start from one of those and try to go to the other, you're going to have to tear down a bunch of things first. On the other hand, the Cloud WG made the ability to go from Fedora Cloud to Fedora Server an explicit goal. Either way, I think it's pretty likely that someone who wants to start with the base and build up will be able to with, with varying possible degrees of difficulty. It may also end up that it's easier to make and share specific, lightweight remixes, so that while you don't necessarily build up in an install, you do it in a tool of some sort -- that was part of Stephen Gallagher's original "products" idea, if I'm remembering right. > > So yes, there may very well be different options. That doesn't mean > > they can't also be the same if you choose not to use those different > > things. > Is that going to be a reasonably sustainable approach, though? It's at > least possible that it won't. What if the Desktop 'product' starts > caring much about shipping commonly-used desktop applications as 'app > bundles' rather than packages? What if the Server 'product' implements > Wordpress as a container image rather than a package? That might happen, although I would be shocked if anyone has anything near workable for F21 timeframe. Or F22. But, would it be so bad? People who are interested in packaging it in the traditional way still could... or, at least _I_ hope so -- that's been part of my version of the proposal since the beginning. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote: > Also possibly correct. However, that doesn't preclude the repos as we > know them today from still existing, with still the same quality. Server, desktop or embedded board, in today's Fedora it's all the same, just with a different package set installed. People (not all, obviously) consider this a good thing. I just have to put a minimal Fedora install on some machine and then build it from there. That's what Tom was getting at, I think. The discussions in the WGs so far have hinted that it's not necessarily a reasonable expectation that this will continue to be the case. An oft-cited reason was that RPMs apparently can't provide the 'integration' that is somehow wanted. I always considered it nice that there's only a single Fedora. I thought that split products were mostly an artefact of commercial differentiation and so Fedora users don't have to deal with "you can't use this filesystem unless you have the Ultra Enterprise Storage Edition" or stuff like that. ☺ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Am 23.01.2014 23:49, schrieb drago01: > On Thu, Jan 23, 2014 at 11:46 PM, Reindl Harald > wrote: >> >> Am 23.01.2014 23:37, schrieb drago01: >>> On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson >>> wrote: No, I don't disagree with you there. But the repos don't exist in a vacuum. Right now they are our way of shipping software in Fedora: our *only* way. If you want to install the Fedora-y version of a particular piece of software, you use the repositories. End of story. >>> >>> I can do "gem install foo" or "pip install foo" on current (and past) >>> fedora releases. >>> So no the story does not quite end here ;) >> >> there is a difference if you *want* do so or *forced* to do so >> because there is no longer a *single* and consistent package >> source what is over years and still *THE* greath strength of >> a linux *distribution* > > No one is proposing to force anyone to do anything so stop the FUD please where in the world do you see FUD? if a software is packed "the new way" and no longer available in the classical repos as RPM you are forced to use whatever to install the package this way instead of a single source like YUM what about consider the result of changes over the long instead insinuate someone is spreading FUD with no reason to do so signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 11:38 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote: > >> > No, I don't disagree with you there. But the repos don't exist in a >> > vacuum. Right now they are our way of shipping software in Fedora: our >> > *only* way. If you want to install the Fedora-y version of a particular >> > piece of software, you use the repositories. End of story. >> >> I can do "gem install foo" or "pip install foo" on current (and past) >> fedora releases. >> So no the story does not quite end here ;) > > Those are not Fedora-provided software. At the point you install and > invoke gem or pip, you are making an explicit decision to use non-Fedora > software. Which is, of course, perfectly fine: but it's not an analogous > situation to there being alternative distribution methods *within the > Fedora distribution*. Sure but people do that. We can either pretend they don't or try to somehow deal with it. Currently we are exploring ways to deal with it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 11:46 PM, Reindl Harald wrote: > > Am 23.01.2014 23:37, schrieb drago01: >> On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson >> wrote: >>> No, I don't disagree with you there. But the repos don't exist in a >>> vacuum. Right now they are our way of shipping software in Fedora: our >>> *only* way. If you want to install the Fedora-y version of a particular >>> piece of software, you use the repositories. End of story. >> >> I can do "gem install foo" or "pip install foo" on current (and past) >> fedora releases. >> So no the story does not quite end here ;) > > there is a difference if you *want* do so or *forced* to do so > because there is no longer a *single* and consistent package > source what is over years and still *THE* greath strength of > a linux *distribution* No one is proposing to force anyone to do anything so stop the FUD please. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Am 23.01.2014 23:37, schrieb drago01: > On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson wrote: >> No, I don't disagree with you there. But the repos don't exist in a >> vacuum. Right now they are our way of shipping software in Fedora: our >> *only* way. If you want to install the Fedora-y version of a particular >> piece of software, you use the repositories. End of story. > > I can do "gem install foo" or "pip install foo" on current (and past) > fedora releases. > So no the story does not quite end here ;) there is a difference if you *want* do so or *forced* to do so because there is no longer a *single* and consistent package source what is over years and still *THE* greath strength of a linux *distribution* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 23:37 +0100, drago01 wrote: > > No, I don't disagree with you there. But the repos don't exist in a > > vacuum. Right now they are our way of shipping software in Fedora: our > > *only* way. If you want to install the Fedora-y version of a particular > > piece of software, you use the repositories. End of story. > > I can do "gem install foo" or "pip install foo" on current (and past) > fedora releases. > So no the story does not quite end here ;) Those are not Fedora-provided software. At the point you install and invoke gem or pip, you are making an explicit decision to use non-Fedora software. Which is, of course, perfectly fine: but it's not an analogous situation to there being alternative distribution methods *within the Fedora distribution*. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 11:34 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 17:26 -0500, Josh Boyer wrote: > >> > Read all the above sequentially. My point is that although you are >> > technically correct that no WG has proposed doing away with the repos, >> > the RPM format, or yum/dnf, their plans - under a reasonable >> > interpretation of the discussions so far - still invalidate the >> > assumptions he is currently making: he can no longer assume that all he >> > basically has to worry about is getting 'Fedora' installed somehow and >> > he can then install whatever he likes. Broadly stated, it will no longer >> > be valid to conceive of Fedora as a large package repository with some >> > installation methods attached to it, whereas currently that's a pretty >> > reasonable conceptual framework that I believe many people (not just >> > Tom) employ. >> > >> > In other words, Tom was really correct. ;) >> >> I don't see how you come to that conclusion, at least not without >> making some large assumptions. The addition of alternate solutions >> for package installation and deployment doesn't preclude people from >> being able to install Fedora and use the underlying tools to point to >> the existing repos. > > No, I don't disagree with you there. But the repos don't exist in a > vacuum. Right now they are our way of shipping software in Fedora: our > *only* way. If you want to install the Fedora-y version of a particular > piece of software, you use the repositories. End of story. I can do "gem install foo" or "pip install foo" on current (and past) fedora releases. So no the story does not quite end here ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 17:26 -0500, Josh Boyer wrote: > > Read all the above sequentially. My point is that although you are > > technically correct that no WG has proposed doing away with the repos, > > the RPM format, or yum/dnf, their plans - under a reasonable > > interpretation of the discussions so far - still invalidate the > > assumptions he is currently making: he can no longer assume that all he > > basically has to worry about is getting 'Fedora' installed somehow and > > he can then install whatever he likes. Broadly stated, it will no longer > > be valid to conceive of Fedora as a large package repository with some > > installation methods attached to it, whereas currently that's a pretty > > reasonable conceptual framework that I believe many people (not just > > Tom) employ. > > > > In other words, Tom was really correct. ;) > > I don't see how you come to that conclusion, at least not without > making some large assumptions. The addition of alternate solutions > for package installation and deployment doesn't preclude people from > being able to install Fedora and use the underlying tools to point to > the existing repos. No, I don't disagree with you there. But the repos don't exist in a vacuum. Right now they are our way of shipping software in Fedora: our *only* way. If you want to install the Fedora-y version of a particular piece of software, you use the repositories. End of story. All I'm saying is that the .next proposals at least seem to be introducing the possibility that that will no longer be the case. i.e., the possibility that there will be software within the Fedora (distribution, not project) ecosystem that you cannot deploy using our package tools and package repositories. It would of course be *possible* for someone to duplicate any work done by any of the WGs in the repositories, but it is not *guaranteed* that this happens. If the desktop WG decides to start shipping some apps as bundles not packages, and no-one takes up the work of duplicating that effort in the repositories, then the situation is different to how it is now: you can no longer rely on the idea that all 'Fedora provided software' is in the repository system. You must choose between doing whatever it is you have to do to access the alternative/secondary distribution methods - which I agree it's not worth speculating about yet - or not having access to all 'Fedora provided software'. That's all I'm saying. I'm not drawing any kinds of conclusions from this: my goal is only to ensure that all implications of possible choices here are considered. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 5:16 PM, Adam Williamson wrote: > quoting simplified: >>> is Tom Hughes, >> is me, > is Josh. Restored > part of Tom's original context. > >>> > The actual spins (or whatever you want to call them) aren't something >>> > that bother me at all, as they are to my mind largely irrelevant for >>> > anybody other than a new user. When I bring a new machine up I just want >>> > to get a base OS on and access to the package repository and what >>> > packages are installed by default doesn't really bother me. > >> > > To be honest my concerns are more with my user hat on than my contributor >> > > hat - that we will lose the gold standard unified packaging standards and >> > > single source and mechanism for installing packages. > >> > If these plans go ahead, we will have multiple official/blessed methods >> > for deploying software on Fedora, potentially with different policies >> > about what software they can include and how that software should be >> > arranged, how dependencies should be handled, and all the rest of it. >> > Some of these methods will be shared between products, and some will >> > either only exist in certain products, or at least be clearly associated >> > with and 'owned' by those products. >> >> Also possibly correct. However, that doesn't preclude the repos as we >> know them today from still existing, with still the same quality. > > Read all the above sequentially. My point is that although you are > technically correct that no WG has proposed doing away with the repos, > the RPM format, or yum/dnf, their plans - under a reasonable > interpretation of the discussions so far - still invalidate the > assumptions he is currently making: he can no longer assume that all he > basically has to worry about is getting 'Fedora' installed somehow and > he can then install whatever he likes. Broadly stated, it will no longer > be valid to conceive of Fedora as a large package repository with some > installation methods attached to it, whereas currently that's a pretty > reasonable conceptual framework that I believe many people (not just > Tom) employ. > > In other words, Tom was really correct. ;) I don't see how you come to that conclusion, at least not without making some large assumptions. The addition of alternate solutions for package installation and deployment doesn't preclude people from being able to install Fedora and use the underlying tools to point to the existing repos. > >> As >> far as I'm aware, the products are still planning on being built from >> packages provided by the Fedora project, from the Fedora buildsystem. >> >> So yes, there may very well be different options. That doesn't mean >> they can't also be the same if you choose not to use those different >> things. > > Is that going to be a reasonably sustainable approach, though? It's at > least possible that it won't. What if the Desktop 'product' starts > caring much about shipping commonly-used desktop applications as 'app > bundles' rather than packages? What if the Server 'product' implements > Wordpress as a container image rather than a package? What if, what if, what if. Yes, all possible. Also possible is that we punt on the whole idea. This is the point where we diverge. I do not see value in somehow saying things will be different and one _cannot_ still do things they do today with no indication that such a world is even planned. You seem to be very cautionary of the whole thing. Neither view is wrong. >> I understand your concern and it's something worth watching, >> but I don't think it's a foregone conclusion that things will be >> horrible or users will be forced to give up RPMs and repos. >> >> josh > > I certainly agree that it's not a foregone conclusion, and I don't think > I suggested it was, but your initial email seemed to more or less > entirely dismiss the possibility, and I don't think that's warranted. I wasn't being dismissive. I have seen no plans to alter the core of how Fedora, at a package level, is built. In fact, if I did see a proposal that said "we're not going to ship repositories or RPMs" I'd be pretty damned upset, and I wouldn't support that. At this point I think our conversation is going to cease being productive, but I do believe it's been productive thus far. Thanks! josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
quoting simplified: >>> is Tom Hughes, >> is me, > is Josh. Restored part of Tom's original context. >> > The actual spins (or whatever you want to call them) aren't something >> > that bother me at all, as they are to my mind largely irrelevant for >> > anybody other than a new user. When I bring a new machine up I just want >> > to get a base OS on and access to the package repository and what >> > packages are installed by default doesn't really bother me. > > > To be honest my concerns are more with my user hat on than my contributor > > > hat - that we will lose the gold standard unified packaging standards and > > > single source and mechanism for installing packages. > > If these plans go ahead, we will have multiple official/blessed methods > > for deploying software on Fedora, potentially with different policies > > about what software they can include and how that software should be > > arranged, how dependencies should be handled, and all the rest of it. > > Some of these methods will be shared between products, and some will > > either only exist in certain products, or at least be clearly associated > > with and 'owned' by those products. > > Also possibly correct. However, that doesn't preclude the repos as we > know them today from still existing, with still the same quality. Read all the above sequentially. My point is that although you are technically correct that no WG has proposed doing away with the repos, the RPM format, or yum/dnf, their plans - under a reasonable interpretation of the discussions so far - still invalidate the assumptions he is currently making: he can no longer assume that all he basically has to worry about is getting 'Fedora' installed somehow and he can then install whatever he likes. Broadly stated, it will no longer be valid to conceive of Fedora as a large package repository with some installation methods attached to it, whereas currently that's a pretty reasonable conceptual framework that I believe many people (not just Tom) employ. In other words, Tom was really correct. ;) > As > far as I'm aware, the products are still planning on being built from > packages provided by the Fedora project, from the Fedora buildsystem. > > So yes, there may very well be different options. That doesn't mean > they can't also be the same if you choose not to use those different > things. Is that going to be a reasonably sustainable approach, though? It's at least possible that it won't. What if the Desktop 'product' starts caring much about shipping commonly-used desktop applications as 'app bundles' rather than packages? What if the Server 'product' implements Wordpress as a container image rather than a package? > I understand your concern and it's something worth watching, > but I don't think it's a foregone conclusion that things will be > horrible or users will be forced to give up RPMs and repos. > > josh I certainly agree that it's not a foregone conclusion, and I don't think I suggested it was, but your initial email seemed to more or less entirely dismiss the possibility, and I don't think that's warranted. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 23 January 2014 14:14, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 3:53 PM, Stephen John Smoogen > wrote: > > > My view of the matter was pretty much the same as Tom's and I was at > FLOCK. > > The language at the sessions I attended was not one of "We would like to > do > > this" but that it was a done thing. I realize a lot of that is the 'get > shit > > done because we are all together' mentality which comes from conferences > but > > by the time I left FLOCK I was pretty sure this was all done and either > get > > in the boat or get out. I wasn't even aware of the FESCO items until this > > email as I figured it had been done and decided at FLOCK. > > If one is advocating for something they strongly believe in, they > definitely are not going to say "I think maybe we should do this kinda > but it might be a crazy idea." They advocate by saying "I am going to > do this and I am going to drive it forward until I am told no." That > doesn't mean they can just skip all the processes and steps required > to get their idea approved. > > I would be a lot happier if people actually did have some humility and at least went with 'this might be a crazy idea but I am doing the following and I would like people to try it out' and actually listening to the people who did try it out. Instead we have a lot of 'I have written X and it is what we will be using in the next release'. and then wonder why the hell we cut our install and contributor base after that next release. > Boostrapping is hard. I didn't come up with the idea and this might > not have been the best way to do it, but hindsight is 20/20. I do > hope that if you are interested in a WG/Product that you do > participate because the governance for them is set up and will allow > different WG members going forward. I've also seen lots of non-member > participation be really fruitful already. > > I do not doubt that non-member participation has been fruitful. At this point of the proceedings most of my time is spent hitting the 'd' key because my responses would not be fruitful and in a couple of cases, career limiting. You people don't need any more of that negativity, you already have enough. Once people get to the the technical side of how to accomplish possibly 4 times the work with RPMS and alternate packages on the same or less hardware and disk space.. then it becomes an interesting problem to me where I can contribute. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 4:57 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote: >> On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson wrote: >> > On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: >> > >> >> > To be honest my concerns are more with my user hat on than my >> >> > contributor >> >> > hat - that we will lose the gold standard unified packaging standards >> >> > and >> >> > single source and mechanism for installing packages. >> >> >> >> I haven't seen anything from any WG that would suggest a deviation >> >> from RPM packaging guidelines or using separate repositories. It is a >> >> valid concern and one we need to keep an eye on. >> > >> > Um. As I read it, three out of four WGs - desktop, server, and cloud - >> > have at least discussed the possibility of implementing what are, in >> > essence, secondary package management layers. The details differ - 'app >> > bundles' for desktop, 'containers' or whatever for server and cloud - >> > but the effect is the same. >> >> Secondary being the key word. None of them are proposing alternate >> RPM repositories or changing the Fedora packaging guidelines. Tom was >> expressing that he is concerned the Fedora repos would go away or be >> of decreased quality. None of the WG proposals are altering those >> repos. They will still exist, much as they do today. > > The repos will still exist, but things will be different. At present, > the Fedora repos are the single unified official Fedora method for > deploying software on Fedora products. Any other method you can use to > deploy software is not an 'official Fedora' thing. Correct. > If these plans go ahead, we will have multiple official/blessed methods > for deploying software on Fedora, potentially with different policies > about what software they can include and how that software should be > arranged, how dependencies should be handled, and all the rest of it. > Some of these methods will be shared between products, and some will > either only exist in certain products, or at least be clearly associated > with and 'owned' by those products. Also possibly correct. However, that doesn't preclude the repos as we know them today from still existing, with still the same quality. As far as I'm aware, the products are still planning on being built from packages provided by the Fedora project, from the Fedora buildsystem. So yes, there may very well be different options. That doesn't mean they can't also be the same if you choose not to use those different things. I understand your concern and it's something worth watching, but I don't think it's a foregone conclusion that things will be horrible or users will be forced to give up RPMs and repos. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 01:57:38PM -0800, Adam Williamson wrote: > If these plans go ahead, we will have multiple official/blessed methods > for deploying software on Fedora, potentially with different policies > about what software they can include and how that software should be > arranged, how dependencies should be handled, and all the rest of it. > Some of these methods will be shared between products, and some will > either only exist in certain products, or at least be clearly associated > with and 'owned' by those products. I think this is possible -- even hopeful -- but I also don't think it's in the immediate future, because there's nothing in place to make it actually really work, let alone work well. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 23 Jan 2014 13:57:38 -0800 Adam Williamson wrote: > The repos will still exist, but things will be different. At present, > the Fedora repos are the single unified official Fedora method for > deploying software on Fedora products. Any other method you can use to > deploy software is not an 'official Fedora' thing. > > If these plans go ahead, we will have multiple official/blessed > methods for deploying software on Fedora, potentially with different > policies about what software they can include and how that software > should be arranged, how dependencies should be handled, and all the > rest of it. Some of these methods will be shared between products, > and some will either only exist in certain products, or at least be > clearly associated with and 'owned' by those products. Well, there's no details to see that yet. There's lots of ideas around those things, but any detailed discussion I have seen has resulted in "thats implementation details, lets keep the PRD high level". Or "we could use docker or SCLs or just rpms for this" with no proposal. So, perhaps in the coming month we will actually see concrete proposals around how to use these methods and can actually discuss them. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson wrote: > > On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: > > > >> > To be honest my concerns are more with my user hat on than my contributor > >> > hat - that we will lose the gold standard unified packaging standards and > >> > single source and mechanism for installing packages. > >> > >> I haven't seen anything from any WG that would suggest a deviation > >> from RPM packaging guidelines or using separate repositories. It is a > >> valid concern and one we need to keep an eye on. > > > > Um. As I read it, three out of four WGs - desktop, server, and cloud - > > have at least discussed the possibility of implementing what are, in > > essence, secondary package management layers. The details differ - 'app > > bundles' for desktop, 'containers' or whatever for server and cloud - > > but the effect is the same. > > Secondary being the key word. None of them are proposing alternate > RPM repositories or changing the Fedora packaging guidelines. Tom was > expressing that he is concerned the Fedora repos would go away or be > of decreased quality. None of the WG proposals are altering those > repos. They will still exist, much as they do today. The repos will still exist, but things will be different. At present, the Fedora repos are the single unified official Fedora method for deploying software on Fedora products. Any other method you can use to deploy software is not an 'official Fedora' thing. If these plans go ahead, we will have multiple official/blessed methods for deploying software on Fedora, potentially with different policies about what software they can include and how that software should be arranged, how dependencies should be handled, and all the rest of it. Some of these methods will be shared between products, and some will either only exist in certain products, or at least be clearly associated with and 'owned' by those products. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson wrote: > On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: > >> > To be honest my concerns are more with my user hat on than my contributor >> > hat - that we will lose the gold standard unified packaging standards and >> > single source and mechanism for installing packages. >> >> I haven't seen anything from any WG that would suggest a deviation >> from RPM packaging guidelines or using separate repositories. It is a >> valid concern and one we need to keep an eye on. > > Um. As I read it, three out of four WGs - desktop, server, and cloud - > have at least discussed the possibility of implementing what are, in > essence, secondary package management layers. The details differ - 'app > bundles' for desktop, 'containers' or whatever for server and cloud - > but the effect is the same. Secondary being the key word. None of them are proposing alternate RPM repositories or changing the Fedora packaging guidelines. Tom was expressing that he is concerned the Fedora repos would go away or be of decreased quality. None of the WG proposals are altering those repos. They will still exist, much as they do today. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: > > To be honest my concerns are more with my user hat on than my contributor > > hat - that we will lose the gold standard unified packaging standards and > > single source and mechanism for installing packages. > > I haven't seen anything from any WG that would suggest a deviation > from RPM packaging guidelines or using separate repositories. It is a > valid concern and one we need to keep an eye on. Um. As I read it, three out of four WGs - desktop, server, and cloud - have at least discussed the possibility of implementing what are, in essence, secondary package management layers. The details differ - 'app bundles' for desktop, 'containers' or whatever for server and cloud - but the effect is the same. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote: > wikipedia page. Further: kororaproject.org, fedorautils-installer and > similar project show that there are people that want to make Fedora > better. But they do their work outside of Fedora and RPM Fusion; > fixing the issues directly at the root would be better for all of us. Those particular examples are very bad examples because they are doing things Fedora explicitly chooses not to do, for *philosophical* not *practical* reasons (a choice the Board has re-affirmed this morning). Korora is hardly a 'Fedora is doing silly stuff, let's fork it' project - as per this statement on their site: "Ultimately, we want people just like you to become useful members of the Fedora community and we hope that trying Korora will be a catalyst for this." And the lead Korora dev is an active Fedora contributor. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 2014-01-23 at 19:03 +0100, Thorsten Leemhuis wrote: > Hi! > > On 03.01.2014 19:14, Matthew Miller wrote: > > […] So those are my things. What do you think about them? What > > else should be included? What different directions should we > > consider? How will we make Fedora more awesome than ever in the > > coming year? > > Okay, I'll bite (after thinking whether writing this mail is worth it): > > I'm still undecided if I overall like Fedora.next or fear it. But more > and more I tend to the latter position and wonder if it might be wise > to slow things down: Do one more Fedora release the old style in round > about June; NO NO NO NO NO NO OH CHRIST NO. Actually, I agree with quite a lot of what you're saying; I think 21 is too early for this .next stuff and have done for a while. But that doesn't mean that if we punt .next we can release in June. Several teams have been working on the explicit understanding - as agreed by FESCo at an earlier meeting - that F21 will not be released until, at the earliest, late August *no matter what happens*. We cannot change that to June now. It would cause extreme inconvenience for QA and other teams, which in turn would result in a bad release. I'm fine with punting on .next, but I am absolutely not fine with releasing in June. Even if F21 is an old-school release, it needs to be in late August or later, as has already explicitly been stated. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, 23 Jan 2014 19:03:02 +0100 Thorsten Leemhuis wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi! > > On 03.01.2014 19:14, Matthew Miller wrote: > > […] So those are my things. What do you think about them? What > > else should be included? What different directions should we > > consider? How will we make Fedora more awesome than ever in the > > coming year? > > Okay, I'll bite (after thinking whether writing this mail is worth > it): Hey Thorsten! Glad you did. ;) > I'm still undecided if I overall like Fedora.next or fear it. But more > and more I tend to the latter position and wonder if it might be wise > to slow things down: Do one more Fedora release the old style in round > about June; that would give us more time to better discuss and work > out Fedora.next and get contributors involved better in the planing. This is not practical. Lots of people are thinking about a fedora.next, qa folks are coding away, lots of people who normally would be working on the next release are not. If we tell them to stop all that and go back to normal, we could, but then fedora.next will likely never ever happen. > The main reason for that: Fedora.next is a huge effort that seems to > make everything even more complicated. It imho is also sold pretty > badly right now, as you have to invest quite a lot of time to > understand what Fedora.next actually is. And Fedora.next to me seems > like something the core contributors push forward without having > really abort those Fedora contributors who don't have Fedora as one of > their top priorities in life. ...snip... So, I'll share my thoughts on it here, seems like a good place. :) The current problem I have with Fedora.next is that it's so abstract. I understand that people who like PRD's and TPS want high level descriptions of what we want to do with goals and visions and such, and thats great. However, I'm a technical person. I like concrete plans and pushing what we can do with the technology we have at hand, or helping to make new technology to do what we want. We are now down to the point where groups have written up their PRD documents, and can get down to details. So, I am hopeful in the next month or so we will gain a lot more interest in fedora.next and more feedback as concrete deliverables are discussed, etc. That is my hope at least... we will see. :) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 7:03 PM, Thorsten Leemhuis wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi! > > On 03.01.2014 19:14, Matthew Miller wrote: >> […] So those are my things. What do you think about them? What >> else should be included? What different directions should we >> consider? How will we make Fedora more awesome than ever in the >> coming year? > > Okay, I'll bite (after thinking whether writing this mail is worth it): > > I'm still undecided if I overall like Fedora.next or fear it. But more > and more I tend to the latter position and wonder if it might be wise > to slow things down: Do one more Fedora release the old style in round > about June; that would give us more time to better discuss and work > out Fedora.next and get contributors involved better in the planing. Actually this makes sense we are currently do not even have a schedule because to many stuff is just undefined. Maybe this should be a formal proposal for FESCo to consider. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 3:53 PM, Stephen John Smoogen wrote: > > > > On 23 January 2014 11:48, Josh Boyer wrote: >> >> On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes wrote: >> >> > Personally I think a lot of it has to do with the way the whole thing >> > seemed >> > to be a fait accompli such that there seemed to be little point doing >> > anything other than sitting back and seeing what happened. >> > >> > You know, the way one minute it was just a suggestion from one member of >> > the >> > community and the next minute it was all decided and people were busy >> > forming working groups to sort out the details. Apparently that >> > miraculous >> > transition happened at Flock, but for anybody that wasn't there it was >> > as if >> > it was a god given edict that had been handed down on tablets of stone >> > that >> > Fedora.next was happening and we should all just be good little children >> > and >> > get on with it. >> >> There _was_ a lot that was discussed and presented at Flock. It's >> kind of the purpose of Flock (and FUDCon before that). Get people >> together to have big discussions in a high bandwith fashion. And yes, >> that can mean that those not in attendance are left to catch up a bit >> (though at least with Flock we tried to stream all the sessions to >> help with that). >> >> However, it wasn't decided at Flock. It was presented after Flock to >> FESCo, in the normal, online FESCo meetings. It went further from >> there to the Board via the usual channels. All of this was done as >> any other proposal would normally be handled. Perhaps the only >> unusual thing was the relative lack of debate and delay. >> > > My view of the matter was pretty much the same as Tom's and I was at FLOCK. > The language at the sessions I attended was not one of "We would like to do > this" but that it was a done thing. I realize a lot of that is the 'get shit > done because we are all together' mentality which comes from conferences but > by the time I left FLOCK I was pretty sure this was all done and either get > in the boat or get out. I wasn't even aware of the FESCO items until this > email as I figured it had been done and decided at FLOCK. If one is advocating for something they strongly believe in, they definitely are not going to say "I think maybe we should do this kinda but it might be a crazy idea." They advocate by saying "I am going to do this and I am going to drive it forward until I am told no." That doesn't mean they can just skip all the processes and steps required to get their idea approved. So yes, I think for this specific item it was the "get stuff done" mentality that might have been misleading. The ideas were still carried forward per process though. > Fedora.NEXT became irrelevant to me when I realized the committees were > mostly hand-chosen versus elected like FESCO. I realize that was to get > stuff done versus having a bunch of bureaucratci elections, but it snuffed > whatever 'joy' I was going to have to participate in as a 'non-voting' > member of a committee. The best way for me to allow the people to get work > they wanted to get done was to get out of the way, and so I have. Now that I > am asked why I am not enthused, I am explaining. Boostrapping is hard. I didn't come up with the idea and this might not have been the best way to do it, but hindsight is 20/20. I do hope that if you are interested in a WG/Product that you do participate because the governance for them is set up and will allow different WG members going forward. I've also seen lots of non-member participation be really fruitful already. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 23 January 2014 11:48, Josh Boyer wrote: > On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes wrote: > > > Personally I think a lot of it has to do with the way the whole thing > seemed > > to be a fait accompli such that there seemed to be little point doing > > anything other than sitting back and seeing what happened. > > > > You know, the way one minute it was just a suggestion from one member of > the > > community and the next minute it was all decided and people were busy > > forming working groups to sort out the details. Apparently that > miraculous > > transition happened at Flock, but for anybody that wasn't there it was > as if > > it was a god given edict that had been handed down on tablets of stone > that > > Fedora.next was happening and we should all just be good little children > and > > get on with it. > > There _was_ a lot that was discussed and presented at Flock. It's > kind of the purpose of Flock (and FUDCon before that). Get people > together to have big discussions in a high bandwith fashion. And yes, > that can mean that those not in attendance are left to catch up a bit > (though at least with Flock we tried to stream all the sessions to > help with that). > > However, it wasn't decided at Flock. It was presented after Flock to > FESCo, in the normal, online FESCo meetings. It went further from > there to the Board via the usual channels. All of this was done as > any other proposal would normally be handled. Perhaps the only > unusual thing was the relative lack of debate and delay. > > My view of the matter was pretty much the same as Tom's and I was at FLOCK. The language at the sessions I attended was not one of "We would like to do this" but that it was a done thing. I realize a lot of that is the 'get shit done because we are all together' mentality which comes from conferences but by the time I left FLOCK I was pretty sure this was all done and either get in the boat or get out. I wasn't even aware of the FESCO items until this email as I figured it had been done and decided at FLOCK. Fedora.NEXT became irrelevant to me when I realized the committees were mostly hand-chosen versus elected like FESCO. I realize that was to get stuff done versus having a bunch of bureaucratci elections, but it snuffed whatever 'joy' I was going to have to participate in as a 'non-voting' member of a committee. The best way for me to allow the people to get work they wanted to get done was to get out of the way, and so I have. Now that I am asked why I am not enthused, I am explaining. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 07:03:02PM +0100, Thorsten Leemhuis wrote: > Okay, I'll bite (after thinking whether writing this mail is worth it): Thanks. I hope that I can make you feel that it was. > The main reason for that: Fedora.next is a huge effort that seems to > make everything even more complicated. It imho is also sold pretty > badly right now, as you have to invest quite a lot of time to > understand what Fedora.next actually is. And Fedora.next to me seems > like something the core contributors push forward without having > really abort those Fedora contributors who don't have Fedora as one of > their top priorities in life. I've been in both of those positions over the years, and I certainly don't want to leave out the more-casual contributor (or, highly committed contributors who are just really busy right now). I understand your feeling that it hasn't been documented in a way that's as helpful as could be -- I'm trying to increase what I'm doing there, and could certainly use more help from others who are good at explaining and visualizing things. I will be giving a talk on Sunday, February 9th in at DevConf in Brno, CZ, and I'll post slides from that (probably here as text as well), and I assume there will be video. For many things, there hasn't been a whole lot to say because it's been in planning -- the product descriptions are not completely approved yet even, and we haven't started collectively talking about the big changes. (And we will!) > I these days wouldn't start contributing to Fedora, as all those rules > and guidelines that the wiki provides would scare me off. That's what > Fedora.next should fix imo, as we afaics need more contributors: I > more often than a few years ago find packages in Fedora that are badly > maintained or outdated. Contributing must be as easy as editing a > wikipedia page. Further: kororaproject.org, fedorautils-installer and > similar project show that there are people that want to make Fedora > better. But they do their work outside of Fedora and RPM Fusion; > fixing the issues directly at the root would be better for all of us. I don't disagree with this, but I don't think they're directly related. Because we started with the governance and somewhat formal product descriptions, those are the primary visible artifacts. As we start working with the website, documentation, and design teams, more naturally-accessible starting points will take over in prominence. > And I really wonder if Fedora.next is really backed by those community > contributors that are not involved in Fedora to deeply. One reason for > that: Fedora.next mails like the one I'm replying to seem to get very > few responses -- especially considering the fact that Fedora.next is [...] > That's why I got the feeing a lot of contributors are simply waiting > for more concrete details to emerge before deciding what to make of > Fedora.next; or they simply at all don't care to much what the higher > ups do, as getting involved on that level can cost quite a lot of time > and can be frustrating (that's not a complaint, that's simply how it > is often; wasn't much different in my days, but noticed that more when > I wasn't that active an more myself). I think that'll naturally solve itself as we get more concrete. But also, just looking anecdotally at the Cloud SIG, this process has helped draw in community contribution where we didn't have so much before. It gives a framework to plug in, and as more details are worked out, I expect that to snowball. So, I guess I kind of disagree with the basic premise. But also, I want to go back to the first part of my message that you're responding to. I don't think our current online communication structure really works very well for the kind of contributor you're concerned about. (Let alone working very well for more active contributors who still don't have time to read every list or hang out on IRC 24/7.) I think we need to fix that, whether we consider that part of Fedora.next or a separate big initiative. > I have many more thoughts in my head, but I'll stop here, as those are > basically the most important things that bother me right now when > looking at Fedora and Fedora.next. I appreciate it. Does anything I've said help you feel better about it? I know I glossed over the "put it off for another release" part. :) And what we do with spins is still up in the air -- I have a suggestion which parallels the primary arch / secondary arch mechanism (although probably less strictly), and I need to finish fleshing that out for FESCo -- it will be on a meeting agenda after FOSDEM/DevConf. I would like to hear more of your thoughts, too. > P.S.: Fixed subject (s/2013/2014/) :) Thanks. -- Matthew Miller-- Fedora Project-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 1:38 PM, Tom Hughes wrote: > On 23/01/14 18:26, Josh Boyer wrote: >> >> On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis >> wrote: >> >>> And I really wonder if Fedora.next is really backed by those community >>> contributors that are not involved in Fedora to deeply. One reason for >> >> >> I wonder the same. However, I don't think it's because we haven't >> necessarily asked in all of the usual places, or haven't tried to >> reach as many people as possible. There has been very little response >> from anyone and I can't tell if it's from indifference or from a lack >> of them even being aware. It's really hard to tell. > > > Personally I think a lot of it has to do with the way the whole thing seemed > to be a fait accompli such that there seemed to be little point doing > anything other than sitting back and seeing what happened. > > You know, the way one minute it was just a suggestion from one member of the > community and the next minute it was all decided and people were busy > forming working groups to sort out the details. Apparently that miraculous > transition happened at Flock, but for anybody that wasn't there it was as if > it was a god given edict that had been handed down on tablets of stone that > Fedora.next was happening and we should all just be good little children and > get on with it. There _was_ a lot that was discussed and presented at Flock. It's kind of the purpose of Flock (and FUDCon before that). Get people together to have big discussions in a high bandwith fashion. And yes, that can mean that those not in attendance are left to catch up a bit (though at least with Flock we tried to stream all the sessions to help with that). However, it wasn't decided at Flock. It was presented after Flock to FESCo, in the normal, online FESCo meetings. It went further from there to the Board via the usual channels. All of this was done as any other proposal would normally be handled. Perhaps the only unusual thing was the relative lack of debate and delay. > Even the formation of the working groups was odd - the original decision to > form them, as I read it, was that they were to explore the idea of doing > these three streams but within days it seemed that the question was no > longer whether to do them but rather how to do them. I can see how that would be confusing. I always understood it to be "these WGs will be formed and they will be tasked with figuring out how to create their respective products". Perhaps some lack of clarity in the proposal? >>> That's why I got the feeing a lot of contributors are simply waiting >>> for more concrete details to emerge before deciding what to make of >>> Fedora.next; or they simply at all don't care to much what the higher >>> ups do, as getting involved on that level can cost quite a lot of time >>> and can be frustrating (that's not a complaint, that's simply how it >>> is often; wasn't much different in my days, but noticed that more when >>> I wasn't that active an more myself). >> >> >> If they are waiting, what are they waiting for? If they don't care, >> and they just want to maintain a package or 30 packages, is there >> anything that you see in Fedora.next that would prevent them from >> doing that? There will always be varied level of participation, and I >> think we need to have a development model that encourages that and >> allows for growth. I don't think Fedora.next gets in the way of that, >> but I would love to have other opinions. > > > To be honest my concerns are more with my user hat on than my contributor > hat - that we will lose the gold standard unified packaging standards and > single source and mechanism for installing packages. I haven't seen anything from any WG that would suggest a deviation from RPM packaging guidelines or using separate repositories. It is a valid concern and one we need to keep an eye on. > The actual spins (or whatever you want to call them) aren't something that > bother me at all, as they are to my mind largely irrelevant for anybody > other than a new user. When I bring a new machine up I just want to get a > base OS on and access to the package repository and what packages are > installed by default doesn't really bother me. So... Fedora.next is essentially irrelevant to you? That's OK, it doesn't have to be relevant to everyone. And meeting the needs of existing users is definitely something that should be taken into account. Would you use e.g. Workstation as it's the most equivalent to the default Fedora install today? (I realize it's difficult to say for sure, given nothing actually exist yet so please allow a little latitude in the question.) josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 23/01/14 18:26, Josh Boyer wrote: On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis wrote: And I really wonder if Fedora.next is really backed by those community contributors that are not involved in Fedora to deeply. One reason for I wonder the same. However, I don't think it's because we haven't necessarily asked in all of the usual places, or haven't tried to reach as many people as possible. There has been very little response from anyone and I can't tell if it's from indifference or from a lack of them even being aware. It's really hard to tell. Personally I think a lot of it has to do with the way the whole thing seemed to be a fait accompli such that there seemed to be little point doing anything other than sitting back and seeing what happened. You know, the way one minute it was just a suggestion from one member of the community and the next minute it was all decided and people were busy forming working groups to sort out the details. Apparently that miraculous transition happened at Flock, but for anybody that wasn't there it was as if it was a god given edict that had been handed down on tablets of stone that Fedora.next was happening and we should all just be good little children and get on with it. Even the formation of the working groups was odd - the original decision to form them, as I read it, was that they were to explore the idea of doing these three streams but within days it seemed that the question was no longer whether to do them but rather how to do them. That's why I got the feeing a lot of contributors are simply waiting for more concrete details to emerge before deciding what to make of Fedora.next; or they simply at all don't care to much what the higher ups do, as getting involved on that level can cost quite a lot of time and can be frustrating (that's not a complaint, that's simply how it is often; wasn't much different in my days, but noticed that more when I wasn't that active an more myself). If they are waiting, what are they waiting for? If they don't care, and they just want to maintain a package or 30 packages, is there anything that you see in Fedora.next that would prevent them from doing that? There will always be varied level of participation, and I think we need to have a development model that encourages that and allows for growth. I don't think Fedora.next gets in the way of that, but I would love to have other opinions. To be honest my concerns are more with my user hat on than my contributor hat - that we will lose the gold standard unified packaging standards and single source and mechanism for installing packages. The actual spins (or whatever you want to call them) aren't something that bother me at all, as they are to my mind largely irrelevant for anybody other than a new user. When I bring a new machine up I just want to get a base OS on and access to the package repository and what packages are installed by default doesn't really bother me. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis wrote: > Verbose: Yes, I really think the Fedora needs changes -- at some point > a few years ago we mostly continued to do things as they have "always" > been done (read: since Core and Extras merged), without thinking if > those ways are still the best. > > So I welcomed Fedora.next in the beginning. But I, as someone that is > not involved very much in Fedora any more, still fail to fully grasp > it. Yes, there are many mailing list or blog posts and some docs in > the wiki. But most of them are really way too long for people that > have busy days; a lot of those docs are also quite "meta", > nevertheless afaics failing to give a goal. Take > https://fedoraproject.org/wiki/Fedora.next for example. It more a > description of a vague idea without saying much concrete besides > "design, build, and market three distinct Fedora products" (what is a > Fedora product?). There are a few links there, but even > https://fedoraproject.org/wiki/Fedora.next/boardproposal is still > quite meta for something which is supposed to be the base for a > release that is eight months or so away. It doesn't explain what > problems are being solved or what happens to spins (KDE and such) or > how often (according to current plans) Fedora will be released in the > future. You make a fair point. There are many unanswered questions around Fedora.next (like spins?). Asking those questions or pointing out inconsistencies does help though :). > What really gives me the creeps on those pages: "sub-committees of > FESCo, with individual governance structures". Those afaics are three > Product Working Groups Workgroups, two Fedora Rings Working Groups and > the Inter-WG for coordination. That sounds like a awful lot of > overhead an even more bureaucracy than we already have. And we imho > have way to much already (part of it is my fault!) – something I had > hoped Fedora.next would try to fix. It is more overhead to a degree. On the other hand, the idea is to enable people that are interested in specific areas to go forth and create a Fedora deliverable that they think meets the needs of those areas best, without having to pass everything through FESCo. FESCo just doesn't scale like that. > I these days wouldn't start contributing to Fedora, as all those rules > and guidelines that the wiki provides would scare me off. That's what > Fedora.next should fix imo, as we afaics need more contributors: I > more often than a few years ago find packages in Fedora that are badly > maintained or outdated. Contributing must be as easy as editing a The packaging guidelines are very daunting. Automating as much of that as possible, either through spec creation tooling or package review tooling would help. > wikipedia page. Further: kororaproject.org, fedorautils-installer and > similar project show that there are people that want to make Fedora > better. But they do their work outside of Fedora and RPM Fusion; > fixing the issues directly at the root would be better for all of us. Small note: The two projects you use as an example are required to do what they're doing (in part) outside of Fedora for legal reasons. I don't believe Fedora.next will change how US law works, so it might not be the best of examples. (And we have a Board meeting to discuss related things that are not legally prohibited.) > And I really wonder if Fedora.next is really backed by those community > contributors that are not involved in Fedora to deeply. One reason for I wonder the same. However, I don't think it's because we haven't necessarily asked in all of the usual places, or haven't tried to reach as many people as possible. There has been very little response from anyone and I can't tell if it's from indifference or from a lack of them even being aware. It's really hard to tell. > that: Fedora.next mails like the one I'm replying to seem to get very > few responses -- especially considering the fact that Fedora.next is > something really important and brought to a list where small details > quite often spawn very long discussions. Sometimes it's different -- > like the ongoing and long "3rd party and non-free software" > discussion. That shows that a lot of people still care, but don't > bother follow to closely what the workgroups discuss before it someone > gets to a point where it's more visible. Yes, that thread shows a lot of people caring. However, those people are still people that I consider "core contributors". > That's why I got the feeing a lot of contributors are simply waiting > for more concrete details to emerge before deciding what to make of > Fedora.next; or they simply at all don't care to much what the higher > ups do, as getting involved on that level can cost quite a lot of time > and can be frustrating (that's not a complaint, that's simply how it > is often; wasn't much different in my days, but noticed that more when > I wasn't that active an more myself). If they a
Re: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi! On 03.01.2014 19:14, Matthew Miller wrote: > […] So those are my things. What do you think about them? What > else should be included? What different directions should we > consider? How will we make Fedora more awesome than ever in the > coming year? Okay, I'll bite (after thinking whether writing this mail is worth it): I'm still undecided if I overall like Fedora.next or fear it. But more and more I tend to the latter position and wonder if it might be wise to slow things down: Do one more Fedora release the old style in round about June; that would give us more time to better discuss and work out Fedora.next and get contributors involved better in the planing. The main reason for that: Fedora.next is a huge effort that seems to make everything even more complicated. It imho is also sold pretty badly right now, as you have to invest quite a lot of time to understand what Fedora.next actually is. And Fedora.next to me seems like something the core contributors push forward without having really abort those Fedora contributors who don't have Fedora as one of their top priorities in life. Verbose: Yes, I really think the Fedora needs changes -- at some point a few years ago we mostly continued to do things as they have "always" been done (read: since Core and Extras merged), without thinking if those ways are still the best. So I welcomed Fedora.next in the beginning. But I, as someone that is not involved very much in Fedora any more, still fail to fully grasp it. Yes, there are many mailing list or blog posts and some docs in the wiki. But most of them are really way too long for people that have busy days; a lot of those docs are also quite "meta", nevertheless afaics failing to give a goal. Take https://fedoraproject.org/wiki/Fedora.next for example. It more a description of a vague idea without saying much concrete besides "design, build, and market three distinct Fedora products" (what is a Fedora product?). There are a few links there, but even https://fedoraproject.org/wiki/Fedora.next/boardproposal is still quite meta for something which is supposed to be the base for a release that is eight months or so away. It doesn't explain what problems are being solved or what happens to spins (KDE and such) or how often (according to current plans) Fedora will be released in the future. What really gives me the creeps on those pages: "sub-committees of FESCo, with individual governance structures". Those afaics are three Product Working Groups Workgroups, two Fedora Rings Working Groups and the Inter-WG for coordination. That sounds like a awful lot of overhead an even more bureaucracy than we already have. And we imho have way to much already (part of it is my fault!) – something I had hoped Fedora.next would try to fix. I these days wouldn't start contributing to Fedora, as all those rules and guidelines that the wiki provides would scare me off. That's what Fedora.next should fix imo, as we afaics need more contributors: I more often than a few years ago find packages in Fedora that are badly maintained or outdated. Contributing must be as easy as editing a wikipedia page. Further: kororaproject.org, fedorautils-installer and similar project show that there are people that want to make Fedora better. But they do their work outside of Fedora and RPM Fusion; fixing the issues directly at the root would be better for all of us. And I really wonder if Fedora.next is really backed by those community contributors that are not involved in Fedora to deeply. One reason for that: Fedora.next mails like the one I'm replying to seem to get very few responses -- especially considering the fact that Fedora.next is something really important and brought to a list where small details quite often spawn very long discussions. Sometimes it's different -- like the ongoing and long "3rd party and non-free software" discussion. That shows that a lot of people still care, but don't bother follow to closely what the workgroups discuss before it someone gets to a point where it's more visible. That's why I got the feeing a lot of contributors are simply waiting for more concrete details to emerge before deciding what to make of Fedora.next; or they simply at all don't care to much what the higher ups do, as getting involved on that level can cost quite a lot of time and can be frustrating (that's not a complaint, that's simply how it is often; wasn't much different in my days, but noticed that more when I wasn't that active an more myself). I have many more thoughts in my head, but I'll stop here, as those are basically the most important things that bother me right now when looking at Fedora and Fedora.next. CU knurd P.S.: Fixed subject (s/2013/2014/) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS4VlWAAoJEHK25u9MWD0tjR0QAJAe7Z35vN90Moq1mXGRpiMJ n6qYwGFiORpnzLkO