[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnuzilla] concerning voting & further directions
From: |
Ivan Zaigralin |
Subject: |
[Bug-gnuzilla] concerning voting & further directions |
Date: |
Mon, 14 Nov 2016 11:46:32 -0800 |
User-agent: |
KMail/4.14.10 (Linux/4.4.29-gnu; KDE/4.14.21; x86_64; ; ) |
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.
- [Bug-gnuzilla] concerning voting & further directions,
Ivan Zaigralin <=