Which, as far as I found so far, means Forgejo. Haven't found any others. And even Forgejo Actions says that it's mostly the same as Github Actions syntax, meaning you still have to double-check that everything still works the same. It probably will, but if you don't know what the corner cases are then you have to double-check everything. Still, it's probably the best migration option if you rely on GHA.
> On long distance trips I spend 1 hour charging for every 2 hours driving
In Spain, I take ~600km trips every once in a while. I just need to charge once in the middle of the trip, in a super-charger that is. And the charge is 25min maximum.
Your experience varies is basically opposite from my experience. Your situation is probably influenced, indeed, by the poor choice of EVs you purchased (range is the most important factor for me to buy) and the lack of superchargers around your area.
If an Ioniq 5 is a poor choice, I would love to know what a good choice is. Its energy usage is comparable to the vast majority of SUVs and it can charge at up to 227kW. The lack of good fast charger is certainly a difference compared to many areas.
Only the Long Range version of the Ioniq5 has decent range IMO. And BTW, the fact that it's an SUV is precisely a downside about it; smaller cars would have obviously more efficiency.
No. Very much no. It means that gold does not have a stable value, and using it as the yardstick to measure the value of other things just leads to confusion.
Notice how they say “No PR” on every single repo ? So for sure no PR was open.
Putting a bit more energy, you are redirected to a whole other system which I have never seen anywhere else (and in this case; unique doesn’t mean good). After 5 minutes of trying to navigate what is probably the least intuitive software forge I ever had the displeasure to witness, you understand that clearly these guys live in a different UI/UX bubble than the rest of us.
Seems like they use gerrit. A lot of larger projects use gerrit for their code review. It is different, yes, but many prefer it over GitHub's "pull request" paradigm which really sucks for high velocity contributors.
This is bad faith. You are not obligated to contribute any sort of code to point out problems in an open source project.
When I go to a restaurant and order a steak, and it arrives and tastes awful, the waiter does not have the right to say to me "if you don't like it, cook it yourself". The chef does not have the right to say to me "tell me exactly what I did wrong, since you're claiming you're an expert on steaks".
No. Anyone can complain about a thing, and the fact that they haven't tried to fix the code themselves is utterly irrelevant.
The difference is that at a restaurant you’re paying for it. If you show up at a soup kitchen and complain that it wasn’t seasoned just right, that’s fully on you.
I agree, I looked around my area and found a task on top of a parking lot that says: "These elements have rare (<20 uses) parking=* values." What does this mean? Does it mean that the parking log is marked to have a "<20" value when the value should be a number instead of a string? Obviously I'm not going to go inside the car park and count all the park slots, there could be hundreds!
That likely means something like "This is using a rare value for the key 'parking'. It might be incorrect, check that it's not supposed to be a more common value".
In other words, it's trying to catch things like typos.
I tried items with rare values for 'surface.' I found and fixed a footpath through a pasture (the docs seemed to imply that "dirt" is sufficient for a path through a pasture). But my next item was in China and the surface was "木" which apparently means Wood. But the rest of the fields of this pier were also in Chinese, and I was too shy to update it. I hope that localization is handled separately and that it would have been fine, but... it would be super annoying if a Chinese-speaking editor updated an American map to have details all in Chinese. Googling "are tags on openstreetmap supposed to always be in English?" gave no hints.
In this case, the spec allows for "commonly used" user defined values, which is unusual (how does a user defined value become commonly used enough in the first place?), measured per this site: https://taginfo.openstreetmap.org/keys/surface#values
You can find a few non English entries in there, but the vast majority and all of the most common ones are in English. "木“ has 2 entries, "wood" has >200k. I think it's pretty clear that even in cases when the specification is open, the intention is for values to be English whenever practical.
You misinterpreted the wiki page. That tag (like several others) explicitly supports user-defined values. This is useful, because you cannot define a complete set of values for something as open-ended as a way's surface. Innovations happen, and sometimes odd things are used to pave a way for a variety of reasons (art, tourist appeal, experiments, etc.)
So that table there lists all common values covering 99% of the use cases, and finally links to TagInfo for all values in use. That 'all commonly used values' bit is slightly misleading, because TagInfo lists all uncommon values, but it true in the sense that any common value missing from that table will be listed in TagInfo (being derived from the actual database).
OpenStreetMap generally follows the guideline that all tags and generic values (i.e., not names and other language dependant stuff) are written in British English. Exceptions exist due to the way this project works. The wiki is the primary place to go for documentation of tags and values.
So yes, surface=木 is wrong, but to replace it you would have to know if the path uses wood-chips (`woodchip`) or boards (`wood`).
reply