35 Matching Annotations
  1. Jun 2021
  2. May 2021
  3. 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.
  4. Feb 2021
  5. 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.
  6. Dec 2020
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. Jul 2020
  12. May 2020
  13. Jan 2020
  14. Nov 2019