Request for assistance maintaining LibreWolf

Request for assistance maintaining LibreWolf

[Ian Eure]

Hi folks,

Last year, I spent several months getting the LibreWolf web 
browser packaged, reviewed, and contributed to Guix.  I’m happy to 
have done so, and glad that it’s proved useful to others.  One of 
the concerns raised as I was going through that process was 
responsibility for ongoing maintenance.  I offered to take that 
on, and have followed through, continuing to contribute patches 
which improve the package and update it as new upstream releases 
occur -- which is very frequently.  Unfortunately, much of this 
work is wasted, as the patches remain mired in the review backlog. 
The package is now three major version out of date and suffers 
from numerous CVEs.  The initial patch to update the version to 
127.x was submitted on June 29th; updated to 128.x on July 17th; 
and I’ll be sending the patch updating it to 129.x later today, 
after I’ve finished building and testing it.

I’m stuck in an impossible situation.  I can’t apply for committer 
access until I have more accepted contributions, but can’t build 
those contributions unless my patches are reviewed.  It’s 
frustrating and demoralizing.

Are there, perhaps, one or two committers who’d be willing to work 
more closely with me on LibreWolf on an ongoing basis?  I’m not 
asking for help doing the work of maintaining the browser itself, 
which I remain committed to doing.  I’m purely looking to 
consitently get timely feedback and review, because the normal 
process for contributions cannot reliably provide it.

A second, and smaller question, is: is there a mechanism to direct 
others’ contributions to LibreWolf to me for review, without 
subscribing to every patch sent to Guix?  I have seen some 
patches, and participated, but I have to go look for those, and 
it’d be more convenient if they were directed to me in the first 
place.

Thanks,

  — Ian

Re: Request for assistance maintaining LibreWolf

[Sergio Pastor Pérez]

Hello Ian.

I cannot help you since I don't have commit access. But I want to thank
you for your hard work, I'm currently using your package.

I can only echo your frustration since I also have some patches ready to
be merged that seem to be forgotten. As it has been discussed in the
past, Guix is growing, but there are not enough hands to merge all the
contributions that come through.

We should try to come up with a solution that alleviates the burden on
the maintainers. Given how often this issue arises, what if we try, as
a collective, to suggest new mechanisms that would improve the
situation?

If I recall correctly, someone suggested having a development branch in
which, once the QA passes, the patches get automatically merged. I know
some people rose concerns about the slowness of the QA system for this
to be an effective solution, and there is also the issue ordering the
patch application.

If the previous solution is ruled out, I would like to know the opinion
of the Guix community on a voting system. I'm imagining a system where
we reuse the mailing infrastructure we have, where each accepted mail in
the guix devel mailing list has 1 vote for a given patch, that way we
avoid multiple votes from the same entity and would allow people without
commit access, but active on the Guix development, to participate. So,
we could set up a threshold where if a patch gets 10 votes from
non-committers the merge would be done; preferably automated, but if it's
not possible, committers would know what is ready to be merged without
effort and what the community wants.

Regards,
Sergio.

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

Hi Sergio,

Sergio Pastor Pérez <sergio.pastorperez@outlook.es> writes:

> Hello Ian.
>
> I cannot help you since I don't have commit access. But I want 
> to thank
> you for your hard work, I'm currently using your package.
>

Thank you for the kind words, they truly mean a lot to me.

Whatever the state of Guix proper, you can always find the current 
version of LibreWolf in my personal channel[1], though I don’t 
have a public substitute server, so long build times will await 
you if you choose this route.


> We should try to come up with a solution that alleviates the 
> burden on
> the maintainers. Given how often this issue arises, what if we 
> try, as
> a collective, to suggest new mechanisms that would improve the
> situation?
>
> If I recall correctly, someone suggested having a development 
> branch in
> which, once the QA passes, the patches get automatically 
> merged. I know
> some people rose concerns about the slowness of the QA system 
> for this
> to be an effective solution, and there is also the issue 
> ordering the
> patch application.
>
> If the previous solution is ruled out, I would like to know the 
> opinion
> of the Guix community on a voting system. I'm imagining a system 
> where
> we reuse the mailing infrastructure we have, where each accepted 
> mail in
> the guix devel mailing list has 1 vote for a given patch, that 
> way we
> avoid multiple votes from the same entity and would allow people 
> without
> commit access, but active on the Guix development, to 
> participate. So,
> we could set up a threshold where if a patch gets 10 votes from
> non-committers the merge would be done; preferably automated, 
> but if it's
> not possible, committers would know what is ready to be merged 
> without
> effort and what the community wants.
>

I’m not sure this would be effective, because the QA service is 
unreliable.  I regularly see patches which simply don’t get picked 
up by it, including many of my own.  At other times, it lags very 
far behind.  I don’t think it’s reliable enough to be in the 
critical path for anything.  Guix is supposed to be a 
rolling-release distro, so it feels strange to have a develop 
branch which moves even faster.

Thanks,

  — Ian


[1]: https://codeberg.org/ieure/atomized-guix

Re: Request for assistance maintaining LibreWolf

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]

Sergio Pastor Pérez <sergio.pastorperez@outlook.es> writes:

> I cannot help you since I don't have commit access. But I want to thank
> you for your hard work, I'm currently using your package.
>
> I can only echo your frustration since I also have some patches ready to
> be merged that seem to be forgotten. As it has been discussed in the
> past, Guix is growing, but there are not enough hands to merge all the
> contributions that come through.
>
> We should try to come up with a solution that alleviates the burden on
> the maintainers. Given how often this issue arises, what if we try, as
> a collective, to suggest new mechanisms that would improve the
> situation?
>
> If I recall correctly, someone suggested having a development branch in
> which, once the QA passes, the patches get automatically merged. I know
> some people rose concerns about the slowness of the QA system for this
> to be an effective solution, and there is also the issue ordering the
> patch application.
>
> If the previous solution is ruled out, I would like to know the opinion
> of the Guix community on a voting system. I'm imagining a system where
> we reuse the mailing infrastructure we have, where each accepted mail in
> the guix devel mailing list has 1 vote for a given patch, that way we
> avoid multiple votes from the same entity and would allow people without
> commit access, but active on the Guix development, to participate. So,
> we could set up a threshold where if a patch gets 10 votes from
> non-committers the merge would be done; preferably automated, but if it's
> not possible, committers would know what is ready to be merged without
> effort and what the community wants.

We've had for many months a feature in QA [1] where people can mark
patches as being reviewed and looking like they're ready to be merged,
which is personally what I hope will mitigate this feeling of "I cannot
help you since I don't have commit access", because you can help, you
can review the patches and if you think they're ready to merge, you can
record that, and this does help highlight patches that are ready to
merge.

1: https://lists.gnu.org/archive/html/guix-devel/2024-02/msg00132.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

Hi Christopher,

Christopher Baines <mail@cbaines.net> writes:

> [[PGP Signed Part:Undecided]]
> Sergio Pastor Pérez <sergio.pastorperez@outlook.es> writes:
>
>> I cannot help you since I don't have commit access. But I want 
>> to thank
>> you for your hard work, I'm currently using your package.
>>
>> I can only echo your frustration since I also have some patches 
>> ready to
>> be merged that seem to be forgotten. As it has been discussed 
>> in the
>> past, Guix is growing, but there are not enough hands to merge 
>> all the
>> contributions that come through.
>>
>> We should try to come up with a solution that alleviates the 
>> burden on
>> the maintainers. Given how often this issue arises, what if we 
>> try, as
>> a collective, to suggest new mechanisms that would improve the
>> situation?
>>
>> If I recall correctly, someone suggested having a development 
>> branch in
>> which, once the QA passes, the patches get automatically 
>> merged. I know
>> some people rose concerns about the slowness of the QA system 
>> for this
>> to be an effective solution, and there is also the issue 
>> ordering the
>> patch application.
>>
>> If the previous solution is ruled out, I would like to know the 
>> opinion
>> of the Guix community on a voting system. I'm imagining a 
>> system where
>> we reuse the mailing infrastructure we have, where each 
>> accepted mail in
>> the guix devel mailing list has 1 vote for a given patch, that 
>> way we
>> avoid multiple votes from the same entity and would allow 
>> people without
>> commit access, but active on the Guix development, to 
>> participate. So,
>> we could set up a threshold where if a patch gets 10 votes from
>> non-committers the merge would be done; preferably automated, 
>> but if it's
>> not possible, committers would know what is ready to be merged 
>> without
>> effort and what the community wants.
>
> We've had for many months a feature in QA [1] where people can 
> mark
> patches as being reviewed and looking like they're ready to be 
> merged,
> which is personally what I hope will mitigate this feeling of "I 
> cannot
> help you since I don't have commit access", because you can 
> help, you
> can review the patches and if you think they're ready to merge, 
> you can
> record that, and this does help highlight patches that are ready 
> to
> merge.
>

Yes, I’ve used it before.  Unfortunately, it doesn’t appear to be 
making a material difference, as the size of the backlog continues 
to grow[1].  Progress on this problem would result in the backlog 
decreasing.  It doesn’t matter how many reviewers say it looks 
good -- a committer is required to actually push the changes.

The macro problem of the review process being broken has existed 
for years and there doesn’t seem to be concensus on the cause, 
much less a solution.  Waiting for that fix is unreasonable, but 
if a committer was willing to collaborate with me, the worst 
effects could be mitigated.  This is similar to how the Linux 
kernel works -- the "trusted deputy" approach.  It’d also provide 
a path for contributers to grow into committers.  Guix seems 
committed to using an email-based workflow, so I think it makes a 
lot of sense to look at how Linux does it.  It’s the most 
successful project in the world to use email-based development.

Thanks,

  — Ian

[1]: https://debbugs.gnu.org/rrd/guix-patches.html

Re: Request for assistance maintaining LibreWolf

[Suhail Singh]

Ian Eure <ian@retrospec.tv> writes:

> Guix seems committed to using an email-based workflow, so I think it
> makes a lot of sense to look at how Linux does it.  It’s the most
> successful project in the world to use email-based development.

I believe, perhaps, the biggest issue with Guix is a diffusion of
responsiblity.  It's not clear who is responsible for what action.

Who is responsible, for instance, for the next version of Guix?  And if
it's not the tagged releases that are driving development, is there
common awareness in the community as to what is?  What, for instance, is
the target merge windows for some of the -team branches?

Given a patch, is it always clear who the applicable "subsystem
maintainer" is?  In some cases it's clear that there is a corresponding
"team", but at times there's more than one person and at other times
there's no corresponding team.

I believe there are a few lessons to be learned from here:
<https://www.kernel.org/doc/html/latest/process/2.Process.html#>

-- 
Suhail

Re: Request for assistance maintaining LibreWolf

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

Ian Eure <ian@retrospec.tv> writes:

>> We've had for many months a feature in QA [1] where people can mark
>> patches as being reviewed and looking like they're ready to be
>> merged,
>> which is personally what I hope will mitigate this feeling of "I
>> cannot
>> help you since I don't have commit access", because you can help,
>> you
>> can review the patches and if you think they're ready to merge, you
>> can
>> record that, and this does help highlight patches that are ready to
>> merge.
>>
>
> Yes, I’ve used it before.  Unfortunately, it doesn’t appear to be
> making a material difference, as the size of the backlog continues to
> grow[1].  Progress on this problem would result in the backlog
> decreasing.  It doesn’t matter how many reviewers say it looks good --
> a committer is required to actually push the changes.

I think it's unfair to say it's not making a difference, I really rely
on it at least. I also think measuring the backlog and using that as the
success metric is unwise, what we really want is an increase in
throughput.

I think it does matter if people take the time to review patches, as
that is what takes the time and provides the value.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

Christopher Baines <mail@cbaines.net> writes:

> [[PGP Signed Part:Undecided]]
> Ian Eure <ian@retrospec.tv> writes:
>
>>> We've had for many months a feature in QA [1] where people can 
>>> mark
>>> patches as being reviewed and looking like they're ready to be
>>> merged,
>>> which is personally what I hope will mitigate this feeling of 
>>> "I
>>> cannot
>>> help you since I don't have commit access", because you can 
>>> help,
>>> you
>>> can review the patches and if you think they're ready to 
>>> merge, you
>>> can
>>> record that, and this does help highlight patches that are 
>>> ready to
>>> merge.
>>>
>>
>> Yes, I’ve used it before.  Unfortunately, it doesn’t appear to 
>> be
>> making a material difference, as the size of the backlog 
>> continues to
>> grow[1].  Progress on this problem would result in the backlog
>> decreasing.  It doesn’t matter how many reviewers say it looks 
>> good --
>> a committer is required to actually push the changes.
>
> I think it's unfair to say it's not making a difference, I 
> really rely
> on it at least. I also think measuring the backlog and using 
> that as the
> success metric is unwise, what we really want is an increase in
> throughput.
>

Throughput of patch review is useless without considering the rate 
of new issues opened.  It doesn’t matter how much review 
throughput increases if the new issue rate increases faster.  What 
the graphs show is that the backlog has a trend of years-long 
growth -- that only happens when the open rate exceeds the close 
rate.  The problem will continue to grow as long as that remains 
the case.

Thanks,

  — Ian

Re: Request for assistance maintaining LibreWolf

[Maxim Cournoyer]

Hi Ian,

Sorry I was out of action for nearly 2 months.  I'm back, and while time
is still limited, if something stalls, let me know, I can try to help.

-- 
Thanks,
Maxim

Re: Request for assistance maintaining LibreWolf

[Sergio Pastor Pérez]

Hello Christopher.

Christopher Baines <mail@cbaines.net> writes:
> We've had for many months a feature in QA [1] where people can 
> mark
> patches as being reviewed and looking like they're ready to be 
> merged,
> which is personally what I hope will mitigate this feeling of "I 
> cannot
> help you since I don't have commit access", because you can 
> help, you
> can review the patches and if you think they're ready to merge, 
> you can
> record that, and this does help highlight patches that are ready 
> to
> merge.

I know about that feature, what I was describing was an interface where
you could see a vote count. And, in the same way we have a "Forgotten
issues" section in the tracker[1], we could have a "High request"
issues. As far as I know, right know the most similar thing we have is
that someone can mark a bug as priority, but this only show the opinion
of 1 person.

I believe the community would benefit from easy ways of participation,
such as a voting system, one that would show that the interests of the
community are represented, get attention and are prioritized.

[1] https://issues.guix.gnu.org/forgotten

Re: Request for assistance maintaining LibreWolf

[Attila Lendvai]

> We should try to come up with a solution that alleviates the burden on
> the maintainers. Given how often this issue arises, what if we try, as
> a collective, to suggest new mechanisms that would improve the
> situation?


IMO one thing that would help is to somehow losen the current very tight coupling (the guix monorepo).

a high level of centralization always translates to a bottleneck, and guix has reached a point where its centralized structure is seriously hindering it and frustrating away contributors.

i.e. it's much less risk to delegate the management of a hypothethical python channel to someone trusted than to give commit access to every contributor who wants to help maintaining the python related packages.

so, i think a lot of packages should be in channels. probably everything that is not essential for a minimally functional system that can bootstrap itself. part of python could be in the main guix repo, but whatever is not tightly needed could go into a channel with its own access control management.

some channels would have loser standards (god forbid some wouldn't frustrate the contributors with the ChangeLog format in the commit messages), and the users could decide whom they trust with what. and the guix maintainers could decide which channels to list on the official web page, with what comments/warnings.

but this is easier said than done, because formally expressing the dependencies between these channels is not a trivial task (think of e.g. keeping `guix time-machine` working in an environment where a patch in the official guix repo can break a package in some random channel, which is then fixed there in a new commit, etc). and even if doable, it would probably introduce extra code complexity.

but i'm sure there were countless discussions about the pros and cons of the monorepo, and i wish such a topic was captured in a wiki where the main arguments, obstacles, and ideas were collected for people like me who are late to the party.

but then guix doesn't really have an official wiki either. (and no, an afterthought in the libreplanet wiki doesn't count. and if you have an urge to argue, then just look at its current contents...) so we're pretty much stuck with the flat mailing list archive and IRC logs.

hrm, a tangential: maybe digesting the guix mailing list and IRC archive will be my first actual use-case for an LLM... modern problems require modern solutions.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Millions of people never analyze themselves. Mentally they are mechanical products of the factory of their environment, preoccupied with breakfast, lunch, and dinner, working and sleeping, and going here and there to be entertained. They don't know what or why they are seeking, nor why they never realize complete happiness and lasting satisfaction. By evading self-analysis, people go on being robots, conditioned by their environment. True self-analysis is the greatest art of progress.”
	— Paramahansa Yogananda (1893–1952)

Re: Request for assistance maintaining LibreWolf

[Lars-Dominik Braun]

Hi,

> so, i think a lot of packages should be in channels. probably everything that is not essential for a minimally functional system that can bootstrap itself. part of python could be in the main guix repo, but whatever is not tightly needed could go into a channel with its own access control management.

I have the same feeling. As I wrote on IRC a while ago[1]: “Perhaps
the Docker faction is right and traditional distributions are dead,
because they simply cannot (with reasonable effort) provide a coherent
set of packages any more. Maybe we have to embrace that approach and
reduce Guix to a minimal set of packages needed to build Guix itself
and then build (possibly incompatible) channels on top of that.”

For alot of the more complex packages we’ll probably have to go as far
as having a separate channel for each of them. And thus a prerequisite
for this setup to work is that this hypothetical “Guix Zero” will
have excellent support for dozens of channels with even more modules
inside of them[2].

Lars

[1] https://logs.guix.gnu.org/guix-hpc/2024-05-03.log#102354
[2] I believe Guile is still the limiting factor here, since there’s
    a maximum number of modules that can be loaded.

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

The latest patch series has been sent (bug #71832).  It fixes 14 
CVEs, in addition to the 16 fixed in v5.  I’ve backed out various 
improvements and bugfixes I wanted to include, and this does 
nothing other than the bare minimum to update the package.

If anyone would like to step up and review the changes, I’d 
greatly appreciate it.

Thanks,

  — Ian

Re: Request for assistance maintaining LibreWolf

[Suhail Singh]

Ian Eure <ian@retrospec.tv> writes:

> The initial patch to update the version to 127.x was submitted on June
> 29th; updated to 128.x on July 17th; and I’ll be sending the patch
> updating it to 129.x later today, after I’ve finished building and
> testing it.

Thank you for your continued commitment to this despite the lack of
timely review.

> I’m stuck in an impossible situation.  I can’t apply for committer access until
> I have more accepted contributions, but can’t build those contributions unless
> my patches are reviewed.  It’s frustrating and demoralizing.

I can empathize.  I decided to take a step back from posting
contributions earlier this year for similar reasons.  I am hopeful this
can improve in the (near) future.

> A second, and smaller question, is: is there a mechanism to direct others’
> contributions to LibreWolf to me for review, without subscribing to every patch
> sent to Guix?  I have seen some patches, and participated, but I have to go look
> for those, and it’d be more convenient if they were directed to me in the first
> place.

I believe the usual way of doing something like this is via teams (see
./etc/teams.scm ).

-- 
Suhail

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

Suhail Singh <suhailsingh247@gmail.com> writes:

> Ian Eure <ian@retrospec.tv> writes:
>
>> The initial patch to update the version to 127.x was submitted 
>> on June
>> 29th; updated to 128.x on July 17th; and I’ll be sending the 
>> patch
>> updating it to 129.x later today, after I’ve finished building 
>> and
>> testing it.
>
> Thank you for your continued commitment to this despite the lack 
> of
> timely review.
>

I appreciate your kind words; thank you.


>> I’m stuck in an impossible situation.  I can’t apply for 
>> committer access until
>> I have more accepted contributions, but can’t build those 
>> contributions unless
>> my patches are reviewed.  It’s frustrating and demoralizing.
>
> I can empathize.  I decided to take a step back from posting
> contributions earlier this year for similar reasons.  I am 
> hopeful this
> can improve in the (near) future.
>

I’m feeling very similarly, and have been biasing to maintaining 
my own channel lately.


>> A second, and smaller question, is: is there a mechanism to 
>> direct others’
>> contributions to LibreWolf to me for review, without 
>> subscribing to every patch
>> sent to Guix?  I have seen some patches, and participated, but 
>> I have to go look
>> for those, and it’d be more convenient if they were directed to 
>> me in the first
>> place.
>
> I believe the usual way of doing something like this is via 
> teams (see
> ./etc/teams.scm ).
>

I’m not sure whether/how well this mechanism works for 
non-committers.

Thanks,
  — Ian

Re: Request for assistance maintaining LibreWolf

[Tomas Volf]

Ian Eure <ian@retrospec.tv> writes:

>>
>> I believe the usual way of doing something like this is via teams (see
>> ./etc/teams.scm ).
>>
>
> I’m not sure whether/how well this mechanism works for non-committers.

I believe it should.  AFAIK pretty much all it does is to automatically
add the team members onto CC list when running `git send-email'.

At the same time it is not really meant as a general notification
system, so usefulness for you depends on whether some committer will
merge the commit adding librewolf team (with you in it).

Tomas

Re: Request for assistance maintaining LibreWolf

[Ludovic Courtès]

Hi Tomas, Ian, and all,

Tomas Volf <~@wolfsden.cz> skribis:

> Ian Eure <ian@retrospec.tv> writes:
>
>>>
>>> I believe the usual way of doing something like this is via teams (see
>>> ./etc/teams.scm ).
>>>
>>
>> I’m not sure whether/how well this mechanism works for non-committers.
>
> I believe it should.  AFAIK pretty much all it does is to automatically
> add the team members onto CC list when running `git send-email'.

Yes, it works whether or not one has commit rights, and I agree that it
could be helpful here.

> At the same time it is not really meant as a general notification
> system, so usefulness for you depends on whether some committer will
> merge the commit adding librewolf team (with you in it).

Ian, what about teaming up with other Firefox derivative maintainers?
I’m thinking notably of André and Clément who’ve worked on Tor Browser
on Mullvad Browser, Mark H Weaver who’s been maintaining IceCat, and
perhaps Jonathan who’s been taking care of IceDove (Cc’d)?

Of course, each of these package is different but they’re in the same
area so it probably makes sense to share reviewing efforts here.

Thanks,
Ludo’.

PS: I too have been a happy LibreWolf user for some time now, so I join
    others in thanking you for the great work!

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

Hi Ludo’,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Tomas, Ian, and all,
>
> Tomas Volf <~@wolfsden.cz> skribis:
>
>> Ian Eure <ian@retrospec.tv> writes:
>>
>>>>
>>>> I believe the usual way of doing something like this is via 
>>>> teams (see
>>>> ./etc/teams.scm ).
>>>>
>>>
>>> I’m not sure whether/how well this mechanism works for 
>>> non-committers.
>>
>> I believe it should.  AFAIK pretty much all it does is to 
>> automatically
>> add the team members onto CC list when running `git 
>> send-email'.
>
> Yes, it works whether or not one has commit rights, and I agree 
> that it
> could be helpful here.
>

Sounds good -- I’ll send in a patch to add myself.  I’ve run into 
a couple cases where patches got merged while I’ve had other 
patches open, and getting notified will help coordinate which 
stuff goes when.


>> At the same time it is not really meant as a general 
>> notification
>> system, so usefulness for you depends on whether some committer 
>> will
>> merge the commit adding librewolf team (with you in it).
>
> Ian, what about teaming up with other Firefox derivative 
> maintainers?
> I’m thinking notably of André and Clément who’ve worked on Tor 
> Browser
> on Mullvad Browser, Mark H Weaver who’s been maintaining IceCat, 
> and
> perhaps Jonathan who’s been taking care of IceDove (Cc’d)?
>

> Of course, each of these package is different but they’re in the 
> same
> area so it probably makes sense to share reviewing efforts here.
>

This makes a lot of sense to me, and I think it would solve my 
immediate problem.  Would it make sense to set up a browser-team 
mailing list and etc/team.scm which notifies that of patches/bug 
reports sent on any of the browser packages?


> PS: I too have been a happy LibreWolf user for some time now, so 
> I join
>     others in thanking you for the great work!
>

I really appreciate hearing this, thank you for saying.

Thank,

  — Ian

Re: Request for assistance maintaining LibreWolf

[Ludovic Courtès]

Hi,

Ian Eure <ian@retrospec.tv> skribis:

> This makes a lot of sense to me, and I think it would solve my
> immediate problem.  Would it make sense to set up a browser-team
> mailing list and etc/team.scm which notifies that of patches/bug
> reports sent on any of the browser packages?

I would suggest not creating a separate mailing list per team.  Anyone
sending patches in the team’s scope (the #:scope argument in
‘teams.scm’) automatically Cc’s team members, so you don’t miss things
relevant to you.

HTH!

Ludo’.

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Ian Eure <ian@retrospec.tv> skribis:
>
>> This makes a lot of sense to me, and I think it would solve my
>> immediate problem.  Would it make sense to set up a 
>> browser-team
>> mailing list and etc/team.scm which notifies that of 
>> patches/bug
>> reports sent on any of the browser packages?
>
> I would suggest not creating a separate mailing list per team. 
> Anyone
> sending patches in the team’s scope (the #:scope argument in
> ‘teams.scm’) automatically Cc’s team members, so you don’t miss 
> things
> relevant to you.
>

How does one request the creation of a browser-team mailing list?

Thanks,

  — Ian

Re: Request for assistance maintaining LibreWolf

[Tobias Geerinckx-Rice]

Hullo Ian,

On 28 August 2024 23:15:23 UTC, Ian Eure <ian@retrospec.tv> wrote:
>Ludovic Courtès <ludo@gnu.org> writes:
>> I would suggest not creating a separate mailing list per team.  […]
>How does one request the creation of a browser-team mailing list?

We'd ask the GNU sysadmins, but I agree with Ludo' here.



Kind regards,

T G-R

Sent on the go.  Excuse or enjoy my brevity.

[Browser-Team] Re: Request for assistance maintaining LibreWolf

[André Batista]

Hi Ian, browser-team, guix,

qui 29 ago 2024 às 07:30:39 (1724927439), me@tobias.gr enviou:
> Hullo Ian,
> 
> On 28 August 2024 23:15:23 UTC, Ian Eure <ian@retrospec.tv> wrote:
> >Ludovic Courtès <ludo@gnu.org> writes:
> >> I would suggest not creating a separate mailing list per team.  […]
> >How does one request the creation of a browser-team mailing list?
> 
> We'd ask the GNU sysadmins, but I agree with Ludo' here.
> 

So as to not trow the baby with the bath water, how about a subject
prefix to $team_name as in this current?

This way one can easily filter for that tag and redirect it to a higher
priority box or organize its archive localy and at the same time warn
subscribers that current message does not expect greater attention from
uninterested people on the list (all being equally welcome to comment,
of course).

I'm not very sure that this is needed as this list is not that busy, but
wouldn't mind it as well.

Re: [Browser-Team] Re: Request for assistance maintaining LibreWolf

[Ludovic Courtès]

André Batista <nandre@riseup.net> skribis:

> qui 29 ago 2024 às 07:30:39 (1724927439), me@tobias.gr enviou:
>> Hullo Ian,
>> 
>> On 28 August 2024 23:15:23 UTC, Ian Eure <ian@retrospec.tv> wrote:
>> >Ludovic Courtès <ludo@gnu.org> writes:
>> >> I would suggest not creating a separate mailing list per team.  […]
>> >How does one request the creation of a browser-team mailing list?
>> 
>> We'd ask the GNU sysadmins, but I agree with Ludo' here.
>> 
>
> So as to not trow the baby with the bath water, how about a subject
> prefix to $team_name as in this current?

Sounds perfect to me!

Ludo’.

Re: Request for assistance maintaining LibreWolf

[André Batista]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

Hi Ludo, Ian, guixen,

qua 21 ago 2024 às 22:54:31 (1724291671), ludo@gnu.org enviou:
> 
> > Ian Eure <ian@retrospec.tv> writes:
> >
> >>>
> >>> I believe the usual way of doing something like this is via teams (see
> >>> ./etc/teams.scm ).
> >>>
> >>
> >> I’m not sure whether/how well this mechanism works for non-committers.
> >
> > I believe it should.  AFAIK pretty much all it does is to automatically
> > add the team members onto CC list when running `git send-email'.
> 
> Yes, it works whether or not one has commit rights, and I agree that it
> could be helpful here.

Should I send a patch adding myself to the team? What is expected from
team members?

> > At the same time it is not really meant as a general notification
> > system, so usefulness for you depends on whether some committer will
> > merge the commit adding librewolf team (with you in it).
> 
> Ian, what about teaming up with other Firefox derivative maintainers?
> I’m thinking notably of André and Clément who’ve worked on Tor Browser
> on Mullvad Browser, Mark H Weaver who’s been maintaining IceCat, and
> perhaps Jonathan who’s been taking care of IceDove (Cc’d)?
> 
> Of course, each of these package is different but they’re in the same
> area so it probably makes sense to share reviewing efforts here.

I was reticent on this mainly because (i) I have never actually used
LibreWolf and I don't have a clear picture of it besides it being a
"Firefox + Arkenfox - Mozilla Branding" [1](?); (ii) I expect that most
of these security (aka urgent) patches will land on the same day on a
regular basis for all 4 browsers and given Mullvad and TorBrowser
sources will be late in the game, I'll probably not be able to do such
a timely (yet again, urgent) review, which could add to Ian's
frustration, instead of relieving it; and (iii) AFAIUI, LibreWolf moves
at a faster pace, which adds to my concern of not being able to keep up
in the long run.

That being said, given those patches have remained unreviewed for weeks
in a row, I guess I can at least help improve the current situation and
give commiters some more confidence that a given patch will not break
hell loose when commited and so I'm willing to help with these reviews.
However, I cannot promise to maintain it if/when Ian's lead happens to
go missing.

One question in that regard: is there any difference between reviewing
through QA's web interface and sending mail commands to debbugs'
control? Is any of them preferable? I'd rather use the mail interface if
that's enough.

Cheers.

1. No disrespect meant to the project or its users, just my own
current cluelessness exposed. I'll read the docs on it to understand
it better though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 667 bytes --]

Re: Request for assistance maintaining LibreWolf

[Ludovic Courtès]

Hello,

André Batista <nandre@riseup.net> skribis:

>> Yes, it works whether or not one has commit rights, and I agree that it
>> could be helpful here.
>
> Should I send a patch adding myself to the team? What is expected from
> team members?

Yes, you can send a patch.

Team members are expected to coordinate and work together (e.g., for
review) on everything in the team’s scope, onboard new members willing
to help, and coordinate with the rest of the project.

(That <https://guix.gnu.org/manual/devel/en/html_node/Teams.html>
doesn’t even say this is something we should fix!)

>> Ian, what about teaming up with other Firefox derivative maintainers?
>> I’m thinking notably of André and Clément who’ve worked on Tor Browser
>> on Mullvad Browser, Mark H Weaver who’s been maintaining IceCat, and
>> perhaps Jonathan who’s been taking care of IceDove (Cc’d)?
>> 
>> Of course, each of these package is different but they’re in the same
>> area so it probably makes sense to share reviewing efforts here.
>
> I was reticent on this mainly because (i) I have never actually used
> LibreWolf and I don't have a clear picture of it besides it being a
> "Firefox + Arkenfox - Mozilla Branding" [1](?); (ii) I expect that most
> of these security (aka urgent) patches will land on the same day on a
> regular basis for all 4 browsers and given Mullvad and TorBrowser
> sources will be late in the game, I'll probably not be able to do such
> a timely (yet again, urgent) review, which could add to Ian's
> frustration, instead of relieving it; and (iii) AFAIUI, LibreWolf moves
> at a faster pace, which adds to my concern of not being able to keep up
> in the long run.
>
> That being said, given those patches have remained unreviewed for weeks
> in a row, I guess I can at least help improve the current situation and
> give commiters some more confidence that a given patch will not break
> hell loose when commited and so I'm willing to help with these reviews.
> However, I cannot promise to maintain it if/when Ian's lead happens to
> go missing.

Sure.  The goal is to create a group of people with similar interests
and a commitment to help together (of course team members can resign
anytime they feel they will no longer be able to honor that commitment).

Surely you’d do a better job at reviewing LibreWolf patches than myself,
say, thanks to the experience you have with Tor Browser.

> One question in that regard: is there any difference between reviewing
> through QA's web interface and sending mail commands to debbugs'
> control? Is any of them preferable? I'd rather use the mail interface if
> that's enough.

The interface at <https://qa.guix.gnu.org/patches> shows results from
automated builds, as an aid for reviewers.  The actual interface for
reviews remains email.

HTH!

Ludo’.

Defining the role of teams

[Ludovic Courtès]

Hello Guix,

Ludovic Courtès <ludo@gnu.org> skribis:

> Team members are expected to coordinate and work together (e.g., for
> review) on everything in the team’s scope, onboard new members willing
> to help, and coordinate with the rest of the project.
>
> (That <https://guix.gnu.org/manual/devel/en/html_node/Teams.html>
> doesn’t even say this is something we should fix!)

Here’s an attempt at doing that (I meant to Cc: guix-devel but forgot):

  https://issues.guix.gnu.org/72891

Everyone: please do chime in at 72891@debbugs.gnu.org to share
suggestions and comments about the proposed paragraphs.

Ludo’.

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

Hi André,

André Batista <nandre@riseup.net> writes:

>> > At the same time it is not really meant as a general 
>> > notification
>> > system, so usefulness for you depends on whether some 
>> > committer will
>> > merge the commit adding librewolf team (with you in it).
>> 
>> Ian, what about teaming up with other Firefox derivative 
>> maintainers?
>> I’m thinking notably of André and Clément who’ve worked on Tor 
>> Browser
>> on Mullvad Browser, Mark H Weaver who’s been maintaining 
>> IceCat, and
>> perhaps Jonathan who’s been taking care of IceDove (Cc’d)?
>> 
>> Of course, each of these package is different but they’re in 
>> the same
>> area so it probably makes sense to share reviewing efforts 
>> here.
>
> I was reticent on this mainly because (i) I have never actually 
> used
> LibreWolf and I don't have a clear picture of it besides it 
> being a
> "Firefox + Arkenfox - Mozilla Branding" [1](?); (ii) I expect 
> that most
> of these security (aka urgent) patches will land on the same day 
> on a
> regular basis for all 4 browsers and given Mullvad and 
> TorBrowser
> sources will be late in the game, I'll probably not be able to 
> do such
> a timely (yet again, urgent) review, which could add to Ian's
> frustration, instead of relieving it; and (iii) AFAIUI, 
> LibreWolf moves
> at a faster pace, which adds to my concern of not being able to 
> keep up
> in the long run.
>
> That being said, given those patches have remained unreviewed 
> for weeks
> in a row, I guess I can at least help improve the current 
> situation and
> give commiters some more confidence that a given patch will not 
> break
> hell loose when commited and so I'm willing to help with these 
> reviews.
> However, I cannot promise to maintain it if/when Ian's lead 
> happens to
> go missing.
>

This sounds reasonable to me, and I would greatly appreciate any 
assistance that could be provided.  My hope is that with some 
closer working relationships with existing Guix folks and more 
contributions, I can apply for commit access and maintain 
LibreWolf autonomously.  Perhaps next year.


> One question in that regard: is there any difference between 
> reviewing
> through QA's web interface and sending mail commands to debbugs'
> control? Is any of them preferable? I'd rather use the mail 
> interface if
> that's enough.
>

There’s no major difference, whichever you prefer.  I think email 
is more likely to keep threads grouped.


> Cheers.
>
> 1. No disrespect meant to the project or its users, just my own
> current cluelessness exposed. I'll read the docs on it to 
> understand
> it better though.
>

None taken, and you’re on the right track.  LibreWolf ships 
several improvements combined into one package, including 
hardening the default preferences, disables the numerous 
anti-features that ship with Firefox (full page ads on update, 
Pocket, telemetry, DRM, etc).  They also don’t have the onerous 
trademark and logo requirements, which lets distrbutions ship with 
the upstream branding.  The combination of better defaults, 
relaxed branding requiements, and closely tracking upstream make 
it a very compelling choice, IMO.  I’ve been daily driving it for 
several years.

Thanks,

  — Ian

Re: Request for assistance maintaining LibreWolf

[Andy Tai]

I wonder how scalable this approach is, if many "package maintainers"
each have their own channel for the packages they are maintaining, and
made available this way.   I would guess to use this approach the Guix
users have to do "guix package -u --allow-collision"

> Date: Sat, 17 Aug 2024 12:43:11 -0700
> From: Ian Eure <ian@retrospec.tv>
> Whatever the state of Guix proper, you can always find the current
> version of LibreWolf in my personal channel[1], though I don’t
> have a public substitute server, so long build times will await
> you if you choose this route.

Re: Request for assistance maintaining LibreWolf

[Ian Eure]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

It's not, IMO, because while it's very easy to set up a channel, it's very difficult to publish substitutes for it.

I don't think collisions are any more likely, but perhaps you know of cases I haven't encountered.

The larger risk is divergence of package definitions, so version X of a package in Bob's channel works very differently than version X+1 in Alice's.

I'd greatly prefer to do the maintenance in Guix, as it'd be much simpler for everyone.

 — Ian

On August 17, 2024 5:11:44 PM PDT, Andy Tai <atai@atai.org> wrote:
>I wonder how scalable this approach is, if many "package maintainers"
>each have their own channel for the packages they are maintaining, and
>made available this way.   I would guess to use this approach the Guix
>users have to do "guix package -u --allow-collision"
>
>> Date: Sat, 17 Aug 2024 12:43:11 -0700
>> From: Ian Eure <ian@retrospec.tv>
>> Whatever the state of Guix proper, you can always find the current
>> version of LibreWolf in my personal channel[1], though I don’t
>> have a public substitute server, so long build times will await
>> you if you choose this route.
>

[-- Attachment #2: Type: text/html, Size: 1656 bytes --]