41 Matching Annotations
  1. Nov 2022
  2. Jul 2022
    1. Stop autoclosing of PRs While the idea of cleaning up the the PRs list by nudging reviewers with the stale message and closing PRs that didn't got a review in time cloud work for the maintainers, in practice it discourages contributors to submit contributions. Keeping PRs open and not providing feedback also doesn't help with contributors motivation, so while I'm disabling this feature of the bot we still need to come up with a process that will help us to keep the number of PRs in check, but celebrate the work contributors already did instead of ignoring it, or dismissing in the form of a "stale" alerts, and automatically closing PRs.

      Yes!! Thank you!!

      typo: cloud work -> could work

  3. Jan 2022
    1. So, for authorization I use the 403 Forbidden response. It’s permanent, it’s tied to my application logic, and it’s a more concrete response than a 401. Receiving a 403 response is the server telling you, “I’m sorry. I know who you are–I believe who you say you are–but you just don’t have permission to access this resource. Maybe if you ask the system administrator nicely, you’ll get permission. But please don’t bother me again until your predicament changes.”
  4. Sep 2021
    1. I have never seen the @Stale bot or any directly equivalent to it achieve a net positive outcome. Never. It results in disgruntled people, extra expenditure of effort (for reporters and maintainers), real stuff getting lost when people get fed up with poking the bot (I have no intention of poking it further), and more extensive filing of duplicates. You say a simple comment dismisses it, but it doesn’t—it only does this time. Next time, it continues to annoy. This is an issue tracker. Use labels, projects, milestones and the likes for prioritising stuff. Not sweeping stuff under the carpet.
    2. Closing issues doesn’t solve anything. Closing issues in GitHub just sweeps them under the carpet and helps everyone to forget about them, which is just not what you want—the fact that GitHub search excludes closed items by default is a large part of the problem with it. As applied to software projects with general-purpose issue trackers, the @Stale bot is fundamentally phenomenally bad idea, a road paved with good intentions. I presented an actionable alternative: labels. Possibly automatically applied, but it’s certainly better to spend a little bit of time on manual triage. It honestly doesn’t take long to skim through a few hundred issues and bin them into labels. 609 open issues? That’s honestly not a problem. Not at all. There’s nothing wrong with having a large number of issues open, if they do correspond to real things—even things that you may not expect to get to for years, if ever, because that might change or someone might decide they want to deal with one. Closing issues that aren’t dealt with is bad. Please don’t do it.
  5. Jun 2021
  6. May 2021
  7. Mar 2021
    1. Sorry you’re surprised. Issues are filed at about a rate of 1 per day against GLib. Merge requests at a rate of about 1 per 2 days. Each issue or merge request takes a minimum of about 30 minutes (across at least 2 people) to analyse, put together a fix, test it, review it, fix it, review it and merge it. I’d estimate the average is closer to 3 hours than 30 minutes. Even at the fastest rate, it would take 3 working months to clear the backlog of ~1000 issues. I get a small proportion of my working time to spend on GLib (not full time).
    1. here is my set of best practices.I review libraries before adding them to my project. This involves skimming the code or reading it in its entirety if short, skimming the list of its dependencies, and making some quality judgements on liveliness, reliability, and maintainability in case I need to fix things myself. Note that length isn't a factor on its own, but may figure into some of these other estimates. I have on occasion pasted short modules directly into my code because I didn't think their recursive dependencies were justified.I then pin the library version and all of its dependencies with npm-shrinkwrap.Periodically, or when I need specific changes, I use npm-check to review updates. Here, I actually do look at all the changes since my pinned version, through a combination of change and commit logs. I make the call on whether the fixes and improvements outweigh the risk of updating; usually the changes are trivial and the answer is yes, so I update, shrinkwrap, skim the diff, done.I prefer not to pull in dependencies at deploy time, since I don't need the headache of github or npm being down when I need to deploy, and production machines may not have external internet access, let alone toolchains for compiling binary modules. Npm-pack followed by npm-install of the tarball is your friend here, and gets you pretty close to 100% reproducible deploys and rollbacks.This list intentionally has lots of judgement calls and few absolute rules. I don't follow all of them for all of my projects, but it is what I would consider a reasonable process for things that matter.
  8. Feb 2021
  9. Jan 2021
    1. Just saying “snaps are slow” is not helpful to anyone. Because frankly, they’re not. Some might be, but others aren’t. Using blanket statements which are wildly inaccurate will not help your argument. Bring data to the discussion, not hearsay or hyperbole.
  10. Dec 2020
  11. Nov 2020
    1. Don't you hate to repeat yourself? For example, I hate working on anything related to user authentication or authorization that isn't directly related to the system I'm working on. I see it as necessary evil, an accidental complexity.
  12. Oct 2020
    1. One of Svelte's advantages, for me, is that I can test out ideas with relatively few lines of code. the #with feature could save me from adding a separate component for the content of an #each loop. I get frustrated when I have to create a new file, move the content of the #each clause, import it as a component, and add attributes and create exports for that, and implement events to send messages back, and event handlers, when I just wanted to test a small feature.
  13. Sep 2020
    1. Most simple example: <script> import ChildComponent from './Child.svelte'; </script> <style> .class-to-add { background-color: tomato; } </style> <ChildComponent class="class-to-add" /> ...compiles to CSS without the class-to-add declaration, as svelte currently does not recognize the class name as being used. I'd expect class-to-add is bundled with all nested style declarations class-to-add is passed to ChildComponent as class-to-add svelte-HASH This looks like a bug / missing feature to me.
    1. feel like there needs to be an easy way to style sub-components without their cooperation
    2. The problem with working around the current limitations of Svelte style (:global, svelte:head, external styles or various wild card selectors) is that the API is uglier, bigger, harder to explain AND it loses one of the best features of Svelte IMO - contextual style encapsulation. I can understand that CSS classes are a bit uncontrollable, but this type of blocking will just push developers to work around it and create worse solutions.
  14. Aug 2020
    1. Stallman has also stated that considering the practical advantages of free software is like considering the practical advantages of not being handcuffed, in that it is not necessary for an individual to consider practical reasons in order to realize that being handcuffed is undesirable in itself.
  15. Jul 2020
  16. May 2020
  17. Jan 2020
  18. Nov 2019