Re: Fedora should replace mailing lists with Discourse
On Fri, 2018-10-19 at 03:43 +, Máirín Duffy wrote: > I'm open to all of those suggestions as well as committing to design and CSS > work for them. I would need a web dev to help me though; I'm not great with > Django. > > Please note, the reason Hyperkitty didn't cause this sort of thread or > honestly any sort of drama or controversy when it was deployed is because it > required no current users to change anything about their workflow, with one > small exception - mm3 didn't come out w topic support which was used on the > packagers list. (I don't believe that's an issue anymore.) > > The whole point of the design was to enable a new group of would be > contributors be able to participate alongside the folks already there, so > that everyone could participate together. Existing ML users never need to use > Hyperkitty if they don't want to, and yet, users new to the project can start > reading and participating in threads right away w no mail client config and > never receiving a single email if they so desire. > > I believe quite strongly (and have from the start when I first heard of the > project) that Discourse's basic UX model is fundamentally flawed. If we > deploy discourse and roll it out, we *may* get new users, but as noted in > this thread, we will lose existing ones. Participating in upstream effort on > Discourse, improving it, etc is foolish bc the fundamental model is broken. > > When some people think of email, they think of mutt or thunderbird, annoying > client config, setting up procmail or fetchmail or whatever other complex > elaborate tools many of the ppl reading this use. Email is just a basic > standard. Discourse does not follow that standard. There is no reason a > social media timeline like experience for the teenagers is not possible using > email as the underlying system. Jabber never really took off, except Google > Hangouts and FB messenger both used it (no idea if they still do.) The reason > our open standards like email and xmpp are dying off is bc the primary biz > model of the companies that used them relies on getting eyes on ads, and > scanning content in ways that mean giving users a choice of client that works > best for their needs is off the table. Can we be careful with association of timelines with teenagers here? It's a tiny bit belittling, and makes us all sound old and out of touch, since my parents (who are obviously older than me) know what they are. I've been using Linux exclusively on the desktop for a bit over 15 years, so you can guess I'm not a teen. > Basically dont confuse the front end youre used to with the > underlying tech. > > I think it's a better idea to use a tool based on open standards, > that allows users to use the client experience that works best for > them. If you try to force everyone down one road it won't work. > > ~m > ___ > devel mailing list -- > devel@lists.fedoraproject.org > > To unsubscribe send an email to > devel-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://getfedora.org/code-of-conduct.html > > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Call to retire gstreamer-0.10
> beets-plugins Beets can use gstreamer 1.x in the latest releases. I sent this weeks ago when it was a popular topic, but my email client was misconfigured, so it never made it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Call to retire gstreamer-0.10
> beets-plugins Beets uses gstreamer 1.x in the latest release. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: dnf still is unuseable
On Mon, 2016-01-18 at 00:00 +0100, Pierre-Yves Chibon wrote: > On Sun, Jan 17, 2016 at 11:48:23PM +0100, Heiko Adams wrote: > > Am Sonntag, den 17.01.2016, 23:27 +0100 schrieb Reindl Harald: > > > may i suggest to forget that dnf ever existed and switch back to > > > yum? > > > > > > ongoing problems in the core-task solve dependencies is not > > > production > > > ready AND REMOVE THE DEPRECATED WARNINGS for "package-cleanup" > > > and > > > "yum-deprecated" until DNF is useable and provides the same > > > capabilities > > > as yum/yum-utils > > > > > And please don't forget that the autoremove command is unusable at > > least since somewhere between Fedora 23 beta and final. That's > > absolutely unacceptable! > > > > So please fix your shit or remove the parts you can't fix! And > > until > > then de-deprecate yum until dnf is feature-complete, in a usable > > stage > > and you can guarantee dnf will stay in that stage for a long time. > > I would like to point out that this way of communicating is not > welcome on this > list. If you have something to say, please say it but be respectful > in your tone > and wording with everyone and everyone's work. We are all on the same > boat and > shooting each other on the legs isn't going to help. > You may want to refresh your memory on our code of conduct: > https://getfedora.org/code-of-conduct > > > Pierre > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > org agreed. This is a major reason I choose not to participate on Fedora lists. I can't trust that even the limited code of conduct that exists will even be enforced. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Updates (was Fedora 23 Final RC10 status is GO !)
On Wed, 2015-11-04 at 20:03 -0600, Michael Catanzaro wrote: > On Thu, 2015-11-05 at 02:16 +0100, Kevin Kofler wrote: > > Michael Catanzaro wrote: > > > 1) More time to catch regressions > > > > In theory. In practice, it mostly means more wasted time until a > > regression > > is FIXED, i.e., it is entirely counterproductive. Many regressions > > are only > > noticed once the update goes stable, because that's when most users > > start > > trying it. > > I think we would need an alternate "fast path" for updates, in case > of > regressions. I agree with you that the current karma system hurts > more > than it helps there. It should be possible to push an update that > merely reverts a previous update directly to stable. > > > I don't see how even longer delays in testing would help. The > > majority that > > does not have updates-testing enabled won't get it before it goes > > stable no > > matter how long it sits in testing. The users who use updates- > > testing > > are > > those who want updates fast and so will get it within the first > > couple days. > > In practice, I've seen bugs caught in updates-testing, and others > caught only after entering stable. More time in updates-testing can > only reduce regressions that make it to stable, but yes, also delay > fixes that we would wish to release sooner. I suspect the ideal > amount > of time spent in testing is "more than we do now." > > But since you pointed out that service packs could be implemented on > the existing updates system, I'm now leaning towards keeping > everything > we have now the same, and using the stable updates repo as a level of > testing for service packs released to Workstation users via GNOME > Software. (You could still get all the latest updates with dnf if you > want.) > > > I don't see how a huge mix of unrelated updates is in any way > > easier > > to QA > > than the individual small, targeted updates. In fact, I think it is > > the > > exact opposite: there is no way to adequately QA the whole service > > pack, it > > just does not scale. > > Well yes, it would be worse if we got rid of the karma system and no > longer QAed individual updates, but we should layer our release QA on > top of the updates we do now. After an update graduates from testing, > it'll be automatically included in the next service pack. Then every, > say, six weeks, we do the normal release validation on it and release > updated install media. If it doesn't pass release validation, then > quality has decreased since the initial release and we know there's a > problem with our updates. > > > > 3) Less-frequent updates > > > > That is a BAD thing. I want to get my bugfixes as quickly as > > possible. (In > > fact, I'm unhappy that our infrastructure does not support instant > > pushes.) > > I have Apper set to check for updates hourly because the default > > daily is > > too slow for me! Sure, we don't have hourly pushes (sadly), but > > daily > > means > > up to an ADDITIONAL day of delay. > > Ah, but while you like this for yourself, I think that is too fast > for > the common user. > > Maybe you're right, though. The frequency that we release updates > itself isn't necessarily the problem, so much as the frequency the > tool > checks for updates. We shouldn't have weekly LO updates by *default*, > but that shouldn't stop you from getting them if you want them. Maybe > we should just configure GNOME Software to check for updates less > frequently, and apply only the security updates and no other update > when there is a security issue. Or do service packs and not worry > about > it. > I've been using dnf-automatic with: apply_updates=True upgrade_type=security on Fedora Server for that. > Either way allows us to achieve slower updates for Workstation > without > slowing things down for you. > > > The negative effect that the whole thing hits at once would be the > > much more > > noticeable effect. So the updates would actually feel slower, and > > probably > > even BE slower because the mirrors would be swamped, just as they > > are > > on a > > release day. > > True, that is a risk... but I think it is less an exception than you > believe. I notice most package updates are for packages that were > updated quite recently. I speculate that a small portion of packages > in > the distro make for a fairly large portion of updates, and that > service > packs won't balloon to be as large as you expect. Regardless, they > shouldn't be as bad as a post-install update is now, which take 30-45 > minutes for me. Install media respins will fix that. > > But yes, you're right in that we have a trade-off between frequency > of > updates and duration of updates. We have less total time spent > updating > if updates are further apart, as updates that would otherwise be > applied separately are obsoleted by newer updates, but more total > time > spent in each individual update. > > > As for bandwidth-limited users, what would
Re: Self Introduction: Benjamin Roberts
On Tue, 2015-08-25 at 12:28 +1000, Benjamin George Roberts wrote: Good Afternoon My name is Benjamin Roberts. I've recently made a package review request (https://bugzilla.redhat.com/show_bug.cgi?id=1209809) and am hoping to have the package accepted and acquire member sponsorship. A quick introduction about myself: I'm a 3rd year software engineering student Have been using Fedora since F18 I've completed research projects in and related to a couple of open source projects (HHVM, JikesRVM, rpsl4j/OpenDaylight) Am interested in working in computer engineering/systems programming in the future I've been packaging some small applications for my personal machines and for group project VM's for the last two years and would like to maintain official packages for some of these tools I think Fedora users will find useful. Regards and looking forward to working with you Benjamin Roberts -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Hi Benjamin! Let me know if you're interested in helping to package HHVM. I had a WIP package already, but it's not in a state acceptable to Fedora due to certain bundled dependencies. -- 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: bodhi 2 now live
On Sat, 2015-08-22 at 10:46 +0800, Christopher Meng wrote: On 8/22/15, Haïkel hgue...@fedoraproject.org wrote: Sometimes, I wonder if you're not doing this on purpose. Rather than preventing our infrastructure team to fix the actual issues with useless squabbles, just open tickets to let them know. Forget the ridiculous github excuse, fedorahosted trac instance still accepts tickets. Out of respect of the work done by your fellow contributors, stop bikeshedding on the list and start filling/fixing tickets. It's kinda sad, that you never have a nice word for your peers. In the end, you might end up treated as badly as you treat them. Occupying the moral high ground doesn't help as well. -- Let's restate it simpler then. Be nicer to people. Assume the best. Yours sincerely, Christopher Meng http://awk.io -- 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: Firefox testing - offscreen surfaces and OMTC
On Fri, 2015-08-21 at 15:24 +0200, Martin Stransky wrote: I see the same flickering on NVIDIA hardware. Intel seems to be fine. I'm getting flickering (but only when scrolling up) on the linked cairo xrender bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1015218 Adapter Description Intel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Mobile Asynchronous Pan/Zoom none Device ID Mesa DRI Intel(R) Haswell Mobile Driver Version 3.0 Mesa 10.6.3 (git-ccef890) GPU Accelerated Windows 0/3 Basic (OMTC) Supports Hardware H264 Decoding false Vendor ID Intel Open Source Technology Center WebGL Renderer Intel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Mobile windowLayerManagerRemotetrue AzureCanvasBackend cairo AzureContentBackend cairo AzureFallbackCanvasBackend none AzureSkiaAccelerated0 On 08/21/2015 03:06 PM, Alexander Ploumistos wrote: On Fri, Aug 21, 2015 at 11:33 AM, Martin Stransky stran...@redhat.com wrote: - Install Firefox 40 on Fedora 22,23,Rawhide (you'd need Gtk3 build) - go to about:config, click to any key and add a new one, boolean type. The new key name is layers.use-image-offscreen-surfaces and set it to true. - enable layers.offmainthreadcomposition.enabled which may be disabled now. What about layers.acceleration.force-enabled? And you're set now. Please report any oddity (different than the usual ones :)) at #BZ. On my desktop (f22), with a GeForce 9800 GT and the 340.76 driver from nVidia I am getting a lot of flickering when I scroll through some pages (e.g. MDN, Ars Techinca, gmail) especially when they contain fixed or sticky elements or elements whose background image is repeated along the x and y axes. If you can get your hands on similar hardware, scroll through this: https://developer.mozilla.org/en-US/docs/Web/CSS/position On a recent laptop (f22), with nVidia and Intel dual graphics, there is no such problem on either adapter. I have been unable to reproduce the crashes we were investigating so far, so perhaps enabling layers.use-image-offscreen-surfaces could be a solution (and I should get a newer graphics card - anyone cares to get me a late birthday present?). This is the graphics information provided by firefox for the desktop: Adapter DescriptionNVIDIA Corporation -- GeForce 9800 GT/PCIe/SSE2 Asynchronous Pan/Zoomnone Device IDGeForce 9800 GT/PCIe/SSE2 Driver Version3.3.0 NVIDIA 340.76 GPU Accelerated Windows0/1 Basic (OMTC) Supports Hardware H264 Decodingfalse Vendor IDNVIDIA Corporation WebGL RendererNVIDIA Corporation -- GeForce 9800 GT/PCIe/SSE2 windowLayerManagerRemotetrue AzureCanvasBackendcairo AzureContentBackendcairo AzureFallbackCanvasBackendnone AzureSkiaAccelerated0 and for the laptop: Adapter DescriptionNVIDIA Corporation -- GeForce GTX 860M/PCIe/SSE2 Asynchronous Pan/Zoomnone Device IDGeForce GTX 860M/PCIe/SSE2 Driver Version4.5.0 NVIDIA 352.21 GPU Accelerated Windows0/1 Basic (OMTC) Supports Hardware H264 Decodingfalse Vendor IDNVIDIA Corporation WebGL RendererNVIDIA Corporation -- GeForce GTX 860M/PCIe/SSE2 windowLayerManagerRemotetrue AzureCanvasBackendcairo AzureContentBackendcairo AzureFallbackCanvasBackendnone AzureSkiaAccelerated0 Adapter DescriptionIntel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Mobile Asynchronous Pan/Zoomnone Device IDMesa DRI Intel(R) Haswell Mobile Driver Version3.0 Mesa 10.6.3 (git-ccef890) GPU Accelerated Windows0/1 Basic (OMTC) Supports Hardware H264 Decodingfalse Vendor IDIntel Open Source Technology Center WebGL RendererIntel Open Source Technology Center -- Mesa DRI Intel(R) Haswell Mobile windowLayerManagerRemotetrue AzureCanvasBackendcairo AzureContentBackendcairo AzureFallbackCanvasBackendnone AzureSkiaAccelerated0 -- 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: New version of Copr (includes dist-git)
On Wed, 2015-08-12 at 10:31 +0200, Miroslav Suchý wrote: It is my pleasure to announce that we just upgraded https://copr.fedoraproject.org It includes several major improvements: * UI converted to PatternFly [1]. Most visible change is that tables (e.g. list of builds) can be sorted using any column and you can filter visible rows using any value. * dist-git support -- We store your SRPM in dist-git now. It is not accessible directly using fedpkg (it is in plan later). Dist-git is browsable via cgit [2]. This allows us to offer you upload of SRPM directly from your workstation. Just navigate to: New Build - Upload SRPM or if you upgrade to python-copr-1.58-1 (submitted to updates just today) then you can do: copr-cli build name/project ./some.src.rpm While we assume that uploading SRPM will be most popular method, we preserved option to pass SRPM url. You can see new state of your build - Importing. It is obviously the moment when we import your SRPM into dist-git. * In project properties (Edit tab) you can now add you email if you want to be contacted by users in case of some problems with your project. * We improved queue handling of various architectures. This should fix those long waiting time of PPC64LE builds. Big kudos go to Valentin G., Adam Š. and Jakub K., who implemented those features. [1] https://www.patternfly.org/ [2] http://copr-dist-git.fedorainfracloud.org/cgit/ Mirek Suchý Thanks to everybody involved in this. I'm especially happy with the SRPM upload! -- 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: Updates push status - 20150725
On Fri, 2015-07-31 at 02:40 +0200, Kevin Kofler wrote: Kevin Fenzi wrote: Friday (20150724), it hit a problem in the fedora22 updates-testing atomic compose. We worked thru and fixed one, but there's still some sort of issue preventing it from completing. ;( So this useless Fedora Atomic toy now delayed updates (including security updates!) for everybody, i.e., also for the 99% of our users who do NOT use Atomic? I find it unacceptable that we are being held hostage by that kind of niche project (considering that one argument for adding support for it was that if we don't want to use it, it won't affect us). Kevin Kofler Please have respect for other peoples work. I expect to find this language on common web forums, but we can do better here. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gross DNF bandwidth inefficiency if filesystem space limited
On Thu, 2015-07-30 at 03:21 -0400, Felix Miata wrote: # dnf upgrade (dnf nearly exhausts freespace downloading all packages before installing any packages) dnf then reports package xxx needs ##MB on / filesystem and exits without doing any installing dnf all deletes downloaded packages # dnf upgrade (package subset, e.g. dnf* rpm* a* b* c* d* e* f* x* y* z*) dnf downloads needed packages previously downloaded but later deleted, then installs downloaded packages # dnf upgrade dnf downloads needed packages previously downloaded but later deleted, then installs downloaded packages Is the above deletion of freshly downloaded packages (wasted time, wasted bandwidth) known or expected? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ you should take your words in your email signature into account before using words like gross and wasted time Try to show some understanding to the DNF maintainers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
