Bug#1016047: RFH: chromium -- web browser

[karthek]

On Mon, 25 Jul 2022 21:45:33 -0400 Andres Salomon  wrote:
> Package: wnpp
> Severity: normal
> 
> I'm currently the only active maintainer for the chromium package in 
> Debian. This really needs to be maintained by a team, especially since 
> it requires security updates for stable at least two times per month. 
> It is likely that chromium will not be included in the next stable 
> release (bookworm) unless there's an active team maintaining it, as 
> described in . I've done a lot of 
> simplification of the chromium patches and packaging in order to make 
> it easier for people to join the team.
> 
> There are lots of available tasks to do, depending on someone's skill 
> and hardware. I've listed some tasks/roles below, with the most urgent 
> at the top.
> 
> 
> 1) Security updates. These usually only require Debian packaging 
> knowledge, and be pretty simple. Most security updates can be built 
> without having to touch any of the chromium patches, with only a 
> debian/changelog entry update. However, builds take 3 hours on my 8 
> cpu/32gb build machine (45 mins at best with ccache, due to a lot of 
> python and node build stuff that can't be cached), so you'll want 
> access to some good hardware. These can also happen at any time; 
> holidays, weekends, even a day or two before a scheduled release. 
> Ideally several people would be available for packaging security 
> updates.
> 
> 
> 2) Fixing bugs. There's plenty of bugs at
> . 
> Some require simple follow-ups with the reporter to see if it's still 
> an issue, others require in-depth C++ or chromium knowledge or special 
> hardware, and still others require just testing out a build-argument to 
> see if some feature is safe to enable.
> 
> 
> 3) Getting patches upstream. When I took over the package 6mo ago, 
> there were around 70 or 80 debian patches. We're down to 43 patches. 
> Only about 10 of those are debian-specific; the rest are patches that 
> really belong upstream. If you want to actually hack on chromium, this 
> is probably a good way to get started.
> 
> 
> 4) Improving chromium's privacy, as described at 
> .
>  
> It'd be really nice to not have chromium "phone home" to google.
> 
> 
> Please consider helping out! There's surely more stuff that's needed to 
> do as well, that I've forgotten about.
> 
> 
> 
>

I can help. But chromium builds(default config) are taking more than an hour in 
my
machine. I tried helping but got no response last year during the time
Michael Gilbert took a holiday from uploads.

I think i can help with small things here and there.

Like this pull request:
https://salsa.debian.org/mimi8/chromium/-/merge_requests/4

Bug#1016047: RFH: chromium -- web browser

[Andres Salomon]

Package: wnpp
Severity: normal

I'm currently the only active maintainer for the chromium package in 
Debian. This really needs to be maintained by a team, especially since 
it requires security updates for stable at least two times per month. 
It is likely that chromium will not be included in the next stable 
release (bookworm) unless there's an active team maintaining it, as 
described in . I've done a lot of 
simplification of the chromium patches and packaging in order to make 
it easier for people to join the team.


There are lots of available tasks to do, depending on someone's skill 
and hardware. I've listed some tasks/roles below, with the most urgent 
at the top.



1) Security updates. These usually only require Debian packaging 
knowledge, and be pretty simple. Most security updates can be built 
without having to touch any of the chromium patches, with only a 
debian/changelog entry update. However, builds take 3 hours on my 8 
cpu/32gb build machine (45 mins at best with ccache, due to a lot of 
python and node build stuff that can't be cached), so you'll want 
access to some good hardware. These can also happen at any time; 
holidays, weekends, even a day or two before a scheduled release. 
Ideally several people would be available for packaging security 
updates.



2) Fixing bugs. There's plenty of bugs at
. 
Some require simple follow-ups with the reporter to see if it's still 
an issue, others require in-depth C++ or chromium knowledge or special 
hardware, and still others require just testing out a build-argument to 
see if some feature is safe to enable.



3) Getting patches upstream. When I took over the package 6mo ago, 
there were around 70 or 80 debian patches. We're down to 43 patches. 
Only about 10 of those are debian-specific; the rest are patches that 
really belong upstream. If you want to actually hack on chromium, this 
is probably a good way to get started.



4) Improving chromium's privacy, as described at 
. 
It'd be really nice to not have chromium "phone home" to google.



Please consider helping out! There's surely more stuff that's needed to 
do as well, that I've forgotten about.