Sming projects/examples should be separate from libsming

AutomationD commented 9 years ago

This will be beneficial for referencing other projects from other repositories, as well as will help making every example an actual project.

As a mere of transition to it we can use submodules that will point to github/anakod/Basic_Blink (or better - github.com/sming/Basic_Blink)

kadamski commented 9 years ago

+1

matsstaff commented 9 years ago

This is something I would really like to see as well!

anakod commented 9 years ago

This is something I would really like to see as well!

How you want to organize it?

matsstaff commented 9 years ago

I would like to be able to have my own Sming project hosted on Github, with Sming (that is only 'core' Sming, not all the examples) as a submodule.

The way it is organized now, the 'projects' are it the top level of the Sming directory (yes, you could change this, and set SMING_HOME to something else, but it wouldn't follow the 'standard' then). I think that 'core' Sming should be a separate project, and that examples should live outside this. It is also confusing that, when cloning Sming, I get a directory called 'Sming' that holds everything and inside that there is another directory 'Sming' that actually is Sming.

So, I'd like to see Sming refactored to only hold the contents of SMING_HOME, and the examples moved to another (or separate) projects.

Edit: The 'Sming-examples' repo could then use Sming as a submodule, and presto, you have an example of how to include Sming as a submodule for you own project as well :)

Edit 2: Oh, and also, a big thanks for this effort! Sming makes getting started with ESP8266 development really quick! I also wish documentation will improve with time, but as I am able to read code, I can piece most of what I need together from the examples and reading the source. And choosing between improving code or improving documentation, improving code is more important. So again thanks and keep up the good work!

kadamski commented 9 years ago

I started writing my opinion on this but then @matsstaff wrote his which is exactly the same. Downside of having Sming as a submodule in examples is that the submodule SHA1 has to be updated as Sming is changed.

anakod commented 9 years ago

Big thanks for responses!

Sming makes getting started with ESP8266 development really quick! I also wish documentation will improve with time, but as I am able to read code, I can piece most of what I need together from the examples and reading the source. And choosing between improving code or improving documentation, improving code is more important.

@matsstaff may be you can help with documentation? Any kind of small additions to project Wiki will be great!

SHA1 submodule

May be it can be also added to core in main repository? Also, as I know Epsressif have implemented hashing algorithms in chip ROM (not relating to current topic question).

matsstaff commented 9 years ago

@anakod : I'd sure like to help, but I'm still learning this stuff myself. Also, I have a really limited amount of time to spare, and I'd like to put that into the (Sming based) project I'm working on. But if I feel I can (as in both have the time and knowledge) to contribute in some part of the documentation, then I will surely try!

Also, I think what @kadamski meant, was that if Sming-core was to be a submodule in a Sming-examples repo, then for every change to the Sming-core repo, the Sming-examples repo (or rahter the Sming-core submodule in that repo) would need to be updated (pull and push) to point to the 'new' version of the core. I'm not all that familiar with git, so I don't know if there is a better way to do this, but I would really like a better way to integrate Sming with my project and separating Sming core to its own repo and importing it as a submodule just seems like the right way.

raburton commented 9 years ago

Sound like reasonable suggestions. Move all the samples out to a separate repo under sminghub. Promote the contents of sming/sming up a directory to just sming.

I'm not entirely sold on submodules though. For the user it's not as easy for the user as just running git clone anymore, but it might be worth it. There are other external dependencies such as rBoot and spiffs that are currently embedded but could just be linked if we do want to go the the submodule route. It makes it clear where these come from, and they are more likely to get updated with new versions periodically (I intend to keep rBoot up to date, but no one is looking out for spiffs updates - I spent 3 hours last night fixing a bug which turned out to have been fixed already upstream, once I found where the upstream version was).

hreintke commented 9 years ago

@raburton : @kireevco : Like the examples, we also have to consider how we provide the libraries (and associated examples ?) I am not sure how well tested and supported the current libraries are. In my opinion there are two types of libraries 1/ Libs who are "part of sming core" -> fully integrated and supported by sming team. If dependencies exist between sming versions they are documented and solved. 2/ "addon libs" -> libs delivered and supported by "external developers" -> updates / release dependencies are handled by the original contributor. Maybe sming tests for for consistency in structure/api ? Examples for "core libs" should then be handled like above (or like now because the number will decrease). Examples for "addon libs" are part of the lib.

AutomationD commented 9 years ago

Let's revisit this, since we're succesfully moved to SmingHub group and ready to do this. I see two options here:

Each example under it's own repo, something like this:

SmingHub/Basic_rBoot
SmingHub/Basic_WiFi

Advantages

Separated from core (no need to update core when examples are updated / vice versa)
Nice way of templating: user can fork this example and build something based on it or ability to implement sming new Basic_WiFi
Conforms with git best practices - decoupled. No need to checkout huge repo when only one example needed (especially useful for binary distributed sming releases)

Disadvantages

You name it?

All examples are under: SmingHub/Examples

SmingHub/Examples/Basic_rBoot
SmingHub/Examples/Basic_WiFi

Advantages

Some level of separation from core,
Probably more convinient for some users to dig into all examples at once.

Disadvantages

You name it?

@anakod @raburton @robotiko @hreintke ?

hreintke commented 9 years ago

First step could be to get a better directory structure within the Sming Repo.

Sming
    Smingframework
    Examples (only Sming core examples)
Libraries
    ds1820
         ds1820 code
         ds1820 example
   .....

Or

Smingframework
Libaries
Examples (both smingcore & library examples)

Advantage Users do not have to change download procedure Visibility of Sming components PR's which hold code + example do not have to be split across multiple repo's Easy to implement ?

AutomationD commented 9 years ago

@hreintke moving directories sounds like an interim solution. It is definitely good for libraries and core decoupling. Although it won't solve many issues like changes in examples to go live depend on release now to get into master. Maybe examples don't even need release flow. Various project files changes go into core which is completely irrelevant.

Could you and others please share your opinion on the actual move of examples to another repo?

Sent from my iPhone

On Nov 15, 2015, at 2:02 PM, hreintke notifications@github.com wrote:

First step could be to get a better directory structure within the Sming Repo.

Sming Smingframework Examples (only Sming core examples) Libraries ds1820 ds1820 code ds1820 example ..... Or

Smingframework Libaries Examples (both smingcore & library examples) Advantage Users do not have to change download procedure Visibility of Sming components PR's which hold code + example do not have to be split across multiple repo's Easy to implement ?

— Reply to this email directly or view it on GitHub.

AutomationD commented 9 years ago

I agree. We should create another task about libraries.

Sent from my iPhone

On Oct 1, 2015, at 12:45 AM, hreintke notifications@github.com wrote:

@raburton : @kireevco : Like the examples, we also have to consider how we provide the libraries (and associated examples ?) I am not sure how well tested and supported the current libraries are. In my opinion there are two types of libraries 1/ Libs who are "part of sming core" -> fully integrated and supported by sming team. If dependencies exist between sming versions they are documented and solved. 2/ "addon libs" -> libs delivered and supported by "external developers" -> updates / release dependencies are handled by the original contributor. Maybe sming tests for for consistency in structure/api ? Examples for "core libs" should then be handled like above (or like now because the number will decrease). Examples for "addon libs" are part of the lib.

— Reply to this email directly or view it on GitHub.

raburton commented 8 years ago

I vote for just moving the samples to a subdirectory, I don't see a problem with shipping them with a release. That way they don't get left behind if things get changes in sming, they are more likely to get updated and continue to work with future sming updates. Why are libraries separate at all? Can;t they just be a standard part of sming?

AutomationD commented 8 years ago

@raburton One of the issues with libraries is licensing - sming is LGPL while some libraries are not. And some are not even open.

Another thing I want our community to do - is to be more active, examples and user projects is one way to achieve that. If examples would be easier to contribute to, and no core would break - why not do it? - Another way to do that without actually touching examples would be adding user projects under SmingHub org, this will allow sming to expose it's power to new users, and give more visibility and support for project maintainers.

Another thing with examples - I think they deserve to be more substential: a little bit more documentation, some schematic - how to connect things... This will be only available when people can contribute freely, without being afraid of screwing up the core.

I also want to see projects like _SmingHub/LED_WS2812Magic which gives you:

Links to equipment (aliexpress or similar)
Assembly instructions
Actual working and tested code
Video of everything working

This will give an opportunity for people to implement something real, not just a basic example blink. It could also mirror to instructables or other DIY HOWTO blogs to gain visibility over the world.

I know there are a lot of hackers here, and they have nice projects that they want to share, but it's almost impossible to get an overview of what people had done with Sming in their real life.

Bottom line, I'm trying to solve 2 things:

Licensing
Community engagement.

hreintke commented 8 years ago

@kireevco : If we want Community engagement the only way is : Keep it simple.

Conclusion here, reasoning below : Let's go for the suggestion of @raburton and me. -> Move examples to a directory. Quick and easy to do.

Complexity

If we move to more than one repository, both project maintainers and Community contributors face additional work.

Another thing with examples - I think they deserve to be more substential: a little bit more documentation, some schematic - how to connect things... This will be only available when people can contribute freely, without being afraid of screwing up the core.

Yes, we would like some more documentation. But I don't see why someone who adds just documentation would be afraid to screw up the core.

user projects is one way to achieve that

What is your idea on user projects ? Do you really think that people will copy their repo into sminghub and then keep that updated ? I do not. If we want to expose user projects we should give them a link on the wiki to their own location. (Or, but I know you don't want to use : A subforum on the esp8266 sming forum :smile: )

One of the issues with libraries is licensing - sming is LGPL while some libraries are not. And some are not even open.

One of the Sming team members has to merge the libraries into the repo. If we agree to only add libraries withe the right licensing we're done.

@raburton : On you question of libraries : I see a lot of discussion on quality of libraries and whether they "Arduino based" (loop driven) or "Sming based" (event driven). I was thinking on splitting those two types.

AutomationD commented 8 years ago

@hreintke what's the status of this? can we move all examples to Examples or examples?

raburton commented 8 years ago

Lets just move them all to a samples subfolder. We've discussed a lot and never done anything. We can improve on this later if we want but in the mean time just moving them to a sub folder is simple and much neater than the current.

AutomationD commented 8 years ago

@raburton I agree. Should we stick to Camel cased Samples?

raburton commented 8 years ago

My preference would be lower case, friendlier on the command line.

AutomationD commented 8 years ago

@raburton If that would be lower-case, then everything should be lowercase, like sming no?

raburton commented 8 years ago

I'd be in favour of that, but if we do go that way we don't have to do it all at once.

hreintke commented 8 years ago

@raburton @kireevco : From V2.0 release onwards I only committed PR's to solve bugs. Propose to get this out as a V2.1 bugfix release this week. Is the moving to samples directory : Just moving the files and as such easy to take in this V2.1 or does it involve more actions ?

SmingHub / Sming