You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Referring to a comment on a pull request: #30 (comment)
While I do see the value in people being able to share their configs by submitting PRs, I think there are more drawbacks than benefits. The biggest of which is that maintaining the configs that are part of the repo could become a hassle. Suppose a config parameter is deprecated, or ends up being used for another feature, or really any breaking change at all. The options are to leave broken configs in the repo, remove them entirely, or maintain them indefinitely. If there are a few common build configs that are distributed with the repo, then updating them makes sense. But the idea of maintaining possibly hundreds of configs sounds like a quality control nightmare.
I like having the config directory ignored by version control so that as I switch between branches I don't have to be dealing with my personal, uncommitted configs. I can also pull and merge from upstream a lot easier.
It's also nicer to be able to have the commit log unpolluted by changes to individuals configs.
I believe you mentioned wanting to be able to include images with configs, and I think thats a great idea too. The idea of a browsable collection of builds with configs that can be easily modified is awesome. But in my mind at least, that's a separate repo from the one that is used to actually generate the keyboards. Perhaps a submodule?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Referring to a comment on a pull request: #30 (comment)
While I do see the value in people being able to share their configs by submitting PRs, I think there are more drawbacks than benefits. The biggest of which is that maintaining the configs that are part of the repo could become a hassle. Suppose a config parameter is deprecated, or ends up being used for another feature, or really any breaking change at all. The options are to leave broken configs in the repo, remove them entirely, or maintain them indefinitely. If there are a few common build configs that are distributed with the repo, then updating them makes sense. But the idea of maintaining possibly hundreds of configs sounds like a quality control nightmare.
I like having the config directory ignored by version control so that as I switch between branches I don't have to be dealing with my personal, uncommitted configs. I can also pull and merge from upstream a lot easier.
It's also nicer to be able to have the commit log unpolluted by changes to individuals configs.
I believe you mentioned wanting to be able to include images with configs, and I think thats a great idea too. The idea of a browsable collection of builds with configs that can be easily modified is awesome. But in my mind at least, that's a separate repo from the one that is used to actually generate the keyboards. Perhaps a submodule?
Beta Was this translation helpful? Give feedback.
All reactions