The improvements are solid! I think 5x6 was the right call...it's a good balance of being able to reuse strategies from 5x5 but also having to develop some new strategies.
Just note that listing is for an item from a third-party seller. Walmart's website includes listings from their third-party marketplace unless you explicitly filter them out.
> I've seen codebases that enforce these commit prefixes such as "chore", "feat", "bugfix" etc. Is there any real value to that?
It's a choice some teams make, presumably because _they_ see value in it (or at least think they will). The team I'm on has particular practices which I'm sure would not work on other teams, and might cause you to look at them with the same incredulity, but they work for us.
For what it's worth, the prefixes you use as examples do arise from a convention with an actual spec:
Just because someone put up a fancy website and named it "conventional" doesn't mean it's a convention or that it's a good idea.
The main reason this exists is because Angular was doing it to generate their changelogs from it. Which makes sense, but outside of that context it doesn't feel fully baked.
I usually see junior devs make such commits, but at the same time they leave the actual commit message body completely empty and don't even include a reference to the ticket they're working on.
> Or otherwise you can enable the app exposé feature to swipe down with three fingers and it will show you only windows of the same app.
If you have an Apple keyboard, CTRL-F3 (without the Fn modifier) will do the same. Not sure if there are third-party keyboards that support Mac media keys, but I'm guessing there are some at least...
Welp, now that there is confirmation that lawyers are involved, the chances there will be any of sort of open and transparent reconciliation process have plummeted.
Er...FYI, your [2] link is to a discussion about an article written by the person to whom you are responding.
Personally, I think the reason this post about gem.coop has been flagged is that we've reached the point at which new HN threads about things related to the recent RubyGems shake-up quickly devolve into people rehashing the DHH "aspect" of it all. So it has become less about flagging the actual target of the post and more about flagging the parts of the discussion that seem to go nowhere.
That's fair enough, I didn't actually notice. Regardless, I was offering the information for other readers, which may or may not include the person I'm replying to.
Edit:
> flagging the parts of the discussion that seem to go nowhere
This is and isn't what actually happens, though. People do flag the parts of the discussion that don't go anywhere but then people also flag the post itself because they think there's no reason to discuss it at all for the fact there's a vocal part (minority or majority doesn't really matter) that wants to discuss a topic that's not going anywhere.
People shouldn't flag the post itself just because it's likely to gather or even has gathered a crowd that will discuss such directionless topics when there are better topics to discuss, even (especially?) if they're not currently being discussed.
There have been several releases with incremental but still notable performance improvements. The overall cadence has been pretty steady, intentionally targeting roughly one minor release per year since 2019-ish, with handfuls of quality of life improvements in each. Arguably RubyGems and Bundler are infrastructure, so the major feature is stability. What sort of big feature are you imagining is missing from your dependency management system?
André is working on a combination of rbenv/asdf, bundler, and gem that I think is interesting. Not that they're wildly broken, but I'd rather have fewer tools and it always seemed a bit odd that they're separate when they're notionally managing the environment in which your ruby code executes.
Given the rise in supply chain attacks, I'd also like a private rubygem instance where I can whitelist gems and even versions for my company in a way that doesn't let anything else install. I'm not sure if they're taking that on or not, but I'd like it.
That's basically my point. I'm not missing anything, so I'm happy if it just gets small / stability fixes, which doesn't seem like it needs a six member maintainer group. That team should go off and do a great job with 'rv' or whatever the next brand new idea is, and just let rubygems sit there with minor updates, same as we do for the ruby logger or date class.
It seems unrealistic to believe that packaging infrastructure can just “sit there,” particularly in light of changing expectations around the bare minimum a packaging ecosystem should do to protect its users. I think a more reasonable assumption would be that the (former) RubyGems team did a good job, which translated to boring normality for you.
Not sure what post you have in mind, but Kenji Alt-Lopez's video[1] on the topic is excellent. If I remember right, it's based on work he did with a well-known food publication (or show or something)...
There is some more context on a post[1] in /r/ruby, including the fact that the maintainers and others had been working on a proposal[2] for a formalized organizational governance structure as recently as yesterday. The latter also adds some context into Mike McQuaid's involvement: the proposal was influenced by the structure put in place by the Homebrew project.
I'm trying to help, where I can, to mediate. On a call right now about this. Had 4 in the last 24 hours with affected parties past and present on both sides.
I'm not involved beyond just caring a lot about Ruby.
TL;DR: I've been given a lot of private nuance from both sides here but, even just based how the two sides have treated me personally, it's very hard not to put the blame primarily on RubyCentral. I've been a maintainer on Homebrew for 16 years: it's a hard job. If in doubt: I'll side with maintainers.
Sure, but it's two different things. Maintainers are in charge of their projects, and Ruby Central is in charge of the package index. Each has different priorities, which is fine. If they can't find a way to live with each other, maybe a parting of the ways is required.
Parting of ways? Sure. In this case they are in charge of the package index but have removed most maintainers from their projects, implicitly taking charge there too. This is a problem.
How can they remove maintainers from their own projects? If my project is yawaramin/foobar, how can Ruby Central remove me as the mantainer from there?
This thread has probably run its course, and newer postings[1] have more information, but I'll respond anyway if it's helpful...
> How can they remove maintainers from their own projects? If my project is yawaramin/foobar...
The official RubyGems projects in question were under a GitHub organizational account, not a single user's account. A subset of the maintainers had the "owner" flag on the org. One of those folks basically initiated the takeover. See [2] for a more detailed recounting.
That's a dumb move though, isn't it? The original maintainers will now just move their projects somewhere else, and the 'official' projects have now effectively been killed. This is a suicidal move for the Ruby ecosystem.
"Ruby Central has been the RubyGems maintainer and operator since the beginning. They paid people to work on it (including this now disgruntled former contractor).
They're improving their practices and protocols. This is good."
A bit of useful context for DHH’s response: he’s had beef with at least one of these maintainers before, and tried to get him removed from stuff.
As André Arko’s employer at his day job at the time, I was tangential to it, so I don’t know all the details, and my memory is imperfect.
But as I understand it, DHH either organized or was part of a group of prominent rubyists who wrote a letter to the Board of Directors of the trade guild (or some other similar unusual non-profit structure) that André had organized to help get funding to support the open source work he and some others did for Ruby infrastructure like Bundler and/or Rubygems. I don’t know the exact terms of the sanctions they sought, but in the end it resulted in his orgs work getting folded into RubyCentral, iirc.
For some reason it seems they disapproved of how André had found a way to get paid for working on open source. He was managing to pay himself and some other people a good wage for part-time open source work. He was even managing to get a bit more diversity involved in it than a lot of Ruby open source infra work typically has (employing a black trans woman SE as part of this). Whatever their actual motivations they disapproved of André founding his own org and running it as he did.
The irony of their most prominent signatory getting rich off open source, via a different less direct avenue of monetization seemed entirely lost on them.
Anyway, I think it blew up in their face and things got settled out into what the status quo of rubygems maintenance was since then.
Now, I’ve heard rumors that perhaps this is actually related. RubyCentral has had a rough few years and DHH has more than a little pull with at least one of their largest funders.
It’d be incredibly petty to do something like dangling funding in front of RC if they’d finish icing out maintainers that he didn’t see eye to eye with. But it would certainly fit the way the events happened. I don’t know anything directly enough to swear by this and wouldn’t want to implicate anyone even if I did.
But I guess look at the known character of the people involved and draw your own conclusions. Does this seem in character to prior behaviors?
Thanks. Re “scoop” as I said, I wouldn’t swear to any of this on the stand and it certainly doesn’t meet journalistic standards. Consider it opinion piece/color commentary.
…
That said both the person this time and people before who allegedly signed onto DHH’s nonsense I’m incredibly disappointed in. Most of them I considered at the least collegial acquaintances and some of them friends. So I felt like I knew them at least well enough to say they were above his sort of divisive rhetoric. But people frequently disappoint.
Maybe I have it all wrong and André, REDACTED, and REDACTED* have done something awful or something…. but from what I know of their characters I seriously doubt it.
Of course, IDK what the DHH crowd is actually thinking, if any of this is true, since in that case they don’t exactly discuss this openly, purely dealing in backroom shenanigans that one could almost think verged on collusion and that leads some groups like RC to possibly violate contract and employment law (at the very least copyright if you check who actually has the copyright on some of the stuff they distribute…). That is if any of the things people are saying is true.
But hey, Rubyists are all “nice” right? Nobody says ethical or kind was a requirement.
* There’s at least two people that I kno- err that is that I strongly suspect, have been tarred by mere association with André. I have a theory it’s more than just them. Apparently he’s insidious about leaking liberal labor thoughts like people should get paid enough to support their families in expensive tech hubs, even if they are working on open source. But apparently “professional open source maintainer” is anathema to some people’s vision and they’d prefer everything to depend on volunteer labor only. Which is a position multi-millionaires who successfully monetized that volunteer labor could take, sure. But it’d make them hypocrites, in the worst of ways. Especially since their alleged actions are leading to some of said maintainers losing work doing so, but they supposedly seem okay with funding others. At that point it stops being a logical, if unethical platform, and more personal spite?
The improvements are solid! I think 5x6 was the right call...it's a good balance of being able to reuse strategies from 5x5 but also having to develop some new strategies.