-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
We have a rather sizable backlog of issues around the PureBrowser: https://tracker.pureos.net/project/board/1/
I point this out not as a criticism of Jonas, the PureBrowser maintainer, but to highlight that we do not have a clear, distilled policy document that might mitigate some of the issues in the backlog.
One example is this issue: https://tracker.pureos.net/T699 That issue comes from a video of PureOS which makes some inaccurate claims. The video was linked in our bug tracker and I went through the video and pulled out the claims so that they can be refuted, T699 tracks one such claim of not having httpseverywhere enabled per default.
Having a policy for an issue like this would allow someone to quickly go to our policy, quote it in the issue tracker and/or demonstrate that in fact we do have httpseverywhere installed, and then close the bug which I feel is a positive outcome. As it stands now, we have a lot of issues that seem to attract a lot of commentary but little change is effecutated. For me the point of an issue tracker is to track the progress of the issue to the point where it is no longer an issue and it is closed. Is this a shared view from folks on this list?
Regards,
jeremiah
Hi Jeremiah,
Quoting Jeremiah C. Foster (2019-02-15 18:23:16)
I point this out not as a criticism of Jonas, the PureBrowser maintainer, but to highlight that we do not have a clear, distilled policy document that might mitigate some of the issues in the backlog.
One example is this issue: https://tracker.pureos.net/T699 That issue comes from a video of PureOS which makes some inaccurate claims. The video was linked in our bug tracker and I went through the video and pulled out the claims so that they can be refuted, T699 tracks one such claim of not having httpseverywhere enabled per default.
Seems you talk about https://tracker.pureos.net/T519 - and that you today filed a duplicate of https://tracker.pureos.net/T273
Having a policy for an issue like this would allow someone to quickly go to our policy, quote it in the issue tracker and/or demonstrate that in fact we do have httpseverywhere installed, and then close the bug which I feel is a positive outcome. As it stands now, we have a lot of issues that seem to attract a lot of commentary but little change is effecutated.
I am not convinced that a policy helps triage issues, but perhaps I am simply not imaginative enough and it could help if you elaborate on what you think such policy might contain?
For me the point of an issue tracker is to track the progress of the issue to the point where it is no longer an issue and it is closed. Is this a shared view from folks on this list?
As pointed out above I don't share your view for the whole paragraph - but if you refer only to the previous sentence then I agree (and wonder which other views are reasonable).
Thanks for initiating this discussion,
- Jonas
On Fri, 2019-02-15 at 22:36 +0100, Jonas Smedegaard wrote:
Hi Jeremiah,
Quoting Jeremiah C. Foster (2019-02-15 18:23:16)
Having a policy for an issue like this would allow someone to quickly go to our policy, quote it in the issue tracker and/or demonstrate that in fact we do have httpseverywhere installed, and then close the bug which I feel is a positive outcome. As it stands now, we have a lot of issues that seem to attract a lot of commentary but little change is effecutated.
I am not convinced that a policy helps triage issues, but perhaps I am simply not imaginative enough and it could help if you elaborate on what you think such policy might contain?
For me "policy" is just what we do, i.e. what is our PureBrowser policy? Well, we patch it and remove some branding. Obviously that is a truncated answer, but if we had a policy document that outlined what we actually do, then we can refer to that when there are issues or questions.
Such a policy might contain;
"- We remove all hidden system add-ons, including "Activity Stream" which cause our version of Firefox to render a blank start page currently.
- We not only change default search engine, but also disable geospecific search engine resolution, disable telemetry, disable crash reporting, and disable and lock Encrypted Media Extensions (EME).
- We do not install any add-ons into Firefox. But we force our users to additionally install a few independent add-ons when they use the default settings of our package manager to install Firefox.
Our changes (in addition to Debian which apply 30 concrete patches to upstream sourcecode and involve customizing build routines involving roughly 70 files) are documented at https://source.puri.sm/pureos/packages/firefox-esr and specific changes for each of our package releases are summarized in our changelog, e.g. https://source.puri.sm/pureos/packages/firefox-esr/blob/pureos/60.5.0esr-1pu..."
This above quote comes from another email but is an excellent policy document in my mind. So good that I thought I would document it for posterity in our mailing list.
In fact, the third point above might explain https://tracker.pureos.net/T712?
Cheers,
Jeremiah
Quoting Jeremiah C. Foster (2019-03-08 18:53:52)
On Fri, 2019-02-15 at 22:36 +0100, Jonas Smedegaard wrote:
Hi Jeremiah,
Quoting Jeremiah C. Foster (2019-02-15 18:23:16)
Having a policy for an issue like this would allow someone to quickly go to our policy, quote it in the issue tracker and/or demonstrate that in fact we do have httpseverywhere installed, and then close the bug which I feel is a positive outcome. As it stands now, we have a lot of issues that seem to attract a lot of commentary but little change is effecutated.
I am not convinced that a policy helps triage issues, but perhaps I am simply not imaginative enough and it could help if you elaborate on what you think such policy might contain?
For me "policy" is just what we do, i.e. what is our PureBrowser policy? Well, we patch it and remove some branding. Obviously that is a truncated answer, but if we had a policy document that outlined what we actually do, then we can refer to that when there are issues or questions.
Such a policy might contain;
"- We remove all hidden system add-ons, including "Activity Stream" which cause our version of Firefox to render a blank start page currently.
- We not only change default search engine, but also disable
geospecific search engine resolution, disable telemetry, disable crash reporting, and disable and lock Encrypted Media Extensions (EME).
- We do not install any add-ons into Firefox. But we force our users
to additionally install a few independent add-ons when they use the default settings of our package manager to install Firefox.
Our changes (in addition to Debian which apply 30 concrete patches to upstream sourcecode and involve customizing build routines involving roughly 70 files) are documented at https://source.puri.sm/pureos/packages/firefox-esr and specific changes for each of our package releases are summarized in our changelog, e.g. https://source.puri.sm/pureos/packages/firefox-esr/blob/pureos/60.5.0esr-1pu..."
This above quote comes from another email but is an excellent policy document in my mind. So good that I thought I would document it for posterity in our mailing list.
What you quote is me re-telling targeted Mozilla lawyers a set of changelog entries for latest release of our package.
Thanks for clarifying that such a text is what you consider a policy, and that you believe such a text can help us process issues faster.
I fail at seeing that myself, though. But happy if it helps others!
In fact, the third point above might explain https://tracker.pureos.net/T712?
How so?
- Jonas
-
Jeremiah C. Foster -
Jonas Smedegaard