apt-get purge chromium

As you may know, I was the Debian chromium maintainer for many years. Some week ago, I decided to stop working in the chromium package because it is not possible anymore to contribute and work in the team. In fact, Michael Gilbert started to work in a manner that prevent people to help maintain the package.

In the last period the git repository rarely was updated, and my requests were systematically ignored. Having an updated git repository is mandatory in a big package like Chromium, and if you don’t push your changes, other people will lost their time…

Now, after deciding to stop maintaining Chromium, I also decided to purge it and switch to the Google Chrome binary. Why? Chromium is a pain. Huge commits not documented in changelog that caused stupid bugs because no one can double check them.

In this moment we have an unusable [1][2] [3] version of Chromium in testing because maintainer demoted grave bugs with the recommendation to rm -rf ./config/chromium … and nobody can understand the sense of latest commits.

Hi there, FYI i switched to epiphany-browser and am almost completely happy with it 🙂

Julian Andres Klode

I agree. I did the same. I have no trust in Michael Gilbert.

tosky

Pretty please, Giuseppe, use the proper escalation procedure (someone told me about NM team or something like that), it’s not the first time the packages from this DD receive this kind of “work”. Don’t give up!

Mathis DT

I was surprised that after an “aptitude dist-upgrade” in Debian Testing some things in Chromium stopped working, but now I know why. I also did the switch to Google’s package.

So you’d rather use proprietary software, yeah… that makes perfect sense 😐

Valentine North

There are plenty other open source alternatives, Firefox being my favorite one.
Oh, yes, I do have Chrome installed :p, but only for flash games.

Michael Gilbert

Unstated is the fact that chromium is a “nightmare” package (hundreds of embedded code copies, hours for each build iteration, enormous upstream changes every 6 weeks, a massive number of security updates more often than that, etc.), and the cruftiness of the packaging is itself what had become the primary maintenance roadblock.

That nightmare setup is why maintaining the package is often times difficult and time-consuming, and I can fully empathize with Guiseppe’s frustration, but not the target of that frustration.

The package simply needed to be rewritten to get the it out of the way; to reduce the amount of time required for keeping up new versions; and to make it the high pace of security updates supportable for jessie.

I spent a rather huge amount of my personal time improving the package, which is why rather large commits were the outcome. Could I have done more micro-commits? Sure, but that would have meant more of my limited free time. Not only that, I basically jettisoned the original packaging in order to bring in only what was needed, so at least one huge commit was basically unavoidable.

So, yes, there are a few parts of humpty dumpty to piece back together still, but they are all mindless touch ups, not the seemingly catastrophic exaggerations here. And after today’s upload, most of those pieces are back in place, so there was no need for the premature vitriol and abdication.

Anyway, I never bear animosity toward anyone, and I welcome Giuseppe back to the team if he ever so chooses. And, if not, the package is now easier to maintain, which means less of my time and a lower barrier to entry for new contributors anyway.

I confirm that if you think this is the correct way to maintain a package, you cannot work in a team. The experimental branch was outdated for at least five months. I sent you ton of emails but nothing.
The fact that you spent a lot of your personal time in improving the package doesn’t mean you are authorized to deny people in co-maintain and hinder people with huge and incomprehensible commits or hide changes in debian/changelog .

Nik

No matter what the background is, you should be ashamed for proposing the use of an untrusted binary third-party build of proven spyware.

That’s something different than “proposing the use of an untrusted binary”
Anyway, is know from who? Have you analyzed the Chrome binary? Or are you talking about something you know using second-hand information?