[Bug-gnuzilla] concerning voting & further directions

[Ivan Zaigralin]

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?

signature.asc
Description: This is a digitally signed message part.