Cover crop seeds (basically grasses) and tree seeds are apples and oranges. You can spray grass seed on the surface of the dirt and it will grow into a meadow. The same can not be said for trees. They will be eaten by birds and mice and digested, not dispersed. They also don't germinate well when left on the surface of the soil.
It's also a matter of numbers - tree seeds are by comparison, incredibly expensive to harvest. There's an industry of people who will camp out in forests, stalk squirrels, and see where they're storing their nuts. Or they climb trees to manually harvest fresh pinecones. It's labor intensive and you need a permit to do it.
> There's an industry of people who will camp out in forests, stalk squirrels, and see where they're storing their nuts. Or they climb trees to manually harvest fresh pinecones. It's labor intensive and you need a permit to do it.
Given we don't have squirrels in Australia, I'd imagine the knowledge you're providing here around gathering and permits are not accurate to the company in discussion.
What if a drone were to shoot the seeds into the ground with such force that they would be buried 4-5 inches deep (which is, I would guess, the necessary depth for successful propagation)?
It's more like 1 in 3, an order of magnitude better. And they'd be sown under cover in more controlled conditions before planting out; not just tossed in the ground.
I've always seen conventional commits as an anti-pattern as it seems to discourage developers from writing small, atomic commits.
I think that a commit should always be as small as possible and have a descriptive, meaningful message. It is therefore pretty common that I end up with tens of commits when working on a simple feature. Which of these commits should be labelled as "feat" when the feature is added by a group of commits rather than a specific one, and that none of them really adds any feature? Also, a bug can be fixed by many commits. Which of these commits should be labeled as "fix"? We can't label all of them as fixes as cherry-picking only one of them wouldn't fix anything, which means the commit message would be misleading. The only solution left is to create one commit per bug fix or per feature.
Moreover, this information can (and should) be carried by the branch name already, as you'd usually branch off from your main branch to either fix a bug or develop a new feature. All you have to do is to follow a naming convention for your branch like "feature/my-awesome-feature" or "bugfix/fix-this-annoying-bug".
The only benefit I see with using conventional commits is generating changelogs automatically from your git history.
Conventional Commits restricts each commit to a single type of change - no mixing bug fixes, features, and refactoring. This supports exactly what you want - small, atomic commits.
Why can't each small change be labeled "feat"? A feature does not need to be contained in a single change as a "big bang" commit. I make multiple "feat" changes to deliver a feature.
I follow trunk-based development[1], so branches are many, transient, and disposable (and sometimes not even present if it's a small change I'm pushing straight to `main`).
The advantage of Conventional Commits is that I can go to my trunk (`main`), and scroll through the list of commits and see their purpose at a glance:
I nearly never look at individual commits in a PR.
I realize that this isn't applicable to all codebases, but when troubleshooting why a bug happens, or was intended to work, I find it a lot easier to look at a squashed commit than at the individual commits that went into a pull request. It does make `git bisect` less specific (and, to my shame, I've never used it), but having an overall commit message + pull request that points at a Jira ticket (or similar) helps identify whether something was intended behavior or not, and I've never felt the need to look deeper at whether part of it was a refactor/chore/feature. (If I had, I could look at the PR branch, presumably.)
In contrast, I've often had a stream of a 12-20 commits with tiny atomic (and often terrible) messages like "bugfix", "add test", "fix test", "fix linting", which I then try to rebase into some _coherent_ messaging of the time you espouse, where linting + typo fixes are rearranged and squashed on top of the commits that added them, and tests + features are added more closely together. It's very satisfying to do this, but in retrospect I've always felt like the time I spent doing that has been wasted --- it's hard, and often involves many iterations of conflict resolution when reordering commits, all for something that I or my team will squash anyway. The benefit gained (more readable commits of temporary value) never ever seems worth the time (Multiple hours) put into making them that way.
> I've always seen conventional commits as an anti-pattern as it seems to discourage developers from writing small, atomic commits.
Me too, actually I hate conventional commits with a pattern, because I have never seen a "conventional commit message" that actually does a good job. I've recently even written a short article on that subject (https://news.ycombinator.com/item?id=29924976) because it is so annoying to me that people think writing a "conventional commit message" alone results in better quality (hint: it does not).
I agree with you that such a commit has nothing to do in the main branch. But it has nothing it do in any branch that is shared with anyone either. Git has enough ways to keep your own history clean at all times to not require a hack like squash PRs to compensate the lack of discipline of a team. With squash PRs you lose so much valuable information that it gets impossible to use commands like bisect or to have a proper context on a blame.
I agree that you lose the benefit of a direct bisect but this is usually shrugged off with "you can go to the PR and inspect the commits one by one" which, while not ideal, is deemed a good tradeoff if you want your main branch to only contain big commits each laser-focused on one feature or bug.
As I replied to @SQLite above, I am not saying this is the optimal state of affairs -- not at all. But it's what is required everywhere I ever worked for 19.5 years (and similar output was desired when we worked with CVS and Subversion and it was harder to achieve there).
But I'll disagree this is lack of discipline. It's not that at all. It's a compromise between programmers, managers/supervisors, CTOs / directors of engineering, and release engineers. They want a bird's-eye view of the project in the main branch.
You can combine together theses classes in another class name for reusability. I've been doing CSS for 15 years and I love tailwind. It's just a bunch of handful predefined classes but they encourage you to write everything in small, single-purposed classes that you combine together.
You can absolutely do that with CSS (and some people probably did for years), but having theses classes already available kind of shows you the way.
How does a technology become mature if no one wants to test it? I get your point, but we need both type of people in the real world: cutting-edge tech enthusiasts and stable products users. The problem is not that some people try out some fancy new tool, it's that they try it at work and waste lots of money without even being worried about it because it's not theirs. But in few cases it also pays off.
Exactly. It would be amazing to have some of the many incredible UX/UI designers out there help with open source projects like these. So many potential adopters are lost just because of the interface, no matter how awesome the software is.
I feel like that’s the next step for open source, but it will take committed UX people who are also politic enough to sell developers doing things in their free time to use some more of that time to do things right.
> UX people who are also politic enough to sell developers
This, 100%. UX doesn't respect development because devs tend not to care about UX. Development doesn't respect UX because UXers tend not to care about development.
IMHO, devs tend to assume everyone is a programmer. And many people are very much not.
Which is why even graphical OSS tends to look and work like... git.
"People working on open source are hobbyists doing it their free time" is such a tired idea.
Here is a thought: do you want committed UX people working on open source? PAY THEM!
If every developer set aside a budget of 5-10% they spend on proprietary services to contribute to the funding of open source projects, there would be enough to attract hordes of UX professionals.
It amazes me how much of a premium people for, e.g, Apple products yet can not plan to spare 5-10 bucks a month to support R&D of open source.
I feel tempted to buy kleptosphere.com just to imagine someone's confusion the day they would want to buy it but get greeted with a "Sorry, this domain name is taken" instead.
What kind of ideas does sponsoring give you access to that you wouldn't get otherwise?