bug-gnuzilla
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnuzilla] concerning voting & further directions


From: Mart Rootamm
Subject: Re: [Bug-gnuzilla] concerning voting & further directions
Date: Tue, 15 Nov 2016 03:55:46 +0200

Concur on most points.

I support informed consensus, insofar as it would succeed in restoring some previously built-in privacy features.

Simple voting as it's happening here and at Savannah, is not necessarily democracy, because without any proper discussion, it's often uninformed, and becomes simply a vote by majority, especially when a bad decision gets made.

There are also people, who do use IceCat, but who don't vote, and who don't partake in discussions in this list and elsewhere. The same applies to users of upstream, but on a scale greater by orders of magnitude. When something wrong happens to upstream, it's impossible to turn it back, and users discover fairly late when useful functionality has been removed or when bloat has been added.

There are things that should be in addons, and then there are things that should not be. For example, cookie prompt code should be returned, stay built-in, and be developed further. This would resolve an upstream regression and increase the user base. If done right, more distros would then pick IceCat as the defaut browser.

Whilst NoScript is an independently-developed add-on used by other Gecko-based projects and should therefore stay as is.

wrt future IceCat, then instead of any one adblocker, NoScript should be bundled, as it has a compatible license, it offers better security, and most ads are blocked along the way, too. Some distros do that bundling already. Choosing an adblocker is then up to each user and their preference.

-M.


2016-11-14 21:46 GMT+02:00 Ivan Zaigralin <address@hidden>:
This is just brain-storming, meant for comment only.

I am not convinced voting over a bunch of small initiatives would be very
effective, at any rate, I will abstain for now.

I think before voting we need to have a consensus on the general direction as
we are moving forward, which is not something we can solve with just applying
the democracy. We've got some technical problems looming for a while now, and
they need some love and care from the few people doing the actual work.

The terrible lag behind the upstream releases was recognized as an issue for a
while now, and it feels to me that part of the problem is that modifications
applied to the upstream are too invasive. May be we can separate this project
into 2 distinct subprojects:

(1)

This one applies the minimal possible changes to the upstream in order to make
it FSDG-compliant. I haven't looked very carefully, but if it's anything like
building FSDG-compliant thunderbird, then may be the following would be
enough:

(1.1) disable add-on page or replace it with a good page
(1.2) build without official branding
(1.3) add icecat branding, or leave it for (2)

(2)

Here we build the icecat proper, with all the extra privacy features. icecat
branding can also be added at this stage, if it wasn't added earlier. I have
nothing against putting the features inside addons, but I must insist the way
it's being done right now is suboptimal. All these feature-imparting addons
must be made in-house, have their own distinct namespaces, and should not
replicate functionality provided by upstream addons. In particular, icecat
signature addons should not prevent the user from installing and using any of
the general-purpose ad-blockers, https enforcers, etc. If we close our eyes on
its philosophical issues and bugs, LibreJS is how we do it right. spyblock, on
the other hand, needs to go. The users should be able to choose whatever free
ad blocker they want.

This two-pronged approach would insure that users and distributions are
getting the security updates in a timely manner. And may be we can find a way
for the additional features to be packaged separately, and updated
independently?

--
http://gnuzilla.gnu.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]