39 Matching Annotations
  1. Sep 2023
  2. Nov 2022
  3. Aug 2022
    1. I don't understand the hesitation here to accept a really useful addition to rspec. Maintenance burden. Forseen internal changes required to do it. Unforseen internal changes required to do it. Formatter changes to handle new output status for a spec that passed and failed It's simply not a previously design use case of RSpec. It will be hacky to implement.
    2. We already have a very wide configuration API. The further we expand it the more unwieldy it becomes for users. At this point we generally require new features to be implemented first as extension gems, and then to see support, before considering including them in core.
  4. Mar 2022
  5. Sep 2021
    1. The number of complaints across the issue tracker and the lack of substantive followup on many of those complaints should be ample evidence that these frustrated users exist and are likely about to leave Fenix behind in droves, if they haven't already.
  6. Jun 2021
    1. Users who have installed it decided to trust me, and I'm not comfortable transferring that trust to someone else on their behalf. However, if you'd like to fork it, feel free.

      Interesting decision... Seems like the project could have been handed off to new maintainers instead of just a dead-end abandoned project and little chance of anyone using it for new projects now.

      Sure you can fork it, but without a clear indication of which of the many forks in the network graph to trust, I doubt few will take the (massively) extra time to evaluate all options and choose an existing fork as a "leader" (or create their own fork) to go with continuing maintenance...

  7. Apr 2021
  8. Mar 2021
  9. Feb 2021
  10. Jan 2021
    1. Maintaining open source software requires energy and a "want"/"passion". I've not been using this project myself for years, and I mainly work in other things than Rails at this point. That means I'm far removed from this project and see no personal gain in maintaining the energy to keep this going.
    2. I'm still pretty proud of the project and I don't want to see it gone, so I want to keep updating it when needed. But on the other hand, the feature set is pretty stable and well working now (AFAIK) so I also don't see the need to pretend to be actively maintaining it.
    3. Please: Prompt me when things break and I will probably fix it. I won't guarantee how fast I'll move, but I'll try to make the effort sometimes. The bigger the issue, the more likely it is that I'll do something about it.
    4. It's not impossible, but it's not likely I would accept someone I haven't worked with IRL or know on a personal level. That's because I want some form of creative control over the direction and I want to maintain the existing code style. If I know you I'm more likely to know that this will keep working the way I want it to.
    5. a triager would be very welcome; someone that can ask follow-up questions on issues, create test cases for the problems, and so on.
    6. Show me good PRs, bug triaging, documentation fixes, whatever and you're a candidate if you ask for it.
  11. Nov 2020
    1. I hope @hperrin you're still alive to discuss about this and eventually for a pull request.
    2. Preview/beta release (I wish @hperrin allows it to pull request it here)
    3. @monkeythedev I am curious how do you "organize" your work - You forked https://github.com/hperrin/svelte-material-ui and https://github.com/hperrin/svelte-material-ui is not very active. Do you plan an independent project ? I hope the original author would return at some times, if not, i'll see
    4. I agree, it would be great to join forces and speed up development... Svelte really needs one safe material library option.
    5. Maybe @hperrin would be able to make an appearance and select a few additional maintainers to help out.
  12. Oct 2020
  13. Aug 2020
    1. The collection of changes to fix the issues we want to address would be probably of the same size, but it would make easier to review and merge if we could break this PR in many steps. I find it really hard to believe we need to change 170 lines in a single commit to be able to fix this issue. We probably could break the first commit in many commits, test the class better and that would give more confidence over what is being changed. Right now I see a huge diff, with a few assertions changes and no real reason why all those lines had to change.
    2. We've stated what's required multiple times now: #14540 (comment) #14540 (comment), and the follow up arguments weren't convincing. Follow Rafael's advice in new smaller PRs to advance this or it'll simply stay closed
  14. Jul 2020
  15. Apr 2020
    1. Becouse of CanCan, StateMachine and others I deside to create OpenSource organization to maintain gems. People disappear, lose their passion about coding, get new interests, families, children. But if us many we can support gems much longer. I dont pretend to be an expierenced ruby developer, but I can do administarative work: managing teams, members, approve simple pool-requests. If you think it good idea and want to support some inactive gems, not life time, maybe just a little - welcome to organization.
    2. There's actually discussion among the rubygems team about a process for putting gems "up for adoption" that you might be interested in: http://www.benjaminfleischer.com/2014/08/17/rubygems-adoption-center/
    1. So what will happen with these projects from now on? All of the projects above have one thing in common: they were created and maintained by passionate individuals who wanted to make positive contributions to their communities. Without these individuals and their efforts, these projects would not have become what they are today. Therefore, it is only fair that Plataformatec gives these individuals control of these projects moving forward.