Timvde / UserChrome-Tweaks

A community maintained repository of userChrome.css tweaks for Firefox
GNU General Public License v3.0
1.25k stars 122 forks source link

About the future of this repository #125

Open Timvde opened 5 years ago

Timvde commented 5 years ago

Hi all,

I started this repository because I had the feeling somebody needed to step up and do it. Over the past year-and-a-few-months, I learned a few things:

So, how would I like to proceed? I still think that this repository can have purpose for many, and seeing PRs arrive every now and then, I think I'm not alone. So I'd like to make this a real community repository that minimizes the work for me, and gives all of you more freedom. More concretely:

How does this sound?

@Madis0 I am particularly interested in your opinion, as I see that you have forked this repository.

Madis0 commented 5 years ago

Other than the latency, my primary motivation for forking was #58 - if we could all make the code reStyle-compatible, it would be easier for both developers and users to use this, like in the old Stylish days.

Here are my suggestions:

Timvde commented 5 years ago

Require userStyle-compatibility for every new PR and possibly revise old ones (#58, maybe some CI?)

Now I read that again, I see no reason not to add an @-moz-document to the styles. It seems better than the namespace I had in mind earlier.

Some kind of CSS lint CI (not familiar with CIs yet, so can't be more specific)

The thing is: me neither. I looked into this shortly, but I couldn't easily figure it out. That's why I proposed to do no checking at all.

Consistent branches - either automate the versioning with Firefox's calendar somehow or get rid of the branches altogether and just mention in code comments what it has been tested with

That's not really a lot for work actually. The problem there is that I postponed branching until after I merged in some PRs, but then never got to merging them...

No need to test every piece of code IMO, CSS can't do very malicious things (that could not be reverted easily)

Yes, it wasn't because of security, but correctness on all platforms. People usually only test on their own platform, but Firefox is different on all OSes, e.g. window buttons on the left in MacOS, no tabs in title bar on most Linux DEs...

Madis0 commented 5 years ago

I looked into this shortly, but I couldn't easily figure it out.

Quick search now found me this. https://github.com/marketplace/codefactor/

That's not really a lot for work actually

So you are willing to adjust all branches on every Firefox major update?

correctness on all platforms.

I guess that could be solved by issues:

  1. Person 1 uploads a style for specific system/version
  2. Person 2 comes and claims it doesn't work well for them
  3. Person 3 with a similar system helps test and fix that

Asking uploaders to just test them on everything is going to slow/demotivate things down, especially because Firefox changes its CSS very often nowadays.

Timvde commented 5 years ago

I made a PR that adds all @-moz-document blocks. I have no idea if I should apply them to the style in the extension folder too. I copied the block from your quote in #58, but now I look at it, I actually think I should add quotes around the chrome:// url...

So you are willing to adjust all branches on every Firefox major update?

I won't maintain older branches, just fork once after every move from Nightly to beta

I guess that could be solved by issues

Agreed, that was the plan.

Asking uploaders to just test them on everything is going to slow/demotivate things down, especially because Firefox changes its CSS very often nowadays.

Yes, that's exactly what I noticed too, which is why I want to loosen it up.

Madis0 commented 5 years ago

I'll review your PR soon.

So how are the branches going to work for contributors? You should clarify that in contributing.md to make everyone push to the right one.

Also, you might want to create an issue template too.

Timvde commented 5 years ago

So how are the branches going to work for contributors? You should clarify that in contributing.md to make everyone push to the right one.

The PR should usually be to master. I won't merge new features in other branches, although I'd take a PR for beta or release (not for unsupported versions) if they fix a bug.

Also, you might want to create an issue template too.

What should be in it?

Madis0 commented 5 years ago

What should be in it?

Assuming the issue is about a style, otherwise the template can be ignored by the user.

https://help.github.com/articles/about-issue-and-pull-request-templates/