Menu
▾
▴
configobj-develop
|
From: Jason B. <jb...@ze...> - 2010-03-04 15:49:38
|
Has anybody thought about switching ConfigObj to a DVCS? The main reason why I ask is because they make contributing to open source projects *so* much easier. Instead of making a patch, putting it in a ticket, and then having someone apply it, all you have to do is open a ticket saying "pull this commit from my repository" and then have the branch owner pull it. I personally am partial to git, but hg and bzr are both good choices (I believe Google Code has support for hg). |
|
From: Michael F. <fuz...@vo...> - 2010-03-04 15:52:40
|
On 04/03/2010 14:45, Jason Baker wrote: > Has anybody thought about switching ConfigObj to a DVCS? The main > reason why I ask is because they make contributing to open source > projects *so* much easier. Instead of making a patch, putting it in a > ticket, and then having someone apply it, all you have to do is open a > ticket saying "pull this commit from my repository" and then have the > branch owner pull it. > > I personally am partial to git, but hg and bzr are both good choices > (I believe Google Code has support for hg). Well, I'm a big fan of Hg (git not so much). I doubt I'll switch ConfigObj over in the forseeable future though, not unless / until there are more committers which doesn't seem immediately likely. Michael > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > > _______________________________________________ > Configobj-develop mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/configobj-develop > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. |
|
From: Jason B. <jb...@ze...> - 2010-03-04 16:00:00
|
On Thu, Mar 4, 2010 at 9:52 AM, Michael Foord <fuz...@vo...>wrote: > On 04/03/2010 14:45, Jason Baker wrote: > > Has anybody thought about switching ConfigObj to a DVCS? The main reason > why I ask is because they make contributing to open source projects *so* > much easier. Instead of making a patch, putting it in a ticket, and then > having someone apply it, all you have to do is open a ticket saying "pull > this commit from my repository" and then have the branch owner pull it. > > I personally am partial to git, but hg and bzr are both good choices (I > believe Google Code has support for hg). > > Well, I'm a big fan of Hg (git not so much). I doubt I'll switch ConfigObj > over in the forseeable future though, not unless / until there are more > committers which doesn't seem immediately likely. > I think this is a reasonable stand to take. But let me play devil's advocate. My point is that using a DVCS would make it easier for people to contribute. Isn't this kind of a chicken-and-the-egg type problem? After all, you want to get more people to contribute before moving to a DVCS, but moving to a DVCS is a good way to get more people to contribute. (I'm not trying to prod you into using a DVCS. I just want to make sure you've thought this out fully.) |
|
From: Michael F. <fuz...@vo...> - 2010-03-04 16:06:54
|
On 04/03/2010 15:59, Jason Baker wrote: > On Thu, Mar 4, 2010 at 9:52 AM, Michael Foord > <fuz...@vo... <mailto:fuz...@vo...>> wrote: > > On 04/03/2010 14:45, Jason Baker wrote: >> Has anybody thought about switching ConfigObj to a DVCS? The >> main reason why I ask is because they make contributing to open >> source projects *so* much easier. Instead of making a patch, >> putting it in a ticket, and then having someone apply it, all you >> have to do is open a ticket saying "pull this commit from my >> repository" and then have the branch owner pull it. >> >> I personally am partial to git, but hg and bzr are both good >> choices (I believe Google Code has support for hg). > Well, I'm a big fan of Hg (git not so much). I doubt I'll switch > ConfigObj over in the forseeable future though, not unless / until > there are more committers which doesn't seem immediately likely. > > > I think this is a reasonable stand to take. But let me play devil's > advocate. My point is that using a DVCS would make it easier for > people to contribute. Isn't this kind of a chicken-and-the-egg type > problem? After all, you want to get more people to contribute before > moving to a DVCS, but moving to a DVCS is a good way to get more > people to contribute. > > (I'm not trying to prod you into using a DVCS. I just want to make > sure you've thought this out fully.) Well - you can already use Hg to talk to svn, and generating a patch from a set of diffs is a single command. svn is *still* much more popular than DVCS (the gap is narrowing but svn has a big lead), so I think switching is actually likely to *reduce* the number of people able to contribute in the short term. Most of the patches that have ever been contributed to ConfigObj have required reworking (there are exceptions - the entire interpolation engine system was an outside contribution), so I'm not sure that the ability to pull is even that useful in *practise* (for configobj specifically - not as a general statement). It is also useful to have contributions tracked on the issue tracker as I deal with them sporadically. Centralised systems also have their advantages. :-) Michael > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > > _______________________________________________ > Configobj-develop mailing list > Con...@li... > https://lists.sourceforge.net/lists/listinfo/configobj-develop > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. |
|
From: Chris J. <cm...@te...> - 2010-03-04 17:00:13
|
Hi On 04/03/10 16:06, Michael Foord wrote: > Well - you can already use Hg to talk to svn, and generating a patch > from a set of diffs is a single command. As can bzr :D > specifically - not as a general statement). It is also useful to have > contributions tracked on the issue tracker as I deal with them > sporadically. Centralised systems also have their advantages. :-) For my personal projects I quite like that people can leave me a patch in a bug or push a branch to launchpad and send me a merge request. I also often rework their efforts, but I can do that on a copy of their branch and then merge it into my trunk and keep all that lovely history :) It's notionally a centralised system because I use launchpad as my development hub and access to trunk is quite limited, but other people are able to fork and collaborate easily in the same environment. (Disclaimer, I'm a sysadmin at Canonical, so I have corporate ties to both bzr and launchpad). Cheers, -- Chris Jones cm...@te... www.tenshu.net |
Thanks for helping keep SourceForge clean.
X