Skip to contentSkip to conversation

New home for i2c-tools (RFC)

DISCUSSION Jean Delvare 5 participants 10 messages Jan 29, 2009 7 messages not in the archive I2C subsystem host drivers

lore
Share & tools
lore
#0 lore raw

Hi all,

I am in the process of moving i2c-tools away from lm-sensors.org to a new home. My reasons for doing this are:
* The i2c tools are useful way beyond lm-sensors, and on the other hand lm-sensors works fine on many recent systems without I2C support at all. There has been a lot of confusion about i2c and lm-sensors in the past and I hope that moving i2c-tools somewhere else will help put an end to it.
* Administration of lm-sensors.org isn't always as good as I would like. I am not blaming our host, we get everything for free and it isn't that bad, but apparently our admin is busy with more important things so I don't want to put additional load on him.
* I hope that a clean, simple, standalone project will more easily attract extra developers.

Now the question is: where do we go? At first I had considered Savannah [1], essentially because I have other projects hosted there. One problem though is that they are rather strict when it comes to licenses. In particular, GPL v2 only code isn't good enough for them, while one piece of i2c-tools is released under that license.

[1] https://savannah.nongnu.org/

An alternative I have considered since then is to put the code on kernel.org. After all, i2c-tools are tightly linked to the Linux kernel at the moment.

There are pros and cons both ways. At Savannah we'd have a Subversion tree, which is what we already have for i2c-tools at the moment so importing the code should be easy. Creating accounts for extra contributors is easy. We get a bug tracking system and web space.

At kernel.org, we would have a git tree. More powerful than Subversion, but also a little more complicated, and we probably don't need that much power for such a small project. I'm not sure how easy it is to import a Subversion repository into a git tree. No bug tracking system. No accounts for contributors. The web pages would probably go in i2c.wiki.kernel.org. Might become a little confusing if i2c-tools ever supports another OS than Linux.

And there are other options available, such as Gna! or BerliOS. Never used these myself though.

[2] https://gna.org/
[3] http://developer.berlios.de/

As far as I am concerned, I can live with all options, but what I really want to know is: which option would potential future contributors prefer? Please speak up if you care!

Thanks,

Signature · 1 line
Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw

Hi Jean,

(oops, dropped the CCs accidently on the first try)

Quoted 5 lines

[3] http://developer.berlios.de/

As far as I am concerned, I can live with all options, but what I really want to know is: which option would potential future contributors prefer? Please speak up if you care!

Berlios works for me, it hosts the C64-related projects I am doing with some friends. SVN, Bugtracker, Mailinglists work as one would expect... SocketCAN is also hosted there.

I just had a glimpse, they seem to accept all OSI-approved licenses, so no problem with that. Looks they also offer git now, if that change would ever be needed ;)

I think it would be a reasonable choice, sounds at least better to me than the scenarios you sketched.

Regards,

Wolfram

Signature · 2 lines
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
#3 lore raw
In reply to a message not in the archive
Quoted 9 lines · On Thursday 29 January 2009 04:37:17 Jean Delvare wrote:

And there are other options available, such as Gna! or BerliOS. Never used these myself though.

[2] https://gna.org/
[3] http://developer.berlios.de/

As far as I am concerned, I can live with all options, but what I really want to know is: which option would potential future contributors prefer? Please speak up if you care!

any reason for not looking at sf.net ? they provide svn and everything else needed ... they dont provide git currently though so an easy upgrade path like is available with berlios is out of the question.

a quick survey based on packages in gentoo shows sf.net is significantly more popular atm than berlios and gna (combined even).

but yes, i could live with any of those sites ...
-mike

A message that is not in the archive (sent off-list or not yet received): 200901291056.12963.vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org

#5 lore raw
Quoted 3 lines · On Thursday 29 January 2009 04:37:17 Jean Delvare wrote:

As far as I am concerned, I can live with all options, but what I really want to know is: which option would potential future contributors prefer? Please speak up if you care!

I can live with almost anything! :)

-------------------------------------------------------------------------

|   Paul Goyette   | PGP DSS Key fingerprint: |  E-mail addresses:      |
| Customer Service | FA29 0E3B 35AF E8AE 6651 |  paul at whooppee.com   |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
|                  |                          | pgoyette at netbsd.org  |

-------------------------------------------------------------------------

#6 lore raw
In reply to a message not in the archive

Hi Mike,

Quoted 7 lines · Mike Frysinger
Quoted 6 lines · On Thursday 29 January 2009 04:37:17 Jean Delvare wrote:

And there are other options available, such as Gna! or BerliOS. Never used these myself though.

[2] https://gna.org/
[3] http://developer.berlios.de/

Quoted 7 lines
Quoted 3 lines

As far as I am concerned, I can live with all options, but what I really want to know is: which option would potential future contributors prefer? Please speak up if you care!

any reason for not looking at sf.net ? they provide svn and everything else needed ... they dont provide git currently though so an easy upgrade path like is available with berlios is out of the question.

Sourceforge is fat and slow and their mailing lists are filled up with spam. I have had too much trouble with that site as a user in the past so I did not even consider it as an option as a developer.

Quoted 2 lines

a quick survey based on packages in gentoo shows sf.net is significantly more popular atm than berlios and gna (combined even).

I'm not surprised, Sourceforge is really big. Probably berlios is essentially popular in Germany and gna essentially popular in France.

Quoted 1 line

but yes, i could live with any of those sites ...

Thanks,

Signature · 1 line
Jean Delvare

A message that is not in the archive (sent off-list or not yet received): [email protected]

#8 lore raw
Quoted 2 lines

Sourceforge is fat and slow and their mailing lists are filled up with

It is slow at times and even had annoying downtimes. Let's just hope the alternatives won't grow that big ;)

Wolfram

Signature · 2 lines
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry

A message that is not in the archive (sent off-list or not yet received): [email protected]

#10 lore raw
Quoted 5 lines · Wolfram Sang
Quoted 2 lines

Sourceforge is fat and slow and their mailing lists are filled up with

It is slow at times and even had annoying downtimes. Let's just hope the alternatives won't grow that big ;)

A git tree at kernel.org and a mailing list at vger.kernel.org works well. You could have separate branches in the master git tree and automatically fetch other people's branches in to that with minor scripting.

Also there's almost zero spam on the vger lists and no subscription is necessary.

Just my 2c worth,

Tony

A message that is not in the archive (sent off-list or not yet received): [email protected]

#12 lore raw
Quoted 10 lines · On Thursday 29 January 2009 11:38:46 Tony Lindgren wrote:
Quoted 4 lines · Wolfram Sang
Quoted 1 line

Sourceforge is fat and slow and their mailing lists are filled up with

It is slow at times and even had annoying downtimes. Let's just hope the alternatives won't grow that big ;)

A git tree at kernel.org and a mailing list at vger.kernel.org works well. You could have separate branches in the master git tree and automatically fetch other people's branches in to that with minor scripting.

but no tracker system. any package that wants to integrate/work with downstream distros needs a tracker. things get lost on mailing lists. -mike

A message that is not in the archive (sent off-list or not yet received): 200901291148.06805.vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org

#14 lore raw
Quoted 7 lines · Mike Frysinger
Quoted 6 lines · On Thursday 29 January 2009 11:38:46 Tony Lindgren wrote:
Quoted 4 lines · Wolfram Sang
Quoted 1 line

Sourceforge is fat and slow and their mailing lists are filled up with

It is slow at times and even had annoying downtimes. Let's just hope the alternatives won't grow that big ;)

Quoted 7 lines
Quoted 4 lines

A git tree at kernel.org and a mailing list at vger.kernel.org works well. You could have separate branches in the master git tree and automatically fetch other people's branches in to that with minor scripting.

but no tracker system. any package that wants to integrate/work with downstream distros needs a tracker. things get lost on mailing lists.

Maybe patchwork + bugzilla could do the job?

http://patchwork.kernel.org/

Tony

A message that is not in the archive (sent off-list or not yet received): [email protected]

#16 lore raw
Quoted 14 lines · On Thursday 29 January 2009 11:56:15 Tony Lindgren wrote:
Quoted 13 lines · Mike Frysinger
Quoted 11 lines · On Thursday 29 January 2009 11:38:46 Tony Lindgren wrote:
Quoted 5 lines · Wolfram Sang
Quoted 2 lines

Sourceforge is fat and slow and their mailing lists are filled up with

It is slow at times and even had annoying downtimes. Let's just hope the alternatives won't grow that big ;)

A git tree at kernel.org and a mailing list at vger.kernel.org works well. You could have separate branches in the master git tree and automatically fetch other people's branches in to that with minor scripting.

Quoted 6 lines
Quoted 2 lines

but no tracker system. any package that wants to integrate/work with downstream distros needs a tracker. things get lost on mailing lists.

Maybe patchwork + bugzilla could do the job?

http://patchwork.kernel.org/

if we're looking to bring more people into the process and lower the bar for entry, i think patchwork is taking that in very much the opposite direction -mike