search

alexa-pi / AlexaPiDEPRECATED

DEPRECATED - Use https://github.com/alexa-pi/AlexaPi instead ...Turn a Raspberry Pi into an Alexa Client
https://github.com/alexa-pi/AlexaPi
MIT License
587 stars 442 forks source link

1st attempt on a platform-shared code #125

Closed renekliment closed 8 years ago

renekliment commented 8 years ago

Hey! First, I wanna say, that I love the project! I'm excited about Alexa without spending the money for another device that I don't need and having the privacy under my control - recording truly only when I want it.

I've read in comments that you've been doing some code cleanup. However, I wanted to play around with it now on my desktop and I have some changes that I'd like to push upstream. If these are made obsolete by your changes, feel free to close and throw away this PR. If you'd like me to rework it, let me know!

Sorry for not doing this in atomic commits (will do it now if you like and in the future), I was just doing a quick and dirty fixes. What's in this:

  1. Directories!
  2. All config (except for Raspberry Pi config - will do that later) in a YAML configuration file so users can safely pull from the repo in order to get updates.
  3. Making the codebase common for all platforms and having the platforms as plugins. So we don't have to have AlexaPi, AlexaCHIP, AlexaOPi, ...

Please test on Raspberry Pi - I don't have one on me right now. I was forced to do these changes because I wanted to run in on my Arch Linux machine and it's important that developers can run this on their machines directly using for example the dummy platform. What would be coming next is merging other AlexaSTUFF projects by creating platform files for those and merging the actual projects.

Let me know what you think or if you have your own changes, please push them. Also, please keep the current stuff in master. I'm very confused by this version1.1 branch - it doesn't even look like it's got common history and

This branch is 17 commits ahead, 41 commits behind master.

looks like quite a mess.

renekliment commented 8 years ago

I've stumbled upon https://github.com/maso27/AlexaPi/ and other forks. Is this still developed? Do you guys want to negotiate some kind of merge? (feature-wise and platform wise) This is a mess! :-(

maso27 commented 8 years ago

That fork has seen quite a bit of development. I just added a new branch to it last week, trying out a more automated snowboy implementation. And yeah, I feel like there are probably features in there that could be useful to merge.

Sorry if it's a mess. It was my first time using github, and if you've got suggestions for a better way, I'm listening.

renekliment commented 8 years ago

Yes, I've seen some good work there - snowboy is an awesome thing to have :-)

I didn't mean to be rude. The current state is just very confusing for me and I think it makes it hard for the project to have efficient development. As a matter of fact, this PR is kind of a preview what I would like to do with the project for a start. If this were to be merged, I'd rewrite it so it's split into respective commits and it's not a half-done mashup of things.

I guess we have to wait for @sammachin what he has to say regarding this / his further progress and the code cleanup that he mentioned in a comment here on GH.

What I suggest:

  1. Choose one repo that is gonna be the upstream - if @sammachin wants to lead the development further / at least review & accept pull requests, let's choose his as upstream.
  2. For a start, let's have the master branch as the main development branch. We can have later some extra branch as dev, but I don't think that's necessary now.
  3. Don't do development in these versionX.Y branches - seriously. If one wants to develop a feature - create a feature branch forked from master and when done, do a PR against upstream master. That way, the latest code is always in master for anyone to base on.
  4. When the project leader decides there is enough features for a new version, he just makes a tag.

The point of this is that having these long-living branches that contain many new features in a various state of development prevents collaboration and is confusing and hard to merge eventually

What I would like for the project, as I have indicated in this PR, is to be multi-platform and to provide users with multiple choices for example for the trigger mechanism (snowboy, cmusphinx, button, ...) and prevent hard-coded things in general. The first stage is to have a modular code base and then we can rock & roll :-)

So, these are my thoughts :-) I'll be happy to help out with this in my free time, even though I don't have much of it nowadays.

sammachin commented 8 years ago

This is awesome!

It's pretty much exactly what I've been thinking and wanting to do I did make a start last week but other bits of life got in the way!

I completely agree that the current code base is a mess why started as a weekend hack project kind of took me by suprise in its popularity.

I've been thinking about how to manage the various options around triggering and indicators I'd welcome your thoughts on how to design a modular system for this.

We also need to consider how to make the project accessible to people that aren't developers I'm currently leaning towards offering a ready built RasPi image that could use a standard set of credentials so those that just want to get Alexa up and running have a quick route without having to do too much Linux tinkering.

I'd very much like to remain the 'lead' on the project if he have a more modular code base and can try to stick to Renés suggestions around development then it should be easier for me to maintain. I think most of the links and docs out there point to my repo anyway.

We could also look at creating a GitHub org for the project and make than the definitive repo, open to thoughts on this?

René what state is the code in this PR at? And what branch is it based on? I'm currently just looking on my phone so haven't had a proper look yet.

Thanks for this. Sam

On Monday, 5 September 2016, René Kliment notifications@github.com wrote:

Yes, I've seen some good work there - snowboy is an awesome thing to have :-)

I didn't mean to be rude. The current state is just very confusing for me and I think it makes it hard for the project to have efficient development. As a matter of fact, this PR is kind of a preview what I would like to do with the project for a start. If this were to be merged, I'd rewrite it so it's split into respective commits and it's not a half-done mashup of things.

I guess we have to wait for @sammachin https://github.com/sammachin what he has to say regarding this / his further progress and the code cleanup that he mentioned in a comment here on GH.

What I suggest:

  1. Choose one repo that is gonna be the upstream - if @sammachin https://github.com/sammachin wants to lead the development further / at least review & accept pull requests, let's choose his as upstream.
  2. For a start, let's have the master branch as the main development branch. We can have later some extra branch as dev, but I don't think that's necessary now.
  3. Don't do development in these versionX.Y branches - seriously. If one wants to develop a feature - create a feature branch forked from master and when done, do a PR against upstream master. That way, the latest code is always in master for anyone to base on.
  4. When the project leader decides there is enough features for a new version, he just makes a tag.

The point of this is that having these long-living branches that contain many new features in a various state of development prevents collaboration and is confusing and hard to merge eventually

What I would like for the project, as I have indicated in this PR, is to be multi-platform and to provide users with multiple choices for example for the trigger mechanism (snowboy, cmusphinx, button, ...) and prevent hard-coded things in general. The first stage is to have a modular code base and then we can rock & roll :-)

So, these are my thoughts :-) I'll be happy to help out with this in my free time, even though I don't have much of it nowadays.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sammachin/AlexaPi/pull/125#issuecomment-244806123, or mute the thread https://github.com/notifications/unsubscribe-auth/AALc_YW6pkEUU3_LWWH6b-4MpIo3-n84ks5qnHbFgaJpZM4J0aK- .

renekliment commented 8 years ago

Cool!

To be honest, this PR is more of a sketch. I did this in a hurry to make it work on my desktop. I'll close this once we agree on the further development and I'll make it the right way.

I suggest:

  1. @sammachin Throw away the version1.0 branch (as there is no point for it IMHO) - tag the respective commit in master as v1.0.
  2. version1.1 branch was created in a weird way, because it doesn't share history with master - it probably wasn't based on it - that's why git/GH gives me This branch is 17 commits ahead, 41 commits behind master. To get a common ground, merge version1.1 into master and delete version1.1. maso27's branch snowboy or version1.2 into master and delete branch version1.1. Now we have up-to-date master and no other branch and the work can begin. Tell me if you need help with this.
  3. I'll separate the code into directories as in this PR.
  4. I'll split it into platform files as in this PR. We can develop this on our desktop machines now - yay!
  5. Merge AlexaCHIP and AlexaOPi - should be easy - just making the small platform files for now. Would need testing though. Then, those repos can be deleted / emptied with link to this one / redirected to this one with instructions.
  6. We can talk about configuration - YAML would be cool - as suggested in this PR, but I'd probably enhance it a bit.
  7. Give users possibility to choose the trigger - now we have platform-specific (like a button on a RasPi here) and @maso27 has implemented snowboy and cmusphinx if I'm correct. Let's have code for everything and let it be an option. In this stage, @maso27 would refactor his code for this new code base (not necessarily all alone).

I would expect we would have some discussion on each thing to think about it and design it right.

We can always do organization repo later - let's clean up first. Also, if you mean SD card images, we can talk about that later. I personally think that simple and short instructions on how to run this on a standard Raspbian would be enough so people can integrate this into their existing systems, but that's a discussion for later :-)

Let me know what you think @sammachin and @maso27 . I'll create a meta bug for this structure change once we agree on the process and start sending PRs for this for review.

Thanks!

renekliment commented 8 years ago

Ah, silly me! Looking at @maso27's branches, it would probably make sense to merge his work first and then do the structural changes, so it's not a nightmare for him and it actually makes sense. Although branch version1.2 seems messed up a bit - GH gives me This branch is 52 commits ahead, 41 commits behind sammachin:master. - what is it based on? The version1.1 seems like it could be merged into @sammachin's version1.1 now.

EDIT: I see the history now (thanks git gui) - I would have thought that version1.2 would be based on version1.1. I am for merging the branch snowboy into master, if maso27 is happy with it's state. That would partially replace the second step.

maso27 commented 8 years ago

Yeah, version 1.2 was where things diverged significantly. That was the whole reason I bumped the number.

I tried to write it into the readme's, but I pulled some things in from Nascent Objects and added other things: -silence detection rather than timer for voice-activated listening. -volume control. -better tune-in support. -always-on monitoring. (Done via a separate script-- I now believe it's too heavy-handed and unnecessary)

As for the snowboy branch: that is still pretty untested. It worked fine for me with a fresh install last week but might be worth getting a little more mileage before doing anything rash.

Hopefully that's helpful? I'm just futzing with things until they seem to work. Still pretty amateur at the python thing.

renekliment commented 8 years ago

Okay. Let's merge your version1.2 into master then. Hopefully you can refactor the whole snowboy into the new code structure later?

EDIT: Let me guys know if you agree with the scenario above (point 2 being the merging of version1.2).

GemBro commented 8 years ago

FINALLY!!! ... I'm glad to hear this ... I bailed out a while back as it got too much of a mess ... and (tbh) I got lost with all the branches, routes and versions, etc ... don't think I was the only one ...

I'm totally in agreement of all the above ... this is a fantastic project but it needs to be reasonably simple for the newer folk coming aboard ... it needs to flurish and with everyone who has made major changes & additions, to the AlexaPi project, coming together it will be awesome ...

So yeah dump all the old versions and concentrate on (as Sam says) one definitve version for all ... this should involve an initial clean vanilla install of the Pi files and its setup ... it will cut down on "I can't get it to work" comments, as we'll all be in the same boat and the issues 'should' then be the same for everyone(?) ... it also needs a decent 'How To' and/or 'Installation' write up as well ...

I miss messing with this project and after telling a few mates to try it out it, it got difficult for them as well, as they are not developers ... if it can be simple to setup (ideally a one off Setup package or modules) then more will join in ... most can do simple Nano editing but not much more where adding repos and stuff ... basically what Sam, renekliment and maso27 has said above really ...

Keeping an eye on this bigtime ...

cheers, Gem

maso27 commented 8 years ago

@renekliment I'm cool with that. Once there's an established framework I'm happy seeing what it takes to refactor snowboy. (Or anyone else if you want to, of course!)

Also, I'm excited about this getting commonized, as you were saying. I've got an arch linux box that I got AlexaPi running on eventually, but it took a bit of shoehorning, and is still kinda crashy.

Plus, I got my pre-ordered C.H.I.P. processors recently and having an easy and reproducible path to get the latest onto one of those would be awesome!

renekliment commented 8 years ago

So I've made a quick attempt at merging version1.2 into master to make a PR and it's not easy, because they don't have a common history. (this is a reminder to never do anything like this again) So I figure we have these options:

  1. Manually resolve merge conflicts.
  2. Create some other branch - let's call it dev, pull version1.2 into it, rename master to something else like original, rename dev to master with the process being a little less straightforward I guess in reality.
  3. Create a completely new repo (can be an organization repo like @sammachin pointed out) with its master branch having the content of version1.2. We could choose a new name for the project, since it would support more platforms than just Pi SBCs, but I guess we can always rename it later, so no actual need to decide it now.

Everything with the full history of version1.2 of course! So what do you guys think is the best option? I'd probably go for 3, as it is the easiest one.

sammachin commented 8 years ago

So I'm going to setup an organisation on github and we can then have multiple repos in that if we need to.

Name wise I'd like to keep AlexaPi for the project as; Its quite short/easy to remember, Thats whats got most of the publicity/traction so far. I know one of the aims is to have a single codebase that supports multiple boards in the future but I don't think thats too much of an issue if the name has 'Pi' in it. RasPi is still the most well known board out there.

So I'll call the org alexapi (can't have that as someone has that username, for now I've gone for alexa-pi, might see if the guy will give us alexapi as he doesn't seem to be using it.)

@renekliment do you want to start a fresh repo in that org based on whatever code base you feel is best, I havn't had much of a look at @maso27's 1.2 but I know that snowboy takes a fair bit of setup so I think we might be better starting from 1.1 with just the button triggering and working from there.

renekliment commented 8 years ago

Awesome, thank you!

Actually, snowboy support is in the snowboy branch, so we can do version1.2 as master safely. I'll create a repo and start some work on it tomorrow evening. I'll keep you guys posted. Thanks again!

sammachin commented 8 years ago

I've reached out to the person that has the alexapi username to see if he'd be willing to give it up, for now were' on github.com/alexa-pi but I'm not too keen I'd like to change.

Other possible name I thought of was 'MyAlexa' but I'm not sure I like that, I should probabbly run it by Amazon too as we don't want to upset them for using the Alexa trademark

On Wed, Sep 7, 2016 at 11:13 AM, René Kliment notifications@github.com wrote:

Closed #125 https://github.com/sammachin/AlexaPi/pull/125.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sammachin/AlexaPi/pull/125#event-780689403, or mute the thread https://github.com/notifications/unsubscribe-auth/AALc_Y8Rqz-qqAyygwx943106rFxYwSVks5qno4vgaJpZM4J0aK- .

renekliment commented 7 years ago

@sammachin @maso27 I've created the repo, but please don't touch it yet in any way. I'll have some notes and PRs coming later today.

renekliment commented 7 years ago

So, it's time to move the discussion here: https://github.com/alexa-pi/AlexaPi/issues/2 I'll soon start pushing PRs there. Important notes: