Send bug-gnuzilla mailing list submissions to
address@hidden
[cut for brevity]
Today's Topics:
1. Re: Up-to-date IceCat source tarballs now available via GNU
Guix (address@hidden)
2. Re: Up-to-date IceCat source tarballs now available via GNU
Guix (bill-auger)
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 Jul 2019 09:26:34 +0200
From: "address@hidden" <address@hidden>
To: address@hidden
Subject: Re: [Bug-gnuzilla] Up-to-date IceCat source tarballs now
available via GNU Guix
Message-ID: <address@hidden>
Content-Type: text/plain; charset=utf-8
Hello everyone,
[cut for brevity]
------------------------------
Message: 2
Date: Tue, 9 Jul 2019 07:20:41 -0400
From: bill-auger <bill-auger@peers.community>
To: address@hidden
Subject: Re: [Bug-gnuzilla] Up-to-date IceCat source tarballs now
available via GNU Guix
Message-ID: <20190709072041.2c2f61bf@parabola>
Content-Type: text/plain; charset=US-ASCII
that specific concern is only one symptom of the current
situation - at the root of it, is the fact that there is often a
significant amount of work involved to prepare each new release
of these browsers; and the gnuzilla project is currently
under-staffed, and asking for contributors - that has been
discussed recently on this list[1]
some of us have been proposing that the ideal solution is for
the downstreams that package and distribute icecat, and other
FSDG-compliant mozilla-derived browsers, should collaborate more
closely with the gnuzilla project, so that the combined efforts
could go toward getting official upstream versions out sooner as
well as downstream distro packages; rather than repeating the
same work on each fork ahead of the upstream, and then
advertising each downstream release on this list, while the
upstream is still lagging behind
generally speaking, anytime a downstream moves ahead of its
upstream, without offering back upstream, patches that the
upstream would gladly accept for the benefit of all other
downstreams, or when an upstream refuses valuable contributions
that would benefit it's downstreams, that probably indicates a
serious problem somewhere in the ecosystem; one that affects
everyone interested in that project - a bit of conversation,
coordinate, and collaboration among downstreams and the upstream,
could not only solve that problem, but improve the whole
ecosystem surrounding the project
the link below is an example just recently, when someone started
a thread, advertising compiled binaries that were a version
ahead of gnuzilla, also explaining the steps that were taken to
upgrade, and offering to help gnuzilla to move forward - in that
case, the necessary changes were minimal; and that person was
asked to join the team - then three days later, a new version of
icecat was released - that proved to be a fruitful interaction -
gnuzilla just needs more interaction of that sort, from people
who are willing to share their packaging experiences and
opinions with the upstream
[1]: https://lists.gnu.org/archive/html/bug-gnuzilla/2019-05/msg00025.html