-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kinto.sh github organization? #677
Comments
Accidentally posted prematurely just now. I’m interested but not sure of the legalities of setting up an org just for these projects & related efforts. I also have sorun.me but it might be covering too much. We could model it after Buddies of Budgie or Lucee I imagine, but I think it’d be good if we discussed this more in a chat of some kind real time or video chat. You can DM me on Twitter, gbit86, initially & I can give you better contact info from there. I would be very happy to have 2, 3 or more maintainers involved w/ Kinto though & xkeysnail. I’ll be busy tomorrow but late Sunday or any time Monday onward will be fine. |
I'm not talking any legal entities or corporations... just a github organization - anyone can make them... I'll reach out. |
How would you all feel about the name If we're going to hard fork it (vs the author showing up and passing on maintainership) I think we need a new name... |
Even if the creator appears, I see no reason not to change the name and start a new repository. Even because at some point it is very likely that the project needs to support Wayland, and Regarding the name |
Yeah, I had thought of that... but still if the author showed up and could transfer everything over [all the github issues, etc] (vs us setting things up from scratch)... that'd be a good reason to leave the name alone (for at least a bit)... get out a new release or two first... I really don't think support Weyland is that hard JUST you need a library/way to ask it what the current application is... that's not our job... weyland needs to expose that - we're just a consumer... and then we need to clean up our internal API just a bit so that we seamlessly work with X or Weyland (wrapping them both in a nice abstraction).
I don't really care for that much. sorry. Omnikey is cool but already a thing. Evidentally "keysie" is a brand name for a keyring opener or something.... |
Yes, it shouldn't be too complex to include Wayland and it shouldn't be feasible to mess with it now, as not every distro uses it. Regarding the name, it's secondarily per hour. Well, for now, we can continue in a fork, if the project changes a lot and progresses a lot, maybe it's a good idea to disconnect from the original repository. |
We need a new name to release a new python library, assuming we're starting on our own. |
So a name will be needed, even if temporary, xkeysnail-neo should do for now, what do you think? |
Nice, but I'd hate to change the name twice. What about |
@rbreaves I'm making really good progress on my fork. How would you feel if (in a few more days after I'm a bit further) I start mentioning it here on a some of the issues where it seems most relevant (might offer a fix, etc)...? I've been pretty active over on xkeysnail, but there really isn't anyone there to bother (other than users whose problems I might be resolving)... I don't want you to think I'm spamming your project's issues. :-) @luizoti I decided to go with Some of those additional things (process management) do seem useful, but I'm not certain that they aren't better handled by systemd (which should be more than capable of single process handling) or a tiny bash script, etc... so I'm hesitant to add them until exploring the other avenues first. Features are often much easier to add than they are to remove. (once one person decides a feature is indispensable) If you'd like to discuss any individual patches you think I should have a closer look at please open an issue on my fork. |
Well, I already imagined that this would happen, but I decided to see how far it would go. Most of the changes I made didn't directly touch the core of the original project, so the changes you made 2 or 5 days ago (maybe) would fit there, and the rest I would have no problem revising and/or removing. I have no plans to discuss it individually because you already reviewed my PR and decided not to use it, so I won't waste time 2x opening an issue in a discussion that has already occurred. I don't use the original version today because it always had limitations that I fixed in my fork, one of them was the need for external means to run xkeysnail (bash script) and the fact that the hot-plug doesn't work and of course, my control just doesn't was detected, etc., etc. For now, I'm not excited to collaborate anymore, I'll wait and if it works for me, I should use it, keep up the work. |
Most of my big changes has been this weekend and I've changed quite a bit I think (or it sure feels like it). The input system is almost entirely new, running on
But that's part of the problem - is I don't think the discussion has taken place (for many of these items). You had issues, you fixed them to your liking. That's awesome... but is the fix correct for everyone? Does it have side effects? Is there a much better/cleaner solution? Those are the questions I'm used to being able to ask/research/etc when reviewing PRs, etc... so after much lot of thought I decided to start from the "stable" base that most users would already be running, 0.4.0...
Sorry if I made you unexcited, that certainly wasn't my goal. What I mean what I said "open an issue" wasn't for you to just create 100 issues, but rather if you thought a few things you did were super important/relevant I'd be happy for you to direct my focus to just a few rather than my trying to look over all 100+, etc... it's really hard when you have a branch diverge so much and no maintainer to provide thoughts/comments... that's where the other person was coming from when they [a bit rudely] said "why would anyone merge this" or something like that...
I think the "best way" to run the mapper is still an open question... In my README so far I imagine people might want to run it as themselves (via I'll have to glance at your script again to see what it does... (I was mostly looking at the python code changes)
That part of the code has been largely rewritten in my fork but I only had a mouse to play around with. If it doesn't work I'm definitely interested in knowing how/why and fixing it. Hot plug is something that should definitely "just work".
I went a simpler direction with the detection... if a device has A-Z and QWERTY keys, lets call it a keyboard... I think that should auto-detect all actual keyboards... (but if I'm wrong, happy to have another look)
I plan to have it more stable in a few days... I'll definitely ping you if you want to give it a shot then. |
Perhaps part of this discussion would be where to put things that might "live outside" Kinto but still be of super interest to kinto users... you've said you aren't interested in "outside config"... I just added a I can see why we don't want to manage/ship 100 different config files for software, but perhaps we could use the Wiki for things like this? "User contributed per software config" and any tips of how to make the experience of using ANY software with Kinto (making it more mac like)... anything that couldn't make it into Kinto proper could perhaps have a place to live on the Wiki. |
Any thoughts on making this an organization - then our reboot of xkeysnail could live there as well... going thru the whole "we lost the maintainer and now no one can do anything, so we have to create an organization the hard way" with Base 16 colors right now... and since we're looking for a new home for xkeysnail anyways seemed like a reasonable idea... and making a whole org just for just that single project seems a bit overkill to me...
Thoughts?
The text was updated successfully, but these errors were encountered: