Request for Comments on a common repo for software

Archive
1

Gary, Gus, I, and others have been in discussions for a longish while on how to release a bunch of software, some of which I and others did as open source, and some that I did at the request of and through the generous support of GHI. We’ve settled on opening up a new GitHub organization, which will be found under OpenDeviceHub · GitHub

But I would like comments and input from the community on the following points, before I push the first commits:

I want to create one repo for each major architecture/OS combination. That is, one for NETMF and Gadgeteer, one for Llilum, one for the new linux devices, one for RPi/WIn and one for RPi/Linux.

Each repo would have two or more administrators (in addition to the org admin(s)) who are able to accept pull requests. They would be subject-matter experts with the ability to build and nominally test contributions (hardware availability notwithstanding). [Please feel free to volunteer]

Within each repo, there will be some standards for the format of contributions. That is, they would have to fit within a specific file layout and the entire repo would build from a common build infrastructure. Repo admins would create and adjust those standards on a per-repo basis.

Post-build creation of packaging technologies (nuget, npm, apt-get) would be encouraged, and the repo admins would push out ‘official’ releases under the name OpenDeviceHub.

Each repo would be covered in its entirety by an Apache 2.0 license. Authors retain their own copyrights (OpenDeviceHub is not a legal entity and cannot own a copyright). Contributors might be asked to assert that they created or otherwise own the rights to contributions they are making.

The goal is to expose maximum functionality, at high quality, with a permissive license, to the broadest possible audience in an environment of collaboration and respect.

Did I forget anything? Comments? Suggestions?

7 Likes
2

Feel free to suggest a logo too, because it ain’t real until we print the t-shirts…

1 Like
3

Well maybe one little thing… Maybe a short explaination of what OpenDeviceHub is? :slight_smile:

4

@ ianlee74 - Just a github org name for a common place to put open-source small-device software that a) does something useful and b) is reasonably assured to build and run

Think of it as a github repo for codeshare-like stuff. A place to find drivers and such.

It is NOT a company or legal entity, or anything like that - just a name for “place we get stuff”.

5

Oh, I see. So, its not really a project per se but just another place to put drivers, snippets, etc.

1 Like
6

@ ianlee74 - I get the feeling that the stuff going into these repositories already exists. They’re not adding another codeshare (we have one too many already), they’re releasing a bunch of stuff that they’ve been producing. That’s what I read.

1 Like
7

Yes, there’s already content ready to go, and the detail they’re looking to gain from this discussion is how that single repo will look to the outside world, so that it can continue to be used for other code over time and still respect the same code licensing and logical order/structure

1 Like
8

…but with administration so ensure that the code is curated.

I volunteer hardware to test and be an admin for things that I know. At least this will give me an excuse to buy a RPI3 :slight_smile:

2 Likes
9

Ok the Rpi3 and BBB are on the way. This means I can test on Rpi2, Rpi3, BBB and G120. Do we also need to do Intel Edision?

10

Sounds like you are using this as an excuse to buy hardware. Good man.

Actually, any platform you want to include is good by me. The idea here is just to provide a well-known location for good-quality reusable code relevant to the kinds of things we all do for fun and/or profit.

1 Like
11

I’ll be happy to assist with any COBOL projects that arise.

2 Likes
12

@ mcalsyn - I think this is great. Not sure it’s possible to make that size of umbrella though? Would it make sense to be less visionary but keeping the initial direction?

Furthermore, I am surprised about the lack of applause from this community???

1 Like
13

I suspect that others are struggling a bit as I am with understanding how this will fit into the ecosystem. I’m hoping this is going to be one of those things I “get” once I see it. Right now it sounds a bit like “one repo to rule them all” which is not the way I usually like to roll. But mcalsyn is definitely a smarter guy than me and I have confidence it’ll make sense once I know more.

14

Definitely not one repo to rule them all, but there are lots of very useful bits of driver and library code floating around out there and it would be nice to get some critical mass of it in one spot. You always have the option of making your own repos (as I have done with numerous projects), but it can be hard to find that one driver you need if you don’t know the url or project name or whatever.

There will also be some advantages to having a repo that is known to build and receives some level of maintenance and ongoing love.

So, if you wrote a driver for something useful, you can either issue a pull request, or just email it to one of the admins and on a time-available basis, we’ll get it integrated in the repo.

This is kind of an extension to codeshare, but not a replacement. This is more appropriate to slightly larger and more involved bits of code, but the motivation is the same as codeshare - useful, contributed code, in a well-known location.

15

OK, it seems I’ve misunderstood what’s going on. I definitely can’t support this plan. If I produce a bit of code, driver, etc, then I will want to control the repository that it’s in. There is absolutely zero benefit to joining my code into someone else’s unrelated code in a single repository, and then having to spend time and effort managing my repository through them.

Codeshare is a bad thing (in its current form), it should go away (or be replaced with a tool that works alongside source control systems). It definitely does NOT need an extension. GitHub gives you everything you need to be successful, and does it with standard tools that are well-adopted in the industry (and supported with excellent tooling right in Visual Studio).

16

@ godefroi - Definitely appreciate the input, and yes, I expect that this isn’t for everyone. I respect that you have projects and repos that you want to maintain, manage and publicize separately, and that’s great. That doesn’t mean this is a bad idea - it just doesn’t fit your needs. There are other folks who may want to make a one-off contribution of code that they wish to see maintained by the community, and this would fit that well.

So, if you have a project you want to manage and maintain, then by all means, keep it in a repo you own.
However, if you want to contribute code for community use AND community maintenance, and don’t feel a need to take on the administration overhead, then I think the OpenSourceHub collection of repos is a reasonable way to do it.

As for Codeshare, I agree. A modern evolution of that should probably involve no code storage - just forum-like references to repos (on multiple providers) that support a richer model of issue tracking, pull requests and the like.

17

@ godefroi - No, the git hub is for when you want to contribute your code into a repository. E.g. the driver for the Wiznet w5500. This is for things that are just too big for code share. I have a 4K line project I may want to share; to allow the devices to parse the html from websites that don’t have apis, so you can get their data and interface with them (e.g. the status info for my wifi router).

1 Like
18

@ Mr. John Smith - Agree, but I think beyond size, it is also for stuff that people want to contribute to community use and (more importantly) community maintenance, rather than bearing that burden themselves or seeing the code suffer bit-rot for lack of attention.

19

@ mcalsyn - If community maintenance is the goal, then a common repository isn’t going to achieve it. It’s almost certainly easier to fork a repository that has one project in it and make a change than to fork a big repository that has a lot of projects going in possibly different directions.

When “bit-rot” happens, it isn’t because there is only one project in the repository; it’s because nobody can be bothered to keep the code current.

20

While I tend to operate as @ godefroi described (in my 5 years here I’ve never made a Codeshare contribution…), I do understand the need that this is trying to fill and I do think its worthwhile. This makes sense as a replacement for the code storage functionality of Codeshare. However, due to the latency of pulling in contributions I don’t think that Codeshare can go away. So, does it make sense that Codeshare basically become a queue for this new repo?

What Codeshare should be is an index of available code that users can search. Then that Codeshare entry should point to:
[ol]OpenDeviceHub repo source
Other user’s repo source
Codeshare code[/ol]
So, then the Git ignorant can still make contributions w/o making a pull request and those that want to maintain their own repos can do so but still have their code in the index. The admins of OpenDeviceHub would need the ability to migrate code from Codeshare to Git and remove the old code from Codeshare.

Does this make sense?

1 Like