Transfer to new Arduino-CI organization

[ianfixes]

• Move repository to https://github.com/Arduino-CI
• Create snazzy icon
• Update all the documentation again so that the URLs are correct
• Possibly immediately fork back to personal account so I can point to the right repo.

[ianfixes]

I suppose a logo will be straightforward to design

[jgfoster]

I have some work on LiquidCrystal that I'd like to share. Do you want to create a Arduino-CI-Libraries organization and add a fork of LiquidCrystal so I can make a pull request? Or would you like me to take the initiative (I'm not trying to pass off the work to someone else, but I'm also trying not to push into an area where I'm still a novice!)?

[ianfixes]

This is in progress. I'm waiting for caching problems to finish (or whatever it is that keeps Travis CI from being able to see this new GitHub organization but not this repo within it), so that I can update all the URLs within the repo to point here.

Regarding the libraries, I'm going to try and set up a team here specifically to handle libraries, which will have separate permissions from the core repo. I also see that GitHub will allow us to create a "template" repository, and I'm wondering if that will be the end product for #150. But to answer your question: rather than an Arduino-CI-Libraries organization, it looks like we can set that up as a team within this organization. It's quite likely that I will learn more and have better ideas later about how to organize, so if this isn't perfect as-is then we'll adjust later.

[jgfoster]

Very good. When you have the library section (team?) ready, I'd like to have a fork of the following included (I'm willing to help but don't mind having others do it!):

• LiquidCrystal
• Keypad
• Adafruit_MAX31865
• Ethernet
• PID
• PID_AutoTune
• RTClib
• SD
• TimeLib

It appears that the following are not distributed as separate libraries but are built-in (is that correct?). If so, then to add tests we need to create a separate library (Can it have the same name? If not, just append "_Test"?) for the following:

• EEPROM
• SPI
• Wire

I have a model of what LiquidCrystal would look like here and a video describing the approach here. Over the next few weeks I will have students modifying the above libraries to work with Arduino CI and would like them to be able to submit PRs to a shared location. Thanks!

[ianfixes]

I sent you an invite for the organization, which should give you permission to create repositories there as you see fit. Note that rather than create repos, you can also transfer existing repos there (and optionally fork them back to your personal account).

I don't think it makes sense to fork repos into the Arduino-CI organization if you own them yourself but I'm curious to hear your thoughts.

[jgfoster]

Thanks. I will proceed to fork the pre-existing libraries and transfer my fork of LiquidCrystal (or recreate it). I agree that these repositories should be as close to the original as possible. I will fork LiquidCrystal again from here and then submit my changes just as everyone else would do.

[per1234]

It appears that the following are not distributed as separate libraries but are built-in (is that correct?).

These are platform bundled libraries. So a variant of each is bundled with every Arduino boards platform.

Here they are in the Arduino AVR Boards platform:
https://github.com/arduino/ArduinoCore-avr/tree/master/libraries

Here they are in the Arduino SAMD Boards platform:
https://github.com/arduino/ArduinoCore-samd/tree/master/libraries

... and so on. Note that the APIs are compatible, but the implementation is different for each microcontroller architecture.

If so, then to add tests we need to create a separate library

You could fork the whole boards platform repository if you like.

[ianfixes]

https://www.youtube.com/watch?v=BjmGOeGPDGw

If you end up submitting a pull request back to the LiquidCrystal maintainers with the changes you've created in this video, please link it here. I am very interested in joining that discussion.

[jgfoster]

I'll definitely submit this back and let you know. I'll probably wait a couple weeks to get it more complete (student submissions are already arriving) and try to polish it a bit. As you know, I'm new to Arduino development and to using your testing framework, so advice is welcome—especially as we move toward trying to influence those not already here. So, let me know your general thoughts or specific suggestions.

I suppose one of the first things I should do is add a GitHub action to show that the tests run!

[ianfixes]

I've turned on Issues for that repo https://github.com/Arduino-CI/LiquidCrystal/issues (which are disabled by default for forks). Hopefully this makes it easier to track feature development in preparation for submitting edits back to the original library.

[per1234]

It's not clear to me what the strategy is for pushing changes upstream.

It's best to submit multiple small, atomic PRs. A non-atomic mega-PR making a lot of unrelated or extensive changes is less likely to get a good reception. For example, a PR that only adds the license file would be a nice contribution. I recommend following Arduino's established conventions when possible. In the case of license files for libraries, Arduino uses the filename LICENSE.

My recommendation is to make a branch in the Arduino-CI/LiquidCrystal repository for each planned atomic change and then once the changes in that branch are in a polished state, submit a pull request from that branch. You can also merge those commits into a main branch that is intended to be used by users of the fork rather than for PRs.

There's a nice guide to contributing to Arduino projects here:
https://github.com/arduino/Arduino/blob/master/CONTRIBUTING.md

[jgfoster]

I agree with the general suggestion that small, focused, atomic, polished changes are more likely to be accepted on open-source projects. In this case, however, I don't see much point. Look at the existing pull requests for LiquidCrystal, including "a PR that only adds the license file" which has been languishing without attention since January 2018. This doesn't seem to be a project that is actively maintained. So, I think that our time is better invested in building a solid source of test-friendly libraries. It seems to me that the primary value of a pull request will be to document and explain an alternate approach in an environment where others might find our approach worth considering. Other libraries might be different, but (at the moment) I don't feel much inclined to expend my time making bite-size pieces for someone who has left the table.

[per1234]

including "a PR that only adds the license file"

Oops. Good catch!

You certainly have a valid point about Arduino not making as much of an effort to maintain that library as they might. Unfortunately, my assigned role in the firmware repositories is only to moderate the issue trackers, so I'm not in a position to merge that PR.

However, I would still urge you to focus on atomicity of the commits within the PR, as well as making the PR atomic, if perhaps not small. Even if it doesn't matter to Arduino, this makes the PR more valuable to the Arduino community. Adding a license and reformatting the readme have absolutely nothing to do with adding test capabilities, so they only create unnecessary "noise" in the diff, making it harder to understand the relevant changes that were made.

[ianfixes]

I suspect that we are really going to be locked in a chicken-and-egg problem here, where the only way to establish the worthiness of the changes we are proposing is to sell folks on the entire concept of unit testing.

This is why I think the video series is a more powerful way to work towards this goal than code alone. I'd like to work on building up the set of repositories here and learning what hurdles exist before spending too much effort trying to get the attention of upstream folks.

That said, if there are more upstream folks who have an interest in this project, I would welcome them into this GitHub org to run their own experiments.