Re: Summary of accepted Fedora 20 Changes - week 30
On Sunday 28 July 2013 10:29:47 Nicolas Mailhot wrote: > 17. there's no need to work on this, "technical" users will know how to > set up an MTA → that's what Solaris people thought before Linux people ate > their lunch integrating stuff they didn't want to bother with Very good example, it's called "batteries included". -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Ignore Your Rights And They'll Go Away -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sunday 28 July 2013 08:01:25 Matthew Garrett wrote: > On Sun, Jul 28, 2013 at 09:56:16AM +0300, Oron Peled wrote: > > 1. By the same logic we can ship just a browser, why bother building > >LibreOffice if many use just google-docs? > Because not everyone uses Google Docs, and so any solution needs to > account for those who don't as well. And I thought those few "power-users" would install it by themselves ;-) Or, to make the example more to your taste -- if, as many claimed here, most people use Gmail can't we forgo installing MUA's by default? Hmmm new feature for F21? > > 2. People can still use gmail and other online services like twitter > >via desktop applications (in my case kmail and choqok respectively). > But most don't, and therefore an error reporting scheme that depends on > users running a local mail client is inappropriate. You don't suggest any alternative, so let me suggest an easy one (which btw I use on all my desktops for the last 20 years): * Something important is sent to local MTA. * User get mail notification on their desktop. * User click on the notification. * MUA opens. * User reads mail. All of this is plain configuration on any MUA/desktop-system. Just make these *DEFAULTS* and the "problem" is solved: * Alias root to installing user in /etc/aliases * Configure installed MUA's to include local spool mailbox by default. * Configure your desktop to notify about new mails. > > Last side note: helping non-expert people get used to quality local > > applications which have convenient defaults, is part of the push > > for "Freedom" -- if both your data and your applications are locked > > in vertical clouds, you aren't left with too much freedom. > > There are benefits in running local applications, especially when it > comes to freedom. However, we are unable to force our users to run local > applications. Don't force them -- expose the better value proposition: * Read mail accounts from different providers via single interface. * Get mail notifications, regardless of mail origin. * Subscribe to different IM systems via single IM application Correct default configuration of MTA+MUA is great way to hook people into these benefits -- especially those "newbies" (veterans already know this and configure this for themselves). -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron Life is a sexually transmitted, 100% lethal disease. -- 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: Summary of accepted Fedora 20 Changes - week 30
Am 27.07.2013 21:31, schrieb Michael Scherer: > Le samedi 27 juillet 2013 à 12:54 +0200, Reindl Harald a écrit : >> >> Am 27.07.2013 12:45, schrieb drago01: >>> On Sat, Jul 27, 2013 at 12:39 PM, Nicolas Mailhot > Even if we do that ... for most of those user this mails are mostly noise. Where are the facts backing this assertion? >>> >>> Common sense ... >> >> so i am maintaing more than 20 fedora machines and i am >> happy about this mails from my *first day* with Fedora >> many years ago > > Sure, so that's 1 person. No, find just a bit more and we will start to > be able to have proper data instead of anecdote. 5 others around me... in fact anybody *i know* weho is using Linux > I can tell that most of the non technical users ( around 40 in my > office, but I have no reason to believe the 1960 in others offices are > different on that part ) using linux desktop at work ask me why they > receive mail everyday speaking of the backup system not being configured > ( and so mailling them to enable it ) perfect - so why does the admin not his job and configure or remove it? there you see *why* the mails are good *because* they ask > Most have no idea why they receive mail from the computer most have no idea about anything on computers but if they face things they can understand them with remove anything "most have no idea" you can remove the whole operating syetem at all > A mail sent by your computer to say something on a regular basis is not, > except for technical person like you and me ( and usually, when I > receive mail from cron, they are obscure and useless and due to some > failure, so I think people writing cron job do not care that much to > help me seeing what is is wrong ). i can not remember any cron mail which was not clear in doubt Google is everybody's friend >>> where are the facts backing up the opposite? >> >> nobody needs to backing up the opposite! >> >> if somebody comes up and and declares long existing >> things as noise and wants to deprecate them he is >> the one who has to bring facts > > cron output is usually not translated ( cause it is well know that every > admin speak english, why should we take care of that ), and that's > already a problem. really? > A mail do not permit a good interaction ( like "click here to configure > stuff that you should configure" ) while a notification permit that ( at > least on a desktop ) i doubt that a desktop notify permits the user admin-actions and if so which ones so that i can file a bugreport > There is no rate limitation for cronjob output. Usually, no need to send > me 100 mails about "job error, no disk space", I got the message on the > first mail, the 99th are just useless spam that also contribute to the > problem. if you really got the message you would have took action > AFAIK, you cannot easily ( ie, without being minimaly command line savy > ) opt out of the mail notification, except by filtering that on your > mail you *should not* opt out if smartd or mdadm are sending mails you should look at it > For a desktop use case with a single user, that's already enough reasons > to use something else. For a desktop with more than 1 user, the issue > are the same, except that now, someone has to configure the email of > every user in /etc/aliases, thus needing more than a anaconda patch. the user type you are describing all the time has no user cronjobs at all and the root-messages are for whoever calls himself admin and responsible for the machine > And for servers, having 2 ways to get logs of what is running is just > asking for more work than needed. When you setup something to aggregate > the log ( splunk, central syslog ), there is no need to have a second > system that send a different type of log on a different way, just > because "this was done like this before". 2 systems, twice the risk of > failing, twice the work to setup, and of course, they do not match on > feature do you watch all day long syslog of all machines? i do not because i have no time to do so and no place for so many terminals *but* any cronjob mail put via sieve in his folder get attention hence if my scripts are facing something is going wrong they simple echo what is wrong because i can rely that it ends in a notify-mail instead get spotted tomorrow thats why i can work this clean way running 600 domains with php error_reporting E_ALL and twice a hour collect the error log and echo it for a notify - well that is not the desktop case *but* if i had not seen this all at the desktop i would probably not know these things now there are *many* things which got "deperecated" from mostly the same people which are the reason i am doing today the job i do and without them i stil would be only programmer and not sysadmin and *that* is why IMHO it is completly wrong to remove things from which others could learn the same as i did signature.asc Description: OpenPGP digital signature -- devel mailing list devel
Re: Summary of accepted Fedora 20 Changes - week 30
Le Sam 27 juillet 2013 21:31, Michael Scherer a écrit : > Sure, so that's 1 person. No, find just a bit more and we will start to > be able to have proper data instead of anecdote. I'm quite sure you'll find more than a bit more such users among Fedora users. And, btw, the burden of proof is on the people who made the unsubstantiated assertion, don't try to reverse it Anyway, I've seen a quite a few bad arguments on this thread so I'll make answers in one go. 1. system MTA is bad, because sendmail is bad → just switch to a modern replacement like postfix 2. system MTA can not use different sender credentials by user → yes it can 3. it's too much work to configure a mail per user → because it's less work to do it once per user and per mua rather than one per user centrally? 4. this is not a simple anaconda patch → I believe it's be way easier to have anaconda write a stable config file that the ever-changing "desktop-only" mess we've forced it to cope with for years 5. users don't want local mail spool, they use gmail → then let them configure at install time the system MTA so it relays mail to gmail 6. nobody understands cron mail, it's obscure, untranslated → nobody is a stretch and anyway this is a property of the sending apps not of the communication medium. Fix the text of the notices, localize it, and then give it to the MTA. You'll need to work on this anyway if you want to do GUI notifications 7. There is no rate limiting on mail notifications → just do the rate limiting at the source with a filter-before-sending program. Again, you'll need to do the same work for GUI notifications 8. but I don't care about those notices, I'll just suppress them, or bury them in the journal, and no one will be the wiser → this is ostrich design. Those notices were created because people found them useful 9. A mail does not permit proper interaction → somehow Amazon, Google, Ebay manage it perfectly. It's just a matter of writing good notification texts, and adding callbacks to your system with single-use tickets (either web links or attachments a specialized app can display in a notification center). When people wanted to play with extensions, there was no such "can not integrate Internet with the deskop" argument 10. users do not expect a desktop that sends mail → users didn't expect smartphones at all. I guess neither Apple, not Google, not Samsung should have spent a dime on them. Users are far more adaptable than you think, what they expect is irrelevant, what matters is whether your implementation sucks or not 11. smtpd has no place on a desktop → neither Microsoft, not Apple, nor Google, are building pure desktop solutions. They're integrating desktops, laptops, servers, appliances, gizmos, cloud, to provide the best user experience and choose technical bricks based on the functionality they want to achieve, not based on archaic silos 12. all users do not know how to filter their mail → a hell of a lot more users know how to filter their mail than how to filter the custom notification systems people want to replace them with. And this will still be the case in the future, since filtering mail is useful for lots of other things, and dealing with a GUI system that will be rewritten anyway in a few years is not 13. there will only be at most one Fedora system per home anyway → If that's the case, Fedora will be a failure. Given plummeting hardware prices the only bottleneck is Fedora execution (see for example the latest Google dongle. Google is *not* settling for a single Google system per home) 14. Fedora users are irrelevant, I want normal users → what has this attitude ever produced except a collapse in Fedora users? Your normal users, when they actually had a vote (ie RHEL side, when an unhappy user can just cancel his subscription), didn't vote the way your "common sense" indicated (and it was not the first time either, see spacial desktop). Use less "common sense" and "design", do more actual user studies (real users not imaginary ones). Removing features never made other features appear by magic 15. it's useless on servers → on the contrary, once the email notifications are streamlined and standardized it'd be trivial for server alerting systems to pick up mail notifications and inject them in a central console (or if you want to be fancy, just take the local notification processing node, and have it queue notifications on a centralized AMPQ bus instead of smtp-side when the bus is available). The main point is to process notifications before deciding how they are sent, instead of the direct app-to-GUI-popup unmanaged inconsistent mess 16. I can do the same with a central syslog → good for you, but even if that was the case it'll be a lot easier for your central system to process notifications that have been streamlined for a little for smtp sending rather than the current inconsistent situation 17. there's no need to work on this, "technical" users will know how to set up an MTA → th
Re: Summary of accepted Fedora 20 Changes - week 30
On Sun, Jul 28, 2013 at 09:56:16AM +0300, Oron Peled wrote: > On Saturday 27 July 2013 18:36:23 Matthew Garrett wrote: > > Really? I'd expect most users to be using gmail at this point. Any > > solution needs to account for them as well. > > 1. By the same logic we can ship just a browser, why bother building >LibreOffice if many use just google-docs? Because not everyone uses Google Docs, and so any solution needs to account for those who don't as well. > 2. People can still use gmail and other online services like twitter >via desktop applications (in my case kmail and choqok respectively). But most don't, and therefore an error reporting scheme that depends on users running a local mail client is inappropriate. > Last side note: helping non-expert people get used to quality local > applications which have convenient defaults, is part of the push > for "Freedom" -- if both your data and your applications are locked > in vertical clouds, you aren't left with too much freedom. There are benefits in running local applications, especially when it comes to freedom. However, we are unable to force our users to run local applications. We therefore need a mechanism for providing error data to users that doesn't require them to run a local application. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Summary of accepted Fedora 20 Changes - week 30
On Saturday 27 July 2013 18:36:23 Matthew Garrett wrote: > On Sat, Jul 27, 2013 at 01:12:25PM +0300, Oron Peled wrote: > > On the other hand, aliasing root to the installing user in /etc/aliases > > is trivial and adding the local spool mailbox as a default to MUA's > > would make these mails *visible by default* to that user. > > Really? I'd expect most users to be using gmail at this point. Any > solution needs to account for them as well. 1. By the same logic we can ship just a browser, why bother building LibreOffice if many use just google-docs? 2. People can still use gmail and other online services like twitter via desktop applications (in my case kmail and choqok respectively). 3. Having quality desktop experience is part of what gives value to any Linux distribution -- just see the heated debates about any desktop related issue. 4. The "sendmail" discussion raised two small but important points: * That our default MUA's (e.g: kmail, evolution) aren't configured to show our default Linux mailboxes on first startup. * That "root" mail is not redirected by default to the installing user. 5. While I, as a Linux/Unix veteran, would always "fix" these two items without even thinking -- they are definitely "integration-bugs" (or miss-features if you want). Last side note: helping non-expert people get used to quality local applications which have convenient defaults, is part of the push for "Freedom" -- if both your data and your applications are locked in vertical clouds, you aren't left with too much freedom. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron "In theory, it's practical. In practice - it's only a theory". -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sun, 2013-07-28 at 00:10 +0200, drago01 wrote: > On Sat, Jul 27, 2013 at 11:57 PM, Lars Seipel wrote: > > The thing is: is it acceptable that, in the process of reaching that > > goal, we end up alienating (a part of) the more technical userbase (who > > are much more likely contributors)? > > No one is alienating anyone. A "technical" user knows what he wants > and can do yum install sendmail/exim/postfix etc or add it to the > kickstart file. > > While the user that has no or little technical knowledge is unlikely > to remove the unnecessary stuff because if anything all he/show knows > is that "the operating system" is doing that. For the love of Pete, people, FESCo made a decision halfway through last week. Can we please stop making the same arguments at each other over and over again now? No-one has had a single new thing to say in this thread for days. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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: Summary of accepted Fedora 20 Changes - week 30
On 7/27/2013 6:31 PM, David wrote: > On 7/27/2013 6:10 PM, drago01 wrote: >> On Sat, Jul 27, 2013 at 11:57 PM, Lars Seipel wrote: >>> The thing is: is it acceptable that, in the process of reaching that >>> goal, we end up alienating (a part of) the more technical userbase (who >>> are much more likely contributors)? >> >> No one is alienating anyone. A "technical" user knows what he wants >> and can do yum install sendmail/exim/postfix etc or add it to the >> kickstart file. >> >> While the user that has no or little technical knowledge is unlikely >> to remove the unnecessary stuff because if anything all he/show knows >> is that "the operating system" is doing that. >> > > Excuse me please. Non programer. Non adimn. Non geek. You have two paths. You can continue down the one one you appear to be following where only 'geeks' can use Fedora. There are only so many 'geeks'. Or? You can try to develop a system that 'Grandma' can use to replace Windows, that is your goal is it not?, out of the box with a little help. Or? Grandma can buy, or get as a gift, a computer with Windows that does that 'from the box'. With programs that install without 'jumping through hoops' while wearing strange costumes and reading really confusing RTFM manuals to get them to work. *AND* programs that don't require that grandma hunts for 'stuff' that the strange little man with the strange name that lives in the cellar someplace in Estonia stole and is offering for download. Geeks can make 'whatever' work'. Grandma needs a system that she can 'Skype' to the grand daughter. To email her. to share pictures. To watch videos. Or? You can 'geek' yourself out of the mainstream. MHOP. -- David -- 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: Summary of accepted Fedora 20 Changes - week 30
On 7-27-13 12:11:03 Michael Catanzaro wrote: > On Sat, 2013-07-27 at 12:54 +0200, Reindl Harald wrote: > > > > so i am maintaing more than 20 fedora machines > > The typical user will have exactly one Fedora desktop. /me counts my desktop systems. 1. Check. > He will never > ever look at his system logs. Oops. (I actually uninstalled syslog and only use journalctl [awesome] now. But I do look at the logs.) > If you told him that his computer can send > him email, his head would explode. Naw. Been using these for decades. Works good. Lasts a long time. (Of course, I always have to make up for Fedora's broken installation by updating my aliases file. But I've had to do that since Solaris 2.5 days.) > You can yum install sendmail if you want it, without forcing it on > Grandma. You really can. Well, yes. But I'm not sure this discussion really has a handle on the typical *Fedora* user. But hey, I don't have real data either. Just one "typical" user data point. -- Garry T. Williams -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sat, Jul 27, 2013 at 11:57 PM, Lars Seipel wrote: > The thing is: is it acceptable that, in the process of reaching that > goal, we end up alienating (a part of) the more technical userbase (who > are much more likely contributors)? No one is alienating anyone. A "technical" user knows what he wants and can do yum install sendmail/exim/postfix etc or add it to the kickstart file. While the user that has no or little technical knowledge is unlikely to remove the unnecessary stuff because if anything all he/show knows is that "the operating system" is doing 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: Summary of accepted Fedora 20 Changes - week 30
On Sat, Jul 27, 2013 at 12:55:58PM +0200, drago01 wrote: > Which excludes you from the type of user I was talking about. I have no data to back this up but I'd guess that the vast majority of Fedora's userbase _are_ technical users. It's certainly a noble goal to make Fedora more accesible to non-technical users. The thing is: is it acceptable that, in the process of reaching that goal, we end up alienating (a part of) the more technical userbase (who are much more likely contributors)? -- 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: Summary of accepted Fedora 20 Changes - week 30
Le samedi 27 juillet 2013 à 12:54 +0200, Reindl Harald a écrit : > > Am 27.07.2013 12:45, schrieb drago01: > > On Sat, Jul 27, 2013 at 12:39 PM, Nicolas Mailhot > >>> Even if we do that ... for most of those user this mails are mostly noise. > >> > >> Where are the facts backing this assertion? > > > > Common sense ... > > so i am maintaing more than 20 fedora machines and i am > happy about this mails from my *first day* with Fedora > many years ago Sure, so that's 1 person. No, find just a bit more and we will start to be able to have proper data instead of anecdote. I can tell that most of the non technical users ( around 40 in my office, but I have no reason to believe the 1960 in others offices are different on that part ) using linux desktop at work ask me why they receive mail everyday speaking of the backup system not being configured ( and so mailling them to enable it ). Most have no idea why they receive mail from the computer, because for most of them, this is something they never faced. ( and we are speaking of corporate mail, so i can only imagine for the personal mail ). A notification that come on your desktop is something people can understand and a little bit more familiar to them . A mail sent by your computer to say something on a regular basis is not, except for technical person like you and me ( and usually, when I receive mail from cron, they are obscure and useless and due to some failure, so I think people writing cron job do not care that much to help me seeing what is is wrong ). > so which "commons sense" is more woth? > yours or mine? > > > where are the facts backing up the opposite? > > nobody needs to backing up the opposite! > > if somebody comes up and and declares long existing > things as noise and wants to deprecate them he is > the one who has to bring facts cron output is usually not translated ( cause it is well know that every admin speak english, why should we take care of that ), and that's already a problem. A mail do not permit a good interaction ( like "click here to configure stuff that you should configure" ) while a notification permit that ( at least on a desktop ). There is no rate limitation for cronjob output. Usually, no need to send me 100 mails about "job error, no disk space", I got the message on the first mail, the 99th are just useless spam that also contribute to the problem. AFAIK, you cannot easily ( ie, without being minimaly command line savy ) opt out of the mail notification, except by filtering that on your mail, which is not something all users know how to do ( but receiving mail they do not want is something they do not want, and I even got a server ending in a blacklist of yahoo because I think one user ended to filter the mail from cron he received on a server ). For a desktop use case with a single user, that's already enough reasons to use something else. For a desktop with more than 1 user, the issue are the same, except that now, someone has to configure the email of every user in /etc/aliases, thus needing more than a anaconda patch. And for servers, having 2 ways to get logs of what is running is just asking for more work than needed. When you setup something to aggregate the log ( splunk, central syslog ), there is no need to have a second system that send a different type of log on a different way, just because "this was done like this before". 2 systems, twice the risk of failing, twice the work to setup, and of course, they do not match on feature. Anyway, I think I contributed enough to this thread, so I will stop here. -- Michael Scherer -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sat, Jul 27, 2013 at 01:12:25PM +0300, Oron Peled wrote: > On the other hand, aliasing root to the installing user in /etc/aliases > is trivial and adding the local spool mailbox as a default to MUA's > would make these mails *visible by default* to that user. Really? I'd expect most users to be using gmail at this point. Any solution needs to account for them as well. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sat, 2013-07-27 at 12:54 +0200, Reindl Harald wrote: > > so i am maintaing more than 20 fedora machines The typical user will have exactly one Fedora desktop. He will never ever look at his system logs. If you told him that his computer can send him email, his head would explode. You can yum install sendmail if you want it, without forcing it on Grandma. You really can. signature.asc Description: This is a digitally signed message part -- 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: Summary of accepted Fedora 20 Changes - week 30
Am 27.07.2013 12:45, schrieb drago01: > On Sat, Jul 27, 2013 at 12:39 PM, Nicolas Mailhot >>> Even if we do that ... for most of those user this mails are mostly noise. >> >> Where are the facts backing this assertion? > > Common sense ... so i am maintaing more than 20 fedora machines and i am happy about this mails from my *first day* with Fedora many years ago so which "commons sense" is more woth? yours or mine? > where are the facts backing up the opposite? nobody needs to backing up the opposite! if somebody comes up and and declares long existing things as noise and wants to deprecate them he is the one who has to bring facts 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: Summary of accepted Fedora 20 Changes - week 30
On Sat, Jul 27, 2013 at 12:54 PM, Reindl Harald wrote: > > > Am 27.07.2013 12:45, schrieb drago01: >> On Sat, Jul 27, 2013 at 12:39 PM, Nicolas Mailhot Even if we do that ... for most of those user this mails are mostly noise. >>> >>> Where are the facts backing this assertion? >> >> Common sense ... > > so i am maintaing more than 20 fedora machines [...] Which excludes you from the type of user I was talking about. -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sat, Jul 27, 2013 at 12:39 PM, Nicolas Mailhot wrote: > > Le Sam 27 juillet 2013 12:23, drago01 a écrit : >> On Sat, Jul 27, 2013 at 12:12 PM, Oron Peled wrote: >>> >>> Hi, >>> >>> On Friday 26 July 2013 08:06:10 drago01 wrote: Well it is a desktop spin after all. Most of the "keep sendmail and syslog" arguments where more server related things. >>> >>> Definitely not. On our desktop installs we clearly have an interactive >>> user which is defined during install/firstboot/etc. >>> >>> This audience is rarely expected to use the command line shell, >>> and even less so looking at logs (with all journal advantage, running >>> journalctl or tail -f /var/log/messages have the same problem -- the >>> user). >>> >>> On the other hand, aliasing root to the installing user in /etc/aliases >>> is trivial and adding the local spool mailbox as a default to MUA's >>> would make these mails *visible by default* to that user. >> >> Even if we do that ... for most of those user this mails are mostly noise. > > Where are the facts backing this assertion? Common sense ... where are the facts backing up the opposite? -- 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: Summary of accepted Fedora 20 Changes - week 30
Le Sam 27 juillet 2013 12:23, drago01 a écrit : > On Sat, Jul 27, 2013 at 12:12 PM, Oron Peled wrote: >> >> Hi, >> >> On Friday 26 July 2013 08:06:10 drago01 wrote: >>> Well it is a desktop spin after all. Most of the "keep sendmail and >>> syslog" arguments where more server related things. >> >> Definitely not. On our desktop installs we clearly have an interactive >> user which is defined during install/firstboot/etc. >> >> This audience is rarely expected to use the command line shell, >> and even less so looking at logs (with all journal advantage, running >> journalctl or tail -f /var/log/messages have the same problem -- the >> user). >> >> On the other hand, aliasing root to the installing user in /etc/aliases >> is trivial and adding the local spool mailbox as a default to MUA's >> would make these mails *visible by default* to that user. > > Even if we do that ... for most of those user this mails are mostly noise. Where are the facts backing this assertion? -- Nicolas Mailhot -- 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: Summary of accepted Fedora 20 Changes - week 30
On Sat, Jul 27, 2013 at 12:12 PM, Oron Peled wrote: > > Hi, > > On Friday 26 July 2013 08:06:10 drago01 wrote: >> Well it is a desktop spin after all. Most of the "keep sendmail and >> syslog" arguments where more server related things. > > Definitely not. On our desktop installs we clearly have an interactive > user which is defined during install/firstboot/etc. > > This audience is rarely expected to use the command line shell, > and even less so looking at logs (with all journal advantage, running > journalctl or tail -f /var/log/messages have the same problem -- the user). > > On the other hand, aliasing root to the installing user in /etc/aliases > is trivial and adding the local spool mailbox as a default to MUA's > would make these mails *visible by default* to that user. Even if we do that ... for most of those user this mails are mostly noise. -- 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: Summary of accepted Fedora 20 Changes - week 30
Hi, On Friday 26 July 2013 08:06:10 drago01 wrote: > Well it is a desktop spin after all. Most of the "keep sendmail and > syslog" arguments where more server related things. Definitely not. On our desktop installs we clearly have an interactive user which is defined during install/firstboot/etc. This audience is rarely expected to use the command line shell, and even less so looking at logs (with all journal advantage, running journalctl or tail -f /var/log/messages have the same problem -- the user). On the other hand, aliasing root to the installing user in /etc/aliases is trivial and adding the local spool mailbox as a default to MUA's would make these mails *visible by default* to that user. Please note that both steps mentioned are an improvement in default user-experience of Fedora, even if later it's decided that installation of MTA *isn't a default*. (less people some system outputs are "lost" [tongue in the cheek]) Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron ... It's like a Windows.. litle blow and it crashes... (c)Broker -- 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: Summary of accepted Fedora 20 Changes - week 30
On 07/26/2013 04:16 PM, Bill Nottingham wrote: "Jóhann B. Guðmundsson" (johan...@gmail.com) said: Heck maybe the Anaconda team would be willing to come up with or accept patches that will even present this in the installer in a spoke in a user friendly manner. Software selection in anaconda *didn't* have a default in the redesigned UI for quite a while during the pre-F18 run-up. A mechanism to have a default was added based on user complaints. (Essentially, they didn't like having to go into one more spoke.) It's pretty easy to take it out... probably only a line or two. Hmm so I think you misunderstood me here. What I was referring to was in relation with the server sub-community and the idea of them simply having a git instance to host ks files for servers they produce so I guess this needs some further explanation so something along the lines of... step one The service sub-community produce a lamp,jboss,389ds,virtualsation etc. best practices as ready to use ks files in infrastructure. step Two the server sub-community upload those to their git instance under fedorahosted.org and update the description file which contains a short summary for each .ks file and the "|repo=http:" url or ||"repo=git:"| for each of those ks. files Step three Admininstrator downloads the netinst.iso and fires it up. Step four In the main hub spoke he's presented with the option a new spoke "server install" or "install from ks" since this concept can be expanded to something like socialized installation under the name "share my installation/desktop" Apparently there have been alot of people interested in Linus Torvalds desktop setup as can be seen on the internet, for the love of me I don't understand why but it shows that there could be demand for something like that. Anyway that spoke would fetch that description file which contains the summaries and their repo= urls present it in a nice way to the Administrator and he then just selects eitther LAMP, JBoss, 389,Freeipa and performs the install based on that ks file. Simple efficient and easy to use/manage compared to producing 100 server spins and above all allows the server sub-community have full control over what goes in and what goes out ( rsyslog,sendmail ) 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: Summary of accepted Fedora 20 Changes - week 30
Bastien Nocera (bnoc...@redhat.com) said: > Given the amount of time that he spent on the mailing-list fighting for > those features, then it looks like a waste of time, that work has been > done. And? (Maybe I'm misunderstanding what you're saying here.) I mean, it's part of working in a community or company or any larger environment where you don't control all the bits. Sometimes you can't convince people of something. Sometimes you write a 20-patch series to add a feature and upstream decides to go a different way. Sometimes someone doesn't like your pie menus. Is that time wasted? It certainly can be frustrating, and dealing with policies and procedures can be a pain. But it's about the priorities... if all a Fedora contributor cares about is something existing upstream and they don't care what Fedora, RHEL, CentOS, or other downstream distributions do with it, then, sure, I suppose they can just withdraw and concentrate on upstream (or Ubuntu, or Arch, or some other distro). But if they have a vested interest in Fedora, RHEL, CentOS and other downstreams using some bit of technology, if they have a vested interest in getting their code and ideas out to that userbase... participate. Convince. Collaborate. To do otherwise, and just assume someone else will do that for them, seems foolish to me. 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: Summary of accepted Fedora 20 Changes - week 30
On Fri, Jul 26, 2013 at 4:23 PM, "Jóhann B. Guðmundsson" wrote: > On 07/26/2013 01:47 PM, Josh Boyer wrote: >> >> Unless you are willing to change the definition of "default" from >> "spin" to "product", and making product something more broadly >> governed, you're going to be stuck playing these games. If you aren't >> willing to do that, then you're limited to asking spins to adhere to >> concepts of what FESCo thinks should be defaults. >> >> So the choice you have is to work with the existing structure and find >> the spin that best fits the default criteria, or enforce rules on a >> spin because it is "default" which both restricts it compared to other >> spins and elevates it beyond spin status at the same time. > > > Or the third option change/redefine the existing structure to meet something > that actually reflects the current state of the project and drop the entire > concept of an default... > > We have administrators that have been complaining about removal of this and > that from the "defaults" which also will complain about any $future removal > as well and you have to ask yourself why aren't those administrators > participating in the existing server sub-community and help design and shape > what "perfect server" looks like and which components should be in it. > > There they can influence what will be on a spin or better yet ask infra for > a git repo to host all the ks file they come up with, which later can either > be downloaded by all the administrators in the world or the installer can be > pointed at it. > > Practical, simple, useful no overhead to releng like there are with spins > since the server sub-communiy never release iso but only ks files and it > gives the sub-community full control how those ks files are shaped and > what's on them. > > Heck maybe the Anaconda team would be willing to come up with or accept > patches that will even present this in the installer in a spoke in a user > friendly manner. > > Seriously we need to drop entire concept of an default before it tears the > community apart. Having no default(s) means we are no longer a distribution but a collection of packages. That's a way to move towards irrelevance. As for shipping pre built ks files for specific needs. We could try to do that this is not mutually exclusive to having a default for user that either don't want or can't choose their package set. -- 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: Summary of accepted Fedora 20 Changes - week 30
"Jóhann B. Guðmundsson" (johan...@gmail.com) said: > Heck maybe the Anaconda team would be willing to come up with or > accept patches that will even present this in the installer in a > spoke in a user friendly manner. Software selection in anaconda *didn't* have a default in the redesigned UI for quite a while during the pre-F18 run-up. A mechanism to have a default was added based on user complaints. (Essentially, they didn't like having to go into one more spoke.) It's pretty easy to take it out... probably only a line or two. 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: Summary of accepted Fedora 20 Changes - week 30
On Fri, 2013-07-26 at 08:47 +, "Jóhann B. Guðmundsson" wrote: > On 07/25/2013 11:09 PM, Stephen John Smoogen wrote: > > default install -> what you get when you put the DVD in and do a click > > through install. > > The DVD is controlled by RELENG > > > default spin -> The GNOME desktop livecd. > > > While the GNOME SIG controls their live spin > > > If one makes a side by side install of Gnome from DVD and Gnome from > live you wind up with completely different package set thus completely > different experience of Gnome. It's not a 'completely' different package set. The live spin uses the same groups the DVD installs, but cuts stuff out to save space: it's been very close to its size limit for some time. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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: Summary of accepted Fedora 20 Changes - week 30
On 07/26/2013 01:47 PM, Josh Boyer wrote: Unless you are willing to change the definition of "default" from "spin" to "product", and making product something more broadly governed, you're going to be stuck playing these games. If you aren't willing to do that, then you're limited to asking spins to adhere to concepts of what FESCo thinks should be defaults. So the choice you have is to work with the existing structure and find the spin that best fits the default criteria, or enforce rules on a spin because it is "default" which both restricts it compared to other spins and elevates it beyond spin status at the same time. Or the third option change/redefine the existing structure to meet something that actually reflects the current state of the project and drop the entire concept of an default... We have administrators that have been complaining about removal of this and that from the "defaults" which also will complain about any $future removal as well and you have to ask yourself why aren't those administrators participating in the existing server sub-community and help design and shape what "perfect server" looks like and which components should be in it. There they can influence what will be on a spin or better yet ask infra for a git repo to host all the ks file they come up with, which later can either be downloaded by all the administrators in the world or the installer can be pointed at it. Practical, simple, useful no overhead to releng like there are with spins since the server sub-communiy never release iso but only ks files and it gives the sub-community full control how those ks files are shaped and what's on them. Heck maybe the Anaconda team would be willing to come up with or accept patches that will even present this in the installer in a spoke in a user friendly manner. Seriously we need to drop entire concept of an default before it tears the community apart. People seem to be so fixated at "defaults" they no longer can think outside the box. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Fri, Jul 26, 2013 at 02:31:48PM +0200, Christian Fredrik Kalager Schaller wrote: > There is nothing in the Ring proposal which would make any of this any > easier as it is. It is not going to be any easier to agree what is 'ring > 1' than it currently is to agree what is @standard. Only if the rings > had a defined usecase that would change, but then we could also just > agree on the usecase for @standard, and judge sendmail in and out > against that :) The proposal doesn't _include_ that use-case and definition, but puts making it as the first next step. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct [was Re: Summary of accepted Fedora 20 Changes - week 30]
On Fri, Jul 26, 2013 at 10:04:30AM +0100, Matthew Garrett wrote: > > I think you missed my point, but you got the gist. We have way more > > important things to discuss than sendmail. > Yes, like the toxic atmosphere on our mailing lists. I don't agree with > Lennart's position, but that doesn't mean that your behaviour is > acceptable. If you're going to tell someone to leave a community, make > sure that you're meeting that community's norms yourself. Yes. The Fedora Code of Conduct expresses the intentions well. http://fedoraproject.org/code-of-conduct -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 7:20 PM, Toshio Kuratomi wrote: > On Thu, Jul 25, 2013 at 05:09:54PM -0600, Stephen John Smoogen wrote: >> On 25 July 2013 16:59, Billy Crook wrote: >> > On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: >> >> Given the amount of time that he spent on the mailing-list fighting for >> >> those features, then it looks like a waste of time, that work has been >> >> done. >> > >> > Unfeatures technically. He wanted to remove features from the Default >> > spin. Subtracting functionality is not a feature. He wanted an >> > unfeature. >> > >> >> No he wanted out of the default install. We have a badly defined >> naming scheme which is causing confusion: >> >> default install -> what you get when you put the DVD in and do a click >> through install. >> default spin -> The GNOME desktop livecd. >> >> Spins are managed by their respective "teams": >> default has been GNOME and managed by GNOME sig >> kde is managed by KDE sig >> xfce is managed by XFCE sig >> etc etc >> >> So I would say that the GNOME team is within its rights in managing >> its spin. Whether it is named default etc is someone else's problem. >> > This has come up before and I think it's just plain unclear :-( > > The problem is that the desktop spin and the default spin are kinda two > different roles but they are occupied by the same Product. In browsing old > tickets, I see some times when fesco has decided the default spin didn't > have to do what other other things did and sometimes when fesco said they > did. AFAICS, there's been no generalized policy put into place in regards > to this. So it's something that is decided on in every case where it comes > up. > > I don't think anyone thought they were doing anything wrong by making the > change in the desktop spin but because the desktop spin has more than one > owner, I've sent it back to FESCo to vote on whether allowing this change > there is something we intended or not. Unless you are willing to change the definition of "default" from "spin" to "product", and making product something more broadly governed, you're going to be stuck playing these games. If you aren't willing to do that, then you're limited to asking spins to adhere to concepts of what FESCo thinks should be defaults. So the choice you have is to work with the existing structure and find the spin that best fits the default criteria, or enforce rules on a spin because it is "default" which both restricts it compared to other spins and elevates it beyond spin status at the same time. Fun. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, 2013-07-25 at 16:20 -0700, Toshio Kuratomi wrote: > (/me notes that if mattdm's Ring 1 was defined, this might be somewhat > easier to decide upon. If sendmail was in Ring 1 it would be an expected > part of the Fedora Platform. Anything general purpose and carrying the name > Fedora would probably have to carry it as well. If sendmail was in Ring 2, > it probably would be fine to choose whether to install it or not as it > wasn't a guaranteed part of the BaseOS. [You could also > s@sendmail@/usr/bin/sendmail@ in that analysis if you so chose]) > > -Toshio There is nothing in the Ring proposal which would make any of this any easier as it is. It is not going to be any easier to agree what is 'ring 1' than it currently is to agree what is @standard. Only if the rings had a defined usecase that would change, but then we could also just agree on the usecase for @standard, and judge sendmail in and out against that :) As I see it all these flamewars and discussions comes down to a few core problems. One is that Red Hat is not very clear about why we are investing in Fedora and what we need from Fedora to be interested in continuing that investment, although some things are of course implied by RHEL being derived from Fedora. The second issue is that as a community we make everything using the packages produced into 'Fedora'. The Fedora community use the Fedora trademark almost like the smurfs use the word 'smurf' - as a catchall term :) Which in turn leads to endless arguments about what 'Fedora' is. In some sense the word better describes a process than it describes the output these days, and maybe we should update the use of the naming and branding to reflect that. The first question is something we are discussing inside Red Hat and trying to resolve currently, the second question can be solved in a a variety of ways. Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Fri, Jul 26, 2013 at 12:38 PM, Michael Scherer wrote: > Le jeudi 25 juillet 2013 à 11:55 -0700, Adam Williamson a écrit : >> On Thu, 2013-07-25 at 17:36 +0200, Lennart Poettering wrote: >> > On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: >> > >> > > Partially accepted Changes >> > > * No Default Sendmail - >> > > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - >> > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html >> > > >> > > Sendmail will be removed from @core. Removal of sendmail from @standard >> > > didn't >> > > pass. Note: About @standard group might be decided in next release of >> > > Fedora. >> > > >> > > * No Default Syslog - >> > > https://fedoraproject.org/wiki/Changes/NoDefaultSyslog >> > > discussed on >> > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html >> > > >> > > Remove rsyslog from @core, move to @standard pending revaluation in >> > > future. >> > >> > Note that this is not the decision I was interested in. I will hence not >> > work on the implemetation of either of these features. Unless Matthew >> > takes them over alone I will will mark these feature pages as obsolete >> > as they didn't get agreed on. >> >> Taking rsyslog out of @core is a one-line commit to comps which someone >> could do in 30 seconds. It hardly needs 'working on'. > > Technically, fixing all packages with the assumption "there is a MTA > already installed" and "file for log will be there" are also part of the > feature that would have needed work. They are broken regardless of this feature. They will break if a user does "yum remove sendmail" or "yum remove rsyslog" If they require something they should well require it ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
Le jeudi 25 juillet 2013 à 11:55 -0700, Adam Williamson a écrit : > On Thu, 2013-07-25 at 17:36 +0200, Lennart Poettering wrote: > > On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: > > > > > Partially accepted Changes > > > * No Default Sendmail - > > > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - > > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html > > > > > > Sendmail will be removed from @core. Removal of sendmail from @standard > > > didn't > > > pass. Note: About @standard group might be decided in next release of > > > Fedora. > > > > > > * No Default Syslog - > > > https://fedoraproject.org/wiki/Changes/NoDefaultSyslog > > > discussed on > > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html > > > > > > Remove rsyslog from @core, move to @standard pending revaluation in > > > future. > > > > Note that this is not the decision I was interested in. I will hence not > > work on the implemetation of either of these features. Unless Matthew > > takes them over alone I will will mark these feature pages as obsolete > > as they didn't get agreed on. > > Taking rsyslog out of @core is a one-line commit to comps which someone > could do in 30 seconds. It hardly needs 'working on'. Technically, fixing all packages with the assumption "there is a MTA already installed" and "file for log will be there" are also part of the feature that would have needed work. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On 07/25/2013 10:36 PM, Bastien Nocera wrote: - Original Message - On Thu, 2013-07-25 at 17:36 +0200, Lennart Poettering wrote: On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: Partially accepted Changes * No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html Sendmail will be removed from @core. Removal of sendmail from @standard didn't pass. Note: About @standard group might be decided in next release of Fedora. * No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html Remove rsyslog from @core, move to @standard pending revaluation in future. Note that this is not the decision I was interested in. I will hence not work on the implemetation of either of these features. Unless Matthew takes them over alone I will will mark these feature pages as obsolete as they didn't get agreed on. Taking rsyslog out of @core is a one-line commit to comps which someone could do in 30 seconds. It hardly needs 'working on'. Given the amount of time that he spent on the mailing-list fighting for those features, then it looks like a waste of time, that work has been done. Thankfully, it's been removed from the default Desktop spin. It all becomes moot when a FESCO decision can be completely ignored. My own opinions aside (I have a sendmail requirement but would not force it on anyone). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Fri, 26.07.13 08:47, Brendan Jones (brendan.jones...@gmail.com) wrote: > On 07/26/2013 01:47 AM, Lennart Poettering wrote: > > > >[1] "Onsen", in Berlin-Friedrichshain (recommended) > > > Hmmm I must try it. Hard to find real Japanese in this city. It's not a "real" Japanese. I think it's run by Vietnamese, much like the Thai next door, but it's still very good. For a "real" Japanese try Hakata on Oranienstr in Xberg. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
Marcela Mašláňová píše v Pá 26. 07. 2013 v 10:33 +0200: > On 07/26/2013 01:20 AM, Toshio Kuratomi wrote: > > On Thu, Jul 25, 2013 at 05:09:54PM -0600, Stephen John Smoogen wrote: > >> On 25 July 2013 16:59, Billy Crook wrote: > >>> On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera > >>> wrote: > Given the amount of time that he spent on the mailing-list fighting for > those features, then it looks like a waste of time, that work has been > done. > >>> > >>> Unfeatures technically. He wanted to remove features from the Default > >>> spin. Subtracting functionality is not a feature. He wanted an > >>> unfeature. > >>> > >> > >> No he wanted out of the default install. We have a badly defined > >> naming scheme which is causing confusion: > >> > >> default install -> what you get when you put the DVD in and do a click > >> through install. > >> default spin -> The GNOME desktop livecd. > >> > >> Spins are managed by their respective "teams": > >> default has been GNOME and managed by GNOME sig > >> kde is managed by KDE sig > >> xfce is managed by XFCE sig > >> etc etc > >> > >> So I would say that the GNOME team is within its rights in managing > >> its spin. Whether it is named default etc is someone else's problem. > >> > > This has come up before and I think it's just plain unclear :-( > > > > The problem is that the desktop spin and the default spin are kinda two > > different roles but they are occupied by the same Product. In browsing old > > tickets, I see some times when fesco has decided the default spin didn't > > have to do what other other things did and sometimes when fesco said they > > did. AFAICS, there's been no generalized policy put into place in regards > > to this. So it's something that is decided on in every case where it comes > > up. > > > > I don't think anyone thought they were doing anything wrong by making the > > change in the desktop spin but because the desktop spin has more than one > > owner, I've sent it back to FESCo to vote on whether allowing this change > > there is something we intended or not. > > > > (/me notes that if mattdm's Ring 1 was defined, this might be somewhat > > easier to decide upon. If sendmail was in Ring 1 it would be an expected > > part of the Fedora Platform. Anything general purpose and carrying the name > > Fedora would probably have to carry it as well. If sendmail was in Ring 2, > > it probably would be fine to choose whether to install it or not as it > > wasn't a guaranteed part of the BaseOS. [You could also > > s@sendmail@/usr/bin/sendmail@ in that analysis if you so chose]) > > > > -Toshio > > > > > > > Reverting the change or creating the GNOME spin without rsyslog would be > valid options. FESCo decided to leave rsyslog in standard, which means > it should be installed in the default spin. Default spin is now shipped > with GNOME, so it should use FESCo guidance. > > I wouldn't miss default spin at all. At least in Europe we are giving > multi desktop DVD, so the default lost it's purpose anyway. Note that we're only giving away 4000 multidesktop DVDs in Europe. And that's a really small portion of total installations. The multidesktop live DVD is rather a special edition allowed by circumstances (CD, DVD, and dual-layer DVD are about the same cost to produce) than something we should aim for everywhere. Moreover as we will probably be slowly switching to low-cost USB flash drives with a smaller capacity we probably will have to reduce the selection again. Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
- Original Message - > On 25 July 2013 16:59, Billy Crook wrote: > > On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: > >> Given the amount of time that he spent on the mailing-list fighting for > >> those features, then it looks like a waste of time, that work has been > >> done. > > > > Unfeatures technically. He wanted to remove features from the Default > > spin. Subtracting functionality is not a feature. He wanted an > > unfeature. > > > > No he wanted out of the default install. We have a badly defined > naming scheme which is causing confusion: > > default install -> what you get when you put the DVD in and do a click > through install. > default spin -> The GNOME desktop livecd. > > Spins are managed by their respective "teams": > default has been GNOME and managed by GNOME sig > kde is managed by KDE sig > xfce is managed by XFCE sig > etc etc > > So I would say that the GNOME team is within its rights in managing > its spin. Whether it is named default etc is someone else's problem. But within the functional area of the SIG/team. And you know I'm a big fan of more independence of SIGs, and to be honest, I think for Desktops, it's a good move to remove sendmail and rsyslog. The underlying bits should be identical, from the documentation perspective, supportability (ah, we do not have support ;-). One of the Flock proposals says, this should be standard to differ more, another one is more about stable underlying bits, let's see :) Jaroslav > > > -- > Stephen J Smoogen. > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 06:29:47PM -0700, Dan Mashal wrote: > I think you missed my point, but you got the gist. We have way more > important things to discuss than sendmail. Yes, like the toxic atmosphere on our mailing lists. I don't agree with Lennart's position, but that doesn't mean that your behaviour is acceptable. If you're going to tell someone to leave a community, make sure that you're meeting that community's norms yourself. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On 07/25/2013 11:09 PM, Stephen John Smoogen wrote: default install -> what you get when you put the DVD in and do a click through install. The DVD is controlled by RELENG default spin -> The GNOME desktop livecd. While the GNOME SIG controls their live spin If one makes a side by side install of Gnome from DVD and Gnome from live you wind up with completely different package set thus completely different experience of Gnome. JB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On 07/26/2013 01:20 AM, Toshio Kuratomi wrote: On Thu, Jul 25, 2013 at 05:09:54PM -0600, Stephen John Smoogen wrote: On 25 July 2013 16:59, Billy Crook wrote: On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: Given the amount of time that he spent on the mailing-list fighting for those features, then it looks like a waste of time, that work has been done. Unfeatures technically. He wanted to remove features from the Default spin. Subtracting functionality is not a feature. He wanted an unfeature. No he wanted out of the default install. We have a badly defined naming scheme which is causing confusion: default install -> what you get when you put the DVD in and do a click through install. default spin -> The GNOME desktop livecd. Spins are managed by their respective "teams": default has been GNOME and managed by GNOME sig kde is managed by KDE sig xfce is managed by XFCE sig etc etc So I would say that the GNOME team is within its rights in managing its spin. Whether it is named default etc is someone else's problem. This has come up before and I think it's just plain unclear :-( The problem is that the desktop spin and the default spin are kinda two different roles but they are occupied by the same Product. In browsing old tickets, I see some times when fesco has decided the default spin didn't have to do what other other things did and sometimes when fesco said they did. AFAICS, there's been no generalized policy put into place in regards to this. So it's something that is decided on in every case where it comes up. I don't think anyone thought they were doing anything wrong by making the change in the desktop spin but because the desktop spin has more than one owner, I've sent it back to FESCo to vote on whether allowing this change there is something we intended or not. (/me notes that if mattdm's Ring 1 was defined, this might be somewhat easier to decide upon. If sendmail was in Ring 1 it would be an expected part of the Fedora Platform. Anything general purpose and carrying the name Fedora would probably have to carry it as well. If sendmail was in Ring 2, it probably would be fine to choose whether to install it or not as it wasn't a guaranteed part of the BaseOS. [You could also s@sendmail@/usr/bin/sendmail@ in that analysis if you so chose]) -Toshio Reverting the change or creating the GNOME spin without rsyslog would be valid options. FESCo decided to leave rsyslog in standard, which means it should be installed in the default spin. Default spin is now shipped with GNOME, so it should use FESCo guidance. I wouldn't miss default spin at all. At least in Europe we are giving multi desktop DVD, so the default lost it's purpose anyway. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On 07/26/2013 01:47 AM, Lennart Poettering wrote: [1] "Onsen", in Berlin-Friedrichshain (recommended) Hmmm I must try it. Hard to find real Japanese in this city. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Fri, Jul 26, 2013 at 1:20 AM, Toshio Kuratomi wrote: > On Thu, Jul 25, 2013 at 05:09:54PM -0600, Stephen John Smoogen wrote: >> On 25 July 2013 16:59, Billy Crook wrote: >> > On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: >> >> Given the amount of time that he spent on the mailing-list fighting for >> >> those features, then it looks like a waste of time, that work has been >> >> done. >> > >> > Unfeatures technically. He wanted to remove features from the Default >> > spin. Subtracting functionality is not a feature. He wanted an >> > unfeature. >> > >> >> No he wanted out of the default install. We have a badly defined >> naming scheme which is causing confusion: >> >> default install -> what you get when you put the DVD in and do a click >> through install. >> default spin -> The GNOME desktop livecd. >> >> Spins are managed by their respective "teams": >> default has been GNOME and managed by GNOME sig >> kde is managed by KDE sig >> xfce is managed by XFCE sig >> etc etc >> >> So I would say that the GNOME team is within its rights in managing >> its spin. Whether it is named default etc is someone else's problem. >> > This has come up before and I think it's just plain unclear :-( > > The problem is that the desktop spin and the default spin are kinda two > different roles but they are occupied by the same Product. In browsing old > tickets, I see some times when fesco has decided the default spin didn't > have to do what other other things did and sometimes when fesco said they > did. AFAICS, there's been no generalized policy put into place in regards > to this. So it's something that is decided on in every case where it comes > up. > > I don't think anyone thought they were doing anything wrong by making the > change in the desktop spin but because the desktop spin has more than one > owner, I've sent it back to FESCo to vote on whether allowing this change > there is something we intended or not. Well it is a desktop spin after all. Most of the "keep sendmail and syslog" arguments where more server related things. And the "but what if I install app foo that requires syslog" .. well the app has to put in rpm requires. Like for pretty much everything else. > (/me notes that if mattdm's Ring 1 was defined, this might be somewhat > easier to decide upon. If sendmail was in Ring 1 it would be an expected > part of the Fedora Platform. Anything general purpose and carrying the name > Fedora would probably have to carry it as well. If sendmail was in Ring 2, > it probably would be fine to choose whether to install it or not as it > wasn't a guaranteed part of the BaseOS. [You could also > s@sendmail@/usr/bin/sendmail@ in that analysis if you so chose]) /me notes the the whole "ring concept" is utter nonsense but that's a different topic ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, 2013-07-25 at 18:48 -0700, Dan Mashal wrote: > On Thu, Jul 25, 2013 at 6:33 PM, Chris Murphy wrote: > > > > On Jul 25, 2013, at 6:42 PM, Dan Mashal wrote: > > > >> On Thu, Jul 25, 2013 at 4:47 PM, Lennart Poettering > >> wrote: > >>> > >>> "He" didn't depart from the meeting. He was at dinner with friends and > >>> only had a peek every now and then on his phone while having some > >>> delicious Japanese food [1] which turned out to be much more fun than > >>> that meeting. > >> > >> > >> Your attitude is atrocious. > > > > Opinions are funny things. I think his attitude is amusing as well as > > informative. If Onsen does some things other than sushi (i.e. food that > > uses names of things that by most all DNA testing are actually differently > > named things) I should like to try it next time I'm in Berlin. Oh who am I > > kidding, I probably will eat wrong named things anyway. > > I didn't find it funny. I found it arrogant. > > > Right, because when a decaying concept from the pleistocene by default only > > increases boot times and consumes limited resources (it certainly doesn't > > do anything useful out of the box), the intelligent thing to do is > > rearrange the deck chairs. > > > > Deprecation is to a distribution, as fire is to a forest. It keeps them > > healthy instead of cinder boxes. > > > > Really so much whining over having to yum install something? I think this > > thread is a sufficiently tenderized horse. > > Why not build it into some other component then? > > I already to yum install too many things to get a working system. Seriously, folks, that's enough. Stop it now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 6:33 PM, Chris Murphy wrote: > > On Jul 25, 2013, at 6:42 PM, Dan Mashal wrote: > >> On Thu, Jul 25, 2013 at 4:47 PM, Lennart Poettering >> wrote: >>> >>> "He" didn't depart from the meeting. He was at dinner with friends and >>> only had a peek every now and then on his phone while having some >>> delicious Japanese food [1] which turned out to be much more fun than >>> that meeting. >> >> >> Your attitude is atrocious. > > Opinions are funny things. I think his attitude is amusing as well as > informative. If Onsen does some things other than sushi (i.e. food that uses > names of things that by most all DNA testing are actually differently named > things) I should like to try it next time I'm in Berlin. Oh who am I kidding, > I probably will eat wrong named things anyway. I didn't find it funny. I found it arrogant. > Right, because when a decaying concept from the pleistocene by default only > increases boot times and consumes limited resources (it certainly doesn't do > anything useful out of the box), the intelligent thing to do is rearrange the > deck chairs. > > Deprecation is to a distribution, as fire is to a forest. It keeps them > healthy instead of cinder boxes. > > Really so much whining over having to yum install something? I think this > thread is a sufficiently tenderized horse. Why not build it into some other component then? I already to yum install too many things to get a working system. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Jul 25, 2013, at 6:42 PM, Dan Mashal wrote: > On Thu, Jul 25, 2013 at 4:47 PM, Lennart Poettering > wrote: >> >> "He" didn't depart from the meeting. He was at dinner with friends and >> only had a peek every now and then on his phone while having some >> delicious Japanese food [1] which turned out to be much more fun than >> that meeting. > > > Your attitude is atrocious. Opinions are funny things. I think his attitude is amusing as well as informative. If Onsen does some things other than sushi (i.e. food that uses names of things that by most all DNA testing are actually differently named things) I should like to try it next time I'm in Berlin. Oh who am I kidding, I probably will eat wrong named things anyway. > Had you proposed to replace sendmail with postfix that might have been > an intelligent argument. Right, because when a decaying concept from the pleistocene by default only increases boot times and consumes limited resources (it certainly doesn't do anything useful out of the box), the intelligent thing to do is rearrange the deck chairs. Deprecation is to a distribution, as fire is to a forest. It keeps them healthy instead of cinder boxes. Really so much whining over having to yum install something? I think this thread is a sufficiently tenderized horse. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 6:14 PM, Rahul Sundaram wrote: > Hi > > > On Thu, Jul 25, 2013 at 8:42 PM, Dan Mashal >> >> >> Your attitude is atrocious. Go start your own distro. You already >> ruined ours with systemd and PulseAudio. Stop acting like you own >> everything. We have boards, comittees, and plenty of intelligent >> people to decide things. > > > Please don't attack a fellow contributor because he has a different opinion > from yours. The same intelligent people have decided to approve PulseAudio > and systemd as well. I think you missed my point, but you got the gist. We have way more important things to discuss than sendmail. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
Hi On Thu, Jul 25, 2013 at 8:42 PM, Dan Mashal > > Your attitude is atrocious. Go start your own distro. You already > ruined ours with systemd and PulseAudio. Stop acting like you own > everything. We have boards, comittees, and plenty of intelligent > people to decide things. > Please don't attack a fellow contributor because he has a different opinion from yours. The same intelligent people have decided to approve PulseAudio and systemd as well. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 4:47 PM, Lennart Poettering wrote: > On Thu, 25.07.13 17:59, Billy Crook (billycr...@gmail.com) wrote: > >> After some reasonable dialog on the issue FESCo meeting, it was clear >> he wasn't going to immediately get exactly what he wanted without any >> challenge. So he departed the meeting. In his absence, FESCo decided >> to compromise and remove from @core, but not @standard. > > "He" didn't depart from the meeting. He was at dinner with friends and > only had a peek every now and then on his phone while having some > delicious Japanese food [1] which turned out to be much more fun than > that meeting. > > Lennart > > [1] "Onsen", in Berlin-Friedrichshain (recommended) > > -- > Lennart Poettering - Red Hat, Inc. Your attitude is atrocious. Go start your own distro. You already ruined ours with systemd and PulseAudio. Stop acting like you own everything. We have boards, comittees, and plenty of intelligent people to decide things. Had you proposed to replace sendmail with postfix that might have been an intelligent argument. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 4:20 PM, Toshio Kuratomi wrote: > On Thu, Jul 25, 2013 at 05:09:54PM -0600, Stephen John Smoogen wrote: >> On 25 July 2013 16:59, Billy Crook wrote: >> > On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: >> >> Given the amount of time that he spent on the mailing-list fighting for >> >> those features, then it looks like a waste of time, that work has been >> >> done. >> > >> > Unfeatures technically. He wanted to remove features from the Default >> > spin. Subtracting functionality is not a feature. He wanted an >> > unfeature. >> > >> >> No he wanted out of the default install. We have a badly defined >> naming scheme which is causing confusion: >> >> default install -> what you get when you put the DVD in and do a click >> through install. >> default spin -> The GNOME desktop livecd. >> >> Spins are managed by their respective "teams": >> default has been GNOME and managed by GNOME sig >> kde is managed by KDE sig >> xfce is managed by XFCE sig >> etc etc >> >> So I would say that the GNOME team is within its rights in managing >> its spin. Whether it is named default etc is someone else's problem. >> > This has come up before and I think it's just plain unclear :-( > > The problem is that the desktop spin and the default spin are kinda two > different roles but they are occupied by the same Product. In browsing old > tickets, I see some times when fesco has decided the default spin didn't > have to do what other other things did and sometimes when fesco said they > did. AFAICS, there's been no generalized policy put into place in regards > to this. So it's something that is decided on in every case where it comes > up. > > I don't think anyone thought they were doing anything wrong by making the > change in the desktop spin but because the desktop spin has more than one > owner, I've sent it back to FESCo to vote on whether allowing this change > there is something we intended or not. > > (/me notes that if mattdm's Ring 1 was defined, this might be somewhat > easier to decide upon. If sendmail was in Ring 1 it would be an expected > part of the Fedora Platform. Anything general purpose and carrying the name > Fedora would probably have to carry it as well. If sendmail was in Ring 2, > it probably would be fine to choose whether to install it or not as it > wasn't a guaranteed part of the BaseOS. [You could also > s@sendmail@/usr/bin/sendmail@ in that analysis if you so chose]) > > -Toshio > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel That was done here by Ray: https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=279c21441cdacb1d548dc1f1b39acc2882ef4024 And good for them. As far as the MATE spin goes I have no plans to do this. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, 25.07.13 17:59, Billy Crook (billycr...@gmail.com) wrote: > After some reasonable dialog on the issue FESCo meeting, it was clear > he wasn't going to immediately get exactly what he wanted without any > challenge. So he departed the meeting. In his absence, FESCo decided > to compromise and remove from @core, but not @standard. "He" didn't depart from the meeting. He was at dinner with friends and only had a peek every now and then on his phone while having some delicious Japanese food [1] which turned out to be much more fun than that meeting. Lennart [1] "Onsen", in Berlin-Friedrichshain (recommended) -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 05:09:54PM -0600, Stephen John Smoogen wrote: > On 25 July 2013 16:59, Billy Crook wrote: > > On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: > >> Given the amount of time that he spent on the mailing-list fighting for > >> those features, then it looks like a waste of time, that work has been > >> done. > > > > Unfeatures technically. He wanted to remove features from the Default > > spin. Subtracting functionality is not a feature. He wanted an > > unfeature. > > > > No he wanted out of the default install. We have a badly defined > naming scheme which is causing confusion: > > default install -> what you get when you put the DVD in and do a click > through install. > default spin -> The GNOME desktop livecd. > > Spins are managed by their respective "teams": > default has been GNOME and managed by GNOME sig > kde is managed by KDE sig > xfce is managed by XFCE sig > etc etc > > So I would say that the GNOME team is within its rights in managing > its spin. Whether it is named default etc is someone else's problem. > This has come up before and I think it's just plain unclear :-( The problem is that the desktop spin and the default spin are kinda two different roles but they are occupied by the same Product. In browsing old tickets, I see some times when fesco has decided the default spin didn't have to do what other other things did and sometimes when fesco said they did. AFAICS, there's been no generalized policy put into place in regards to this. So it's something that is decided on in every case where it comes up. I don't think anyone thought they were doing anything wrong by making the change in the desktop spin but because the desktop spin has more than one owner, I've sent it back to FESCo to vote on whether allowing this change there is something we intended or not. (/me notes that if mattdm's Ring 1 was defined, this might be somewhat easier to decide upon. If sendmail was in Ring 1 it would be an expected part of the Fedora Platform. Anything general purpose and carrying the name Fedora would probably have to carry it as well. If sendmail was in Ring 2, it probably would be fine to choose whether to install it or not as it wasn't a guaranteed part of the BaseOS. [You could also s@sendmail@/usr/bin/sendmail@ in that analysis if you so chose]) -Toshio pgplz6kzmnFnF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, 2013-07-25 at 17:09 -0600, Stephen John Smoogen wrote: > On 25 July 2013 16:59, Billy Crook wrote: > > On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: > >> Given the amount of time that he spent on the mailing-list fighting for > >> those features, then it looks like a waste of time, that work has been > >> done. > > > > Unfeatures technically. He wanted to remove features from the Default > > spin. Subtracting functionality is not a feature. He wanted an > > unfeature. > > > > No he wanted out of the default install. We have a badly defined > naming scheme which is causing confusion: > > default install -> what you get when you put the DVD in and do a click > through install. > default spin -> The GNOME desktop livecd. > > Spins are managed by their respective "teams": > default has been GNOME and managed by GNOME sig > kde is managed by KDE sig > xfce is managed by XFCE sig > etc etc > > So I would say that the GNOME team is within its rights in managing > its spin. Whether it is named default etc is someone else's problem. The tension between Desktop being a 'spin' and also being our 'default deliverable' has never really been resolved comprehensively at a policy level, as I see it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On 25 July 2013 16:59, Billy Crook wrote: > On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: >> Given the amount of time that he spent on the mailing-list fighting for >> those features, then it looks like a waste of time, that work has been done. > > Unfeatures technically. He wanted to remove features from the Default > spin. Subtracting functionality is not a feature. He wanted an > unfeature. > No he wanted out of the default install. We have a badly defined naming scheme which is causing confusion: default install -> what you get when you put the DVD in and do a click through install. default spin -> The GNOME desktop livecd. Spins are managed by their respective "teams": default has been GNOME and managed by GNOME sig kde is managed by KDE sig xfce is managed by XFCE sig etc etc So I would say that the GNOME team is within its rights in managing its spin. Whether it is named default etc is someone else's problem. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 3:36 PM, Bastien Nocera wrote: > Given the amount of time that he spent on the mailing-list fighting for those > features, then it looks like a waste of time, that work has been done. Unfeatures technically. He wanted to remove features from the Default spin. Subtracting functionality is not a feature. He wanted an unfeature. After some reasonable dialog on the issue FESCo meeting, it was clear he wasn't going to immediately get exactly what he wanted without any challenge. So he departed the meeting. In his absence, FESCo decided to compromise and remove from @core, but not @standard. > Thankfully, it's been removed from the default Desktop spin. If it has been removed from the default Desktop spin, is not that in blatant contradiction of FESCo's decision yesterday? Who removed it? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, Jul 25, 2013 at 04:36:20PM -0400, Bastien Nocera wrote: > - Original Message - > > On Thu, 2013-07-25 at 17:36 +0200, Lennart Poettering wrote: > > > On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: > > > > > > > Partially accepted Changes > > > > * No Default Sendmail - > > > > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - > > > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html > > > > > > > > Sendmail will be removed from @core. Removal of sendmail from @standard > > > > didn't > > > > pass. Note: About @standard group might be decided in next release of > > > > Fedora. > > > > > > > > * No Default Syslog - > > > > https://fedoraproject.org/wiki/Changes/NoDefaultSyslog > > > > discussed on > > > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html > > > > > > > > Remove rsyslog from @core, move to @standard pending revaluation in > > > > future. > > > > > > Note that this is not the decision I was interested in. I will hence not > > > work on the implemetation of either of these features. Unless Matthew > > > takes them over alone I will will mark these feature pages as obsolete > > > as they didn't get agreed on. > > > > Taking rsyslog out of @core is a one-line commit to comps which someone > > could do in 30 seconds. It hardly needs 'working on'. > > Given the amount of time that he spent on the mailing-list fighting for > those features, then it looks like a waste of time, that work has been > done. > Unfortunately, the most controversial changes are going to generate the most discussion on the mailing lists and also have the most chance of failing or requiring modifications in order to be allowed. There's just no getting around that. > Thankfully, it's been removed from the default Desktop spin. > Someone pointed this out to me on IRC earlier. I'm not sure whether that's something that FESCo needs to also approve or not and whether they would. I was hoping I might find some precedent in past tickets but although there seems to be plenty of precedent, it doesn't all agree with each other. I've tacked on this question to the FESCo feature ticket: https://fedorahosted.org/fesco/ticket/1143 -Toshio pgpuIsxO9VAUD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
- Original Message - > On Thu, 2013-07-25 at 17:36 +0200, Lennart Poettering wrote: > > On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: > > > > > Partially accepted Changes > > > * No Default Sendmail - > > > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - > > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html > > > > > > Sendmail will be removed from @core. Removal of sendmail from @standard > > > didn't > > > pass. Note: About @standard group might be decided in next release of > > > Fedora. > > > > > > * No Default Syslog - > > > https://fedoraproject.org/wiki/Changes/NoDefaultSyslog > > > discussed on > > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html > > > > > > Remove rsyslog from @core, move to @standard pending revaluation in > > > future. > > > > Note that this is not the decision I was interested in. I will hence not > > work on the implemetation of either of these features. Unless Matthew > > takes them over alone I will will mark these feature pages as obsolete > > as they didn't get agreed on. > > Taking rsyslog out of @core is a one-line commit to comps which someone > could do in 30 seconds. It hardly needs 'working on'. Given the amount of time that he spent on the mailing-list fighting for those features, then it looks like a waste of time, that work has been done. Thankfully, it's been removed from the default Desktop spin. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, 2013-07-25 at 17:36 +0200, Lennart Poettering wrote: > On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: > > > Partially accepted Changes > > * No Default Sendmail - > > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html > > > > Sendmail will be removed from @core. Removal of sendmail from @standard > > didn't > > pass. Note: About @standard group might be decided in next release of > > Fedora. > > > > * No Default Syslog - > > https://fedoraproject.org/wiki/Changes/NoDefaultSyslog > > discussed on > > https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html > > > > Remove rsyslog from @core, move to @standard pending revaluation in future. > > Note that this is not the decision I was interested in. I will hence not > work on the implemetation of either of these features. Unless Matthew > takes them over alone I will will mark these feature pages as obsolete > as they didn't get agreed on. Taking rsyslog out of @core is a one-line commit to comps which someone could do in 30 seconds. It hardly needs 'working on'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, 2013-07-25 at 14:39 +0200, Jaroslav Reznik wrote: > Greeting! > This is a summary of accepted Fedora 20 Changes by FESCo for week 30 > (2013-07-24 meeting). Thanks Jaro! Could you folks please review the Visible Cloud Change as a priority at the next meeting? If that's accepted it will require some changes to the QA procedures and we'd like to get them in place before we start rolling Alpha composes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Summary of accepted Fedora 20 Changes - week 30
On Thu, 25.07.13 14:39, Jaroslav Reznik (jrez...@redhat.com) wrote: > Partially accepted Changes > * No Default Sendmail - > https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - > https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html > > Sendmail will be removed from @core. Removal of sendmail from @standard > didn't > pass. Note: About @standard group might be decided in next release of Fedora. > > * No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog > discussed on > https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html > > Remove rsyslog from @core, move to @standard pending revaluation in future. Note that this is not the decision I was interested in. I will hence not work on the implemetation of either of these features. Unless Matthew takes them over alone I will will mark these feature pages as obsolete as they didn't get agreed on. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary of accepted Fedora 20 Changes - week 30
Greeting! This is a summary of accepted Fedora 20 Changes by FESCo for week 30 (2013-07-24 meeting). = System Wide Changes = * Unversioned Docdirs - https://fedoraproject.org/wiki/Changes/UnversionedDocdirs discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185633.html * Allow kdump on secureboot machines - https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185133.html Partially accepted Changes * No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail - https://lists.fedoraproject.org/pipermail/devel/2013-July/185328.html Sendmail will be removed from @core. Removal of sendmail from @standard didn't pass. Note: About @standard group might be decided in next release of Fedora. * No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185329.html Remove rsyslog from @core, move to @standard pending revaluation in future. * Change Packaging Guidelines to discourage requires into /bin and /sbin - https://fedoraproject.org/wiki/Changes/NoBinDeps discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185632.html FESCo agreed to defer to FPC to figure out the right thing to do here, reevaluate if this needs to be handled as a Change later = Self Contained Changes = * Vagrant - https://fedoraproject.org/wiki/Changes/Vagrant discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185864.html * GNOME 3.10 - https://fedoraproject.org/wiki/Changes/Gnome3.10 discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185381.html * DNSSEC support for FreeIPA - http://fedoraproject.org/wiki/Changes/IPAv3DNSSEC discussed on http://lists.fedoraproject.org/pipermail/devel/2013-July/185626.html * Snapshot and Rollback Tool - http://fedoraproject.org/wiki/Changes/Rollback discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185804.html * Transitive Trusts with Active Directory support for FreeIPA - http://fedoraproject.org/wiki/Changes/IPAv3TransitiveTrusts discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185634.html * OS Installer Support for LVM Thin Provisioning - http://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185803.html FESCo accepts LVM thinp as a Change and asks to treat usability issues as bugs to be worked out, change documentation from N/A to 'please document in install guide' and speak to maintainers of tools like coreutils. * Enlightenment - http://fedoraproject.org/wiki/Changes/Enlightenment discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/186080.html (announced on 2013-07-18 but without complaints) * Apache OpenOffice - http://fedoraproject.org/wiki/Changes/ApacheOpenOffice discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/ Apache OpenOffice Change is accepted under the condition that the conflicts with libreoffice must be worked out. openoffice and libreoffice packagers get to work them out. There is no Fesco mandate that libreoffice must change to accomodate openoffice at this time. alternatives is not the way to resolve the conflicts but environment-modules may be looked at as a similar means to achieve that. mattdm wants this to be perfectly clear: FESCo does not grant automatic exceptions to our processes on any basis. * X2Go - http://fedoraproject.org//wiki/Changes/X2Go discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185644.html * Sugar 0.100 (1.0) - http://fedoraproject.org/wiki/Changes/Sugar-0.100 discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185808.html * SSSD Smart Card Support - http://fedoraproject.org/wiki/Changes/SSSD_Smart_Card_Support discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185977.html * ACPICA Tools Update - http://fedoraproject.org/wiki/Changes/AcpicaTools discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185802.html * Developer Assistant GUI - http://fedoraproject.org/wiki/Changes/DeveloperAssistantGUI discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185374.html * Role based access control with libvirt - http://fedoraproject.org/wiki/Changes/Virt_ACLs discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185419.html * SSSD CIFS plugin - http://fedoraproject.org/wiki/Changes/SSSD_CIFS_plugin discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185376.html * FreeIPA OTP UI - http://fedoraproject.org/wiki/Changes/IPAv3OTPUI discussed on https://lists.fedoraproject.org/pipermail/devel/2013-July/185657.html * Ryu Network Operating System - http://fedoraproject.org/wiki/Changes/Ryu discussed on https
