Introducing the New QA Dashboard: Gain Insights into the Fedora QA Community
Dear Fedora Community, The Fedora QA team is excited to announce the launch of our brand new QA Dashboard for the Fedora QA community! This dashboard has been designed to provide you with valuable insights into what is happening in the Fedora QA space, helping us all work together more efficiently and effectively. As an open-source community, our collective efforts have always been focused on ensuring the quality and reliability of Fedora. The new QA Dashboard is a significant step forward in enhancing our QA processes and fostering collaboration among contributors. Here are the key features and benefits of the QA Dashboard: Current Development Schedule: The dashboard provides an overview of the development schedule of the current release with important milestones for you to plan and stay ahead of the curve. Blockers and Freeze Exceptions: You can now view the current release Blockers and Freeze Exceptions along with the breakup of Proposed and Accepted. Calendar of Events: Take a look at what is coming up in the next 7 days. Meetings and Test Days to plan your schedule accordingly. Meeting Minutes: Stay up-to-date with the latest decisions made during the QA meeting. Meeting minutes will keep you informed, ensuring that you are always aware of the current state of Fedora QA. To access the new QA Dashboard, please visit https://qa.fedoraproject.org/ We encourage you to explore the QA Dashboard, take advantage of its features, and provide feedback. Your input is invaluable in improving the dashboard and making it even more beneficial to the entire Fedora QA community. Tell us what you would like to see in the dashboard! Thank you for your continued dedication to the Fedora QA community. Let's make the most of this new dashboard and work together to ensure the highest quality standards for Fedora. If you have any questions, suggestions, or need assistance with the QA Dashboard, please don't hesitate to reach out to us. Regards, -- S*UDHIR D* SENIOR MANAGER, FEDORA QE, ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora CI update 2020-03-11
On 3/11/20 7:14 PM, Aleksandra Fedorova wrote: Hi, all. Here is the summary of CI-related work happening in Fedora. If you have questions or topics to discuss you can also join Fedora CI SIG bi-weekly meeting. Next session is today in #fedora-ci IRC channel at 15:30 UTC https://apps.fedoraproject.org/calendar/SIGs/#m9618 ### Dist-git tests support multipackage updates You can define package tests in dist-git via STR format https://docs.fedoraproject.org/en-US/ci/standard-test-roles/ Note that dist-git/STR tests are different from running %check tests in the rpm building phase. STR tests are executed in a clean virtual machine with proper setup of repositories for the latest Fedora Rawhide packages. This environment is better suited for integration tests, which need to test the installed package, not the sources of it. Dist-git tests are fully compatible with the dynamic sidetag approach: if you create a dynamic sidetag for the multi-package update, test environment will be created with the content of the entire sidetag, not an individual package. Status: Ready to Use Contact: Bruno Goncalves (bgoncalv) and #fedora-ci IRC channel. ### New test: rpminspect There is a new rpminspect test running in Fedora Rawhide gating enabled by default for all packages in a non-blocking mode. More details: https://github.com/rpminspect/rpminspect Status: Ready to Use Contact: David Cantrell (dcantrell) Thanks for sending out all this information, Aleksandra :) I also want to call out Tim Flink (irc: tflink) from Fedora QA team who worked extensively on getting rpminspect to run in a way that its results could show up in bodhi. ### Tests for pull-requests via Zuul Zuul team has enabled Zuul CI engine to test Pagure pull requests. You can opt-in to Zuul CI per package. On every pull-request Zuul will * run a scratch build * run rpminspect on that build * run dist-git test defined in STR format(if available) * provide comment in the pull-request * wait for you to put an manual approval on the PR * merge the PR * you can also get Zuul to handle merge events, so that it will automatically build the regular koji build, after the merge. Zuul now has support for EPEL8 branches. More details: https://fedoraproject.org/wiki/Zuul-based-ci Status: Ready to use Contact: Fabien Boucher (fbo) ### Koschei as a gating test With sidetag gating feature enabled it is now possible to run Koschei for each dynamic sidetag and make it a part of the gating process. We do have Koschei deployed on Fedora infrastructure. There is on-going work by Mikolaj Izdebski to get it integrated with the Fedora Messaging, so that sidetags are submitted in Koschei when created. Status: research and prototyping Contact: Serhii Turivnyi (sturivny) ### Infra change: new Jenkins master New Jenkins master to run generic tests and inherit Taskotron pipelines. Our current Jenkins master, which is used for dist-git tests, was not updated for some time and it is by design bundled to the pipeline it runs. So adding new pipelines and separating pipelines from the Jenkins master configuration is problematic. The goal here is to have a Jenkins master setup which is easy to update. It will have a set of plugins pre-installed and configured for Fedora infrastructure endpoints, but jobs configuration will be applied to it independently. More details: Current work is done on a Communishift project. Code will be available soon at https://github.com/fedora-ci Status: WIP Contact: Jim Bair (jbair) ### Infra change: common repository and common format for generic tests We are refactoring the Groovy pipeline library so it is better suited to run generic tests. One of the goals is that generic tests are all run in the same way, and you don’t need to add a lot of new Groovy code to add a certain bash script as a generic test. We’d like people to be able to contribute new generic tests without prior knowledge of the Jenkins internal setup. Current focus is rpmdeplint and rpminspect pipelines. More details: https://github.com/fedora-ci Status: WIP Contact: Michal Srb (msrb) ### Infra change: ODCS composes We are updating ODCS staging infrastructure to the latest ODCS release. Once the Fedora instractructure freeze is over, we will also update the ODCS production instance. This work is preparation for possible further use of ODCS to generate composes used by Fedora CI as well as main Fedora composes. Status: WIP Contact: Jan Kaluza (jkaluza) ### Infra change: Testing Farm Service Testing Farm Team is working on open-sourcing parts of the RH internal CI infrastructure as a service, which will be used by Fedora CI's general tests and functional tests pipeline. The main input of the service will be test definitions in the TMT/FMF format. TMT documentation: https://tmt.readthedocs.io/en/latest/ (recently added testcloud + podman provisioner) Code is hosted at GitLab:
Re: Proposal: Move to an annual platform release starting at F30
On 11/28/18 1:32 AM, Kevin Fenzi wrote: I agree with the folks in this subthread, but I think we are going to have to look at 'redesigning' things more than just 'optimizing'. +1. At the same time, we should also ensure that Devel,QE,Infra,RelEng.. all equal stake holders and are hand in glove with the new design and not fall into their own silo. ie, collect all our inputs and outputs and things we need to do in the process and figure out how to make it modular (no relation) so we can look at just a single changed input and quickly test and generate all the outputs that are affected by that input (and not any of the others). For example, a new xfce4-settings package comes out, we want to test it, test the Xfce live media and if it all passes, perhaps release that media. It may well be that we can figure out a 'base platform' just by looking at these imput/outputs: what things are in most or all outputs? kevin ___ 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: 'No More Alphas': wiki revision drafts
On 08/22/2017 07:34 PM, Matthew Miller wrote: On Tue, Aug 22, 2017 at 07:18:04PM +0530, Sudhir D wrote: On a slightly different thought, if we run all existing Alpha criteria tests in rawhide, we can then probably look at existing Alpha blocker as Branch blocker.. i.e, we don't branch unless the blockers are fixed and thereby keeping rawhide at Alpha quality all the time. We might want to call 'Basic Release Criteria' as 'Basic Branch Criteria'. H. I guess this would avoid needing to fix problems on both the branch and rawhide. But, sometimes the fix should be different (e.g. backport or quick fix on branch, update to new version or other long term solution on rawhide). Such fix must then be tracked separately for branched version. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: 'No More Alphas': wiki revision drafts
On 08/03/2017 05:46 AM, Adam Williamson wrote: * My proposal for 'what do we do about release criteria / validation' is basically: the 'Fedora 27 Alpha Release Criteria' page gets renamed 'Basic Release Criteria' (note: not versioned, I don't think it should be), and we document that *all* composes - not just Beta and Final candidate composes, but also Rawhide and Branched nightlies - will be automatically tested for (and release of them gated on) compliance with them. Which is more or less what's proposed in the Change. All external references to the 'Alpha' criteria get changed to 'Basic' (e.g. this is what changed on the other criteria pages, and on the test matrix template pages). Practically speaking, we currently have automated testing for *most* of the existing Alpha criteria, but a few items aren't covered. We can choose to move these to the Beta criteria, or leave them on Basic and just accept that *actual* coverage doesn't quite meet what we aspire to. I do *NOT* propose to have any kind of blocker tracking bug for the Basic release criteria; it doesn't seem to fit in the process, there is no Alpha release to block, and we can't realistically block nightly composes on manual test results. So a tracker bug wouldn't really have any reason to exist. In the case where a violation of the Basic criteria makes it into composes despite the automated testing, it should be marked as a Beta blocker. On a slightly different thought, if we run all existing Alpha criteria tests in rawhide, we can then probably look at existing Alpha blocker as Branch blocker.. i.e, we don't branch unless the blockers are fixed and thereby keeping rawhide at Alpha quality all the time. We might want to call 'Basic Release Criteria' as 'Basic Branch Criteria'. Regards, Sudhir ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: PROPOSAL: Blocking the release is our only "big hammer" — let's add a softer one.
- Original Message -
| From: "Adam Williamson" <adamw...@fedoraproject.org>
| To: "Development discussions related to Fedora"
<devel@lists.fedoraproject.org>
| Sent: Thursday, October 13, 2016 12:26:10 PM
| Subject: Re: PROPOSAL: Blocking the release is our only "big hammer" — let's
add a softer one.
|
| On Thu, 2016-10-13 at 14:40 +1000, Jeff Fearn wrote:
| > On 13/10/16 14:02, Adam Williamson wrote:
| > > On Wed, 2016-10-12 at 21:09 -0400, Josh Boyer wrote:
| > > > On Wed, Oct 12, 2016 at 8:33 PM, Adam Williamson
| > > > <adamw...@fedoraproject.org> wrote:
| > > > > On Wed, 2016-10-12 at 09:55 -0400, Josh Boyer wrote:
| > > > > > All of the extra app stuff could be avoided if we disallowed
| > > > > > reporters
| > > > > > (or random people) to change the Severity and Priority fields.
| > > > >
| > > > > Mmm, I don't really think so. Presumably it would be maintainers who
| > > > > got to set those fields, right? But they are doing so in relation to
| > > >
| > > > No, why would you presume that?
| > >
| > > I dunno, just seemed logical. That's how they're intended to be used at
| > > present. Bug reporters aren't supposed to set them and don't have the
| > > privilege purely by rights of having an account
| >
| > This is true for priority but not true for severity. Severity is the
| > external, i.e. reporters, weighting
| > of the bug and you do not need to be in editbugs to set it.
|
| That's not the intent of the fields as I understand them. 'severity' is
| supposed to represent how bad the bug is, whereas 'priority' is
| supposed to represent how important it is to get it fixed compared to
| other bugs in the same component. They're obviously related, but not
| the same, and it's not "severity is the reporter's opinion, priority is
| the maintainers' opinion", no.
|
| I think you might be right that we allow the bug reporter to set
| 'severity', though.
There is no direct relation between these fields.
Many projects interpret in different ways, but the most common way is,
'severity' is what user thinks of the issue, how much of an issue it is for him
('user' is a QE engineer/consumer or a developer of other component). This is
usually set to get the attention of the developer/owner of component over other
bugs in same component.
'priority' is what the developer/owner of the component (owner of the bug)
thinks its severity is. It can also be a consensus from all stake holders.
It is not uncommon to see high severity bugs getting triaged first. It is also
a good practice to keep priority and severity at comparable, if not same level
once triaged (i.e., it would not logically seem correct to see high severity
with low priority or vice-versa after triage).
Regards,
Sudhir
| --
| Adam Williamson
| Fedora QA Community Monkey
| IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
| http://www.happyassassin.net
| ___
| devel mailing list -- devel@lists.fedoraproject.org
| To unsubscribe send an email to devel-le...@lists.fedoraproject.org
|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Requiring package test instructions
On 07/13/2016 08:17 AM, Siddhesh Poyarekar wrote: But then we're setting the bar too low by allowing *anyone* to set karma for the sake of it. You might as well just let developers push packages to stable if they're 'confident' about it. That is painting with too broad of a brush for one or two instance. We have to be sensitive to contributions coming from new members. It is our duty to show them the right way and not scram them away. we need a way to put in control mechanisms (and maybe have a mentorship program) when we see a pattern of incorrect behaviour. Correct. There are many ways and having basic functionality testing details is one of them, which the proposal is about. Adam and others are doing their bit by having on-boarding calls etc.. to show the new joiners how to do Fedora testing the right way. Cheers, Sudhir -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Stop please
On Saturday 09 Jan 2016 12:36:08 PM Michael Catanzaro wrote: > I, Michael Catanzaro, have never in my entire life seen any email > client display mail headers. It's beyond unreasonable to suggest users > look there for anything, much less for a way to unsubscribe from a > mailing list. That's very hard to believe. You may have over looked it. There are at least 2 places if not more where source of an email is available in KMail. View>Source or right-click email>Source or via shortcut V. -- Regards, Sudhir Khanger, sudhirkhanger.com. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Flash plugin 0-day vulnerability in the wild
On Friday, January 23, 2015 08:44:03 AM Andrew Lutomirski wrote: $ sandbox -X xterm [nothing happens] It made me install selinux-policy-sandbox and seunshare. I am able to run Firefox under sandbox without any problem. I am running Fedora 21 KDE. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: DNF as default package manager
On Wed, Jan 21, 2015 at 5:43 PM, Jan Zelený jzel...@redhat.com wrote: Name them please. Or better yet, report them. Any plans for local repository support in DNF. https://bugzilla.redhat.com/show_bug.cgi?id=991014 -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. -- 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: IntelliJ
On Wednesday, January 21, 2015 12:39:56 AM Julien Enselme wrote: For android studio, the Oracle JDK is more a recommendation. I made some basic Android development today with Android studio running on the OpenJDK and Fedora 21 and I experienced no problems at all. Oracle JDK 7 is the specific requirement for Android Studio. The only caveat of using OpenJDK with IntelliJ is that upstream won't take bug reports. If people can live with that I think it is a great idea. Maybe if enough folks were using IntelliJ with OpenJDK, it might help change their stance on Oracle JDK requirement. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: IntelliJ
On Wednesday, January 21, 2015 05:02:32 AM Reindl Harald wrote: since with Java7 OpenJDK is the *official reference implementation* it is somehow pervert having such recommendations at all We in any case don't support OpenJDK 7 which makes Fedora 21 and onward a second class citizen for Android development. OpenJDK 7 vs Oracle JDK 7 is a moot point. IntelliJ 14 fully supports JDK 8 and next preview version of Android Studio will be based off IntelliJ 14. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: F21 downloads repository metadata in 3 places!
On Thu, Dec 18, 2014 at 9:04 AM, Kevin Kofler kevin.kof...@chello.at wrote: KDE has the setting in Apper under [Tools icon⌄] Preferences in the first (selected by default) tab (General Settings). It's called Check for updates:, and it's a dropdown list with the options Hourly, Daily, Weekly, Monthly or Never. IMHO, that's clearly the right place and UI for this setting. That doesn't differentiate between metered and un-metered connections. Most people would tether their laptops with their phones via portable hotspot which is treated as a regular wifi connection. Currently, the only good option is to disable dnf and PackageKit. Most folks would not know what's eating their mobile data. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. -- 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: F21 downloads repository metadata in 3 places!
On Sunday, December 14, 2014 12:09:14 PM Hedayat Vatankhah wrote: I'd call it evil. Apparently, nobody around here cares. I think I should start thinking about my own Fedora for Poor product. It certainly affects me. Most decision are being made on two assumptions 1. people have fast and unlimited internet connections and 2. people have high RAM and multiple core CPU powerful computers. Both of these assumptions are arbitrarily at best. DNF regularly downloads cache, disables delta RPM support, and doesn't support local repos. Instead of implementing different profiles for different type of networks like wifi vs mobile we are throwing it out without people's consent. I am in favor of automation but it should be implemented when it's ready. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: Firefox webrtc support in F21?
On Friday, December 12, 2014 03:05:42 PM Joachim Backes wrote: anybody knows if the webrtc support in firefox will be released in F21? I am under the impression WebRTC already works on Firefox. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: fedup FC20 - FC21 update conflicts
On Wednesday, December 10, 2014 04:36:09 PM Przemek Klosowski wrote: icedtea-web-1.5.2-0.fc20.x86_64 requires java-1.7.0-openjdk-1:1.7.0.71-2.5.3.0.fc20.x86_64 OpenJDK 7 has been dropped from F21. You would get prompt answer from fedora- java mailing list. $ rpm -qa | grep icedtea icedtea-web-1.5.1-1.fc21.x86_64 $ rpm -qa | grep openjdk java-1.8.0-openjdk-headless-1.8.0.25-4.b18.fc21.x86_64 java-1.8.0-openjdk-devel-1.8.0.25-4.b18.fc21.x86_64 java-1.8.0-openjdk-1.8.0.25-4.b18.fc21.x86_64 -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: Poll: How users use DNF
On Tuesday, December 09, 2014 12:28:54 PM Radek Holy wrote: I would be very grateful if you could send me a brief description of how you use YUM or DNF currently or how would you like to use it. DNF doesn't work with local repositories created via createrepo or yum-plugin- local. It is one of the reasons I can't use DNF at all. I would hope that DNF would support local repositories before Fedora adopts it as an official package management tool. Here is the bug report[1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=991014 -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: Workstation Product defaults to wide-open firewall
On Mon, Dec 8, 2014 at 11:03 PM, DJ Delorie d...@redhat.com wrote: I, for one, am happy to welcome our new more-reasonable-less-paranoid overlords. I've been disabling my firewall for ages, as my machines are behind an enterprise firewall anyway. So the target audience has shifted from developers to developers who don't understand ports, don't like user prompts and are behind enterprise firewalls. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. -- 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: Join to Mozilla Location Service in Fedora
On Monday, November 10, 2014 11:45:29 AM Florian Weimer wrote: Unfortunately, this does not say that it turns off reporting of encountered SSIDs, (router) MAC address, and Cell ID information. I think if you opt not to use this data to determine your own location, it is still reported to Google to improve accuracy for those who use Google's location services. In the location mode you could tell it to use a combination of one of the following 1. GPS, Wi-Fi and mobile networks 2. Wi-Fi and mobile networks and 3. only mobile networks. I will have to look into how and what exactly it sends to Google in case you choose to report location data. Cell phone users get tracked no matter what. The only consolation is that you don't know about it. -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: Join to Mozilla Location Service in Fedora
On Thursday, November 06, 2014 08:10:19 PM Jiri Eischmann wrote: It's usually opt-in, so you don't have to use it and don't use it by default. This is at least designed as anonymous while Google tracks all Android users and saves their personal location data by default. I don't mind sharing data as long as the data is shared back in some interesting form. I think it's a misconception that Google saves personal location data by default. When you setup your device for the first time it will ask you to enable location reporting. You can disable location reporting and delete location history on your Android devices using this link [1]. You will also lose access to all the value that location aware apps provide. [1] https://support.google.com/gmm/answer/3118687?hl=en -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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: Join to Mozilla Location Service in Fedora
On Thursday, November 06, 2014 01:16:20 PM Martin Stransky wrote: I'd like to ask you to join the project, install the Mozilla Stumbler application [3] and help to improve the location accuracy. How do I benefit from broadcasting my location? -- Regards, Sudhir Khanger, sudhirkhanger.com, github.com/donniezazen, 5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394. 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
