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
André Batista skribis:
> qui 29 ago 2024 às 07:30:39 (1724927439), m...@tobias.gr enviou:
>> Hullo Ian,
>>
>> On 28 August 2024 23:15:23 UTC, Ian Eure wrote:
>> >Ludovic Courtès writes:
>> >> I would suggest not creating a separate mailing list per team. […]
>> >How does one request the creat
Hi Ian, browser-team, guix,
qui 29 ago 2024 às 07:30:39 (1724927439), m...@tobias.gr enviou:
> Hullo Ian,
>
> On 28 August 2024 23:15:23 UTC, Ian Eure wrote:
> >Ludovic Courtès writes:
> >> I would suggest not creating a separate mailing list per team. […]
> >How does one request the creation
Hullo Ian,
On 28 August 2024 23:15:23 UTC, Ian Eure wrote:
>Ludovic Courtès 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,
Hi André,
André Batista 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
Ludovic Courtès writes:
Hi,
Ian Eure 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?
Hi,
Ian Eure 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 creatin
Hello,
André Batista 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 w
Hi Ludo, Ian, guixen,
qua 21 ago 2024 às 22:54:31 (1724291671), l...@gnu.org enviou:
>
> > Ian Eure 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-c
Hi Ludo’,
Ludovic Courtès writes:
Hi Tomas, Ian, and all,
Tomas Volf <~@wolfsden.cz> skribis:
Ian Eure 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 belie
Hi Tomas, Ian, and all,
Tomas Volf <~@wolfsden.cz> skribis:
> Ian Eure 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
Christopher Baines writes:
[[PGP Signed Part:Undecided]]
Ian Eure 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
he
Hello Christopher.
Christopher Baines 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
Ian Eure 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
Ian Eure 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
responsi
Ian Eure 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 l
Hi Christopher,
Christopher Baines writes:
[[PGP Signed Part:Undecided]]
Sergio Pastor Pérez 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 pa
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 c
> 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
Sergio Pastor Pérez 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 disc
Suhail Singh writes:
Ian Eure 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 c
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
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
Ian Eure 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 despit
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
Hi Sergio,
Sergio Pastor Pérez 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 alway
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
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 mai
28 matches
Mail list logo
