From: M. B. Al-N. <ad...@mb...> - 2010-06-15 08:35:44
|
Hi folks, Lately sf.net forbids many open source projects although most these projects are not owned by sourceforge, so I(we) suffer a lot because of their racism policy (They said they've to apply the law but this isn't full truth) so I encourage MinGW admin to migrate this project from sf.net to another open source hosting which real free, real applying FOSS principles, or at least allow me(us) to download MinGW by activating related tick from MinGW admin webpage... for more information read the following please: http://arabcrunch.com/2010/01/following-clintons-internet-freedom-speech-us-based-sourceforge-blocked-syria-sudan-iran-korea-cuba-is-open-source-still-really-open.html http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/ -- Best Regards Muhammad Bashir Al-Noimi My Blog: http://mbnoimi.net |
From: Volker G. <vo...@no...> - 2010-06-15 08:45:55
|
M. Bashir Al-Noimi <ad...@mb...> schrieb: > Lately sf.net forbids many open source projects although most these projects > are not owned by sourceforge, so I(we) suffer a lot because of their racism > policy (They said they've to apply the law but this isn't full truth) so I > encourage MinGW admin to migrate this project from sf.net to another open > source hosting which real free, real applying FOSS principles, or at least > allow me(us) to download MinGW by activating related tick from MinGW admin > webpage... I propose to switch to Savannah or Gna! which are hosted by the FSF resp. FSF France, so it is guaranteed they fully adhere to the principles of Free Software. My Mingw-cross-env project [1] is hosted on Savannah, which I can highly recommend. There was some small initial trouble, but since then everything was running flawlessly. Greets, Volker [1] http://mingw-cross-env.nongnu.org/ -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR |
From: Ben R. <Ben...@sc...> - 2010-06-15 09:27:40
|
>I propose to switch to Savannah or Gna! which are hosted by the FSF resp. > FSF France, so it is guaranteed they fully adhere to the principles of Free Software. This issue has not been explained in enough detail that I really understand what it is, however I believe Savannah is not an option because, taken from the Savannah home page, - We host free projects that run on free operating systems and without any proprietary software dependencies MinGW, by definition, does not run on a free operating system. Gna! Has similar (although not the same) terms in their constituation. SciSys UK Limited. Registered in England and Wales No. 4373530. Registered Office: Methuen Park, Chippenham, Wiltshire SN14 0GB, UK. * Before printing, please think about the environment. |
From: Volker G. <vo...@no...> - 2010-06-15 10:37:15
|
Ben Ross <Ben...@sc...> schrieb: > >I propose to switch to Savannah or Gna! which are hosted by the FSF > > resp. FSF France, so it is guaranteed they fully adhere to the > > principles of Free Software. [...] > however I believe Savannah is not an option because, taken from the > Savannah home page, > > - We host free projects that run on free operating systems and without > any proprietary software dependencies > > MinGW, by definition, does not run on a free operating system. They accepted my Mingw-cross-env project which is based on MinGW, so I don't think they'll refuse MinGW. It's definitely worth a try! Also, I do think that MinGW runs on free operating systems, for the following reasons: 1) MinGW can be used as a cross compiler, allowing developers to build the win32 port of their software without actually touching a Windows or any other proprietary OS. 2) MinGW creates binaries that usually run under Wine, thus running on many free operating systems using free software only. > Gna! Has similar > (although not the same) terms in their constituation. I don't think they'll have a problem with hosting MinGW, either. Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR |
From: Erwin W. <wat...@xs...> - 2010-06-15 10:38:33
|
Op 15-06-10 11:27, Ben Ross schreef: >> I propose to switch to Savannah or Gna! which are hosted by the FSF >> > resp. > >> FSF France, so it is guaranteed they fully adhere to the principles of >> > Free Software. > > This issue has not been explained in enough detail that I really > understand what it is, > however I believe Savannah is not an option because, taken from the > Savannah home page, > > - We host free projects that run on free operating systems and without > any proprietary software dependencies > > MinGW, by definition, does not run on a free operating system. Gna! Has > similar > (although not the same) terms in their constituation. > > If you can run MinGW/MSYS on ReactOS (http://www.reactos.org/) this objection is not valid any more. ReactOS is a free (GPL), NT binary compatible OS. (I never tried it). Erwin |
From: M. B. Al-N. <ad...@mb...> - 2010-06-15 08:55:49
|
On Tue, Jun 15, 2010 at 11:45 AM, Volker Grabsch <vo...@no...>wrote: > M. Bashir Al-Noimi <ad...@mb...> schrieb: > > Lately sf.net forbids many open source projects although most these > projects > > are not owned by sourceforge, so I(we) suffer a lot because of their > racism > > policy (They said they've to apply the law but this isn't full truth) so > I > > encourage MinGW admin to migrate this project from sf.net to another > open > > source hosting which real free, real applying FOSS principles, or at > least > > allow me(us) to download MinGW by activating related tick from MinGW > admin > > webpage... > > I propose to switch to Savannah or Gna! which are hosted by the FSF resp. > FSF France, so it is guaranteed they fully adhere to the principles of > Free Software. > > My Mingw-cross-env project [1] is hosted on Savannah, which I can highly > recommend. There was some small initial trouble, but since then everything > was running flawlessly. > BerliOS <http://developer.berlios.de/> is a clone from sf.net because it uses same applications with same structure. and there is Launchpad<https://launchpad.net/>it's very easy but it's using bzr instead of SVN/CVS Personally I prefer to test BerliOS <http://developer.berlios.de/> because migration process will not take more than 1 day, then you can make MinGW project at sf.net works as a mirror from BerliOS<http://developer.berlios.de/> -- Best Regards Muhammad Bashir Al-Noimi My Blog: http://mbnoimi.net |
From: Stefano S. <ste...@po...> - 2010-06-15 09:24:24
|
On date Tuesday 2010-06-15 11:55:41 +0300, M. Bashir Al-Noimi wrote: > On Tue, Jun 15, 2010 at 11:45 AM, Volker Grabsch <vo...@no...>wrote: > > > M. Bashir Al-Noimi <ad...@mb...> schrieb: > > > Lately sf.net forbids many open source projects although most these > > projects > > > are not owned by sourceforge, so I(we) suffer a lot because of their > > racism > > > policy (They said they've to apply the law but this isn't full truth) so > > I > > > encourage MinGW admin to migrate this project from sf.net to another > > open > > > source hosting which real free, real applying FOSS principles, or at > > least > > > allow me(us) to download MinGW by activating related tick from MinGW > > admin > > > webpage... > > > > I propose to switch to Savannah or Gna! which are hosted by the FSF resp. > > FSF France, so it is guaranteed they fully adhere to the principles of > > Free Software. > > > > My Mingw-cross-env project [1] is hosted on Savannah, which I can highly > > recommend. There was some small initial trouble, but since then everything > > was running flawlessly. > > > > BerliOS <http://developer.berlios.de/> is a clone from sf.net because it > uses same applications with same structure. and there is > Launchpad<https://launchpad.net/>it's very easy but it's using bzr > instead of SVN/CVS > > Personally I prefer to test BerliOS <http://developer.berlios.de/> because > migration process will not take more than 1 day, then you can make MinGW > project at sf.net works as a mirror from BerliOS<http://developer.berlios.de/> That would be also a good pretest to make MinGW switch to some more modern SCCS ;-). And I agree, FLOSS projects should strive hard to be available to every people with no national / geographic discrimination, making this depends on US laws doesn't guarantee that this goal can be effectively achieved. Regards. |
From: Lars U. <lar...@dl...> - 2010-06-15 09:05:10
|
Muhammad, M. Bashir Al-Noimi wrote: > so I encourage MinGW admin to migrate this project from sf.net > to another open source hosting which real free, Thank you for bringing this to attention, I wasn't aware of this until just now. This is taking internet localization one step further (and the last steps were already too far) I FULLY SUPPORT THIS NOTION! If we ignore censorship like that, it will be the end of many open source projects. Best Regards, Lars -- Dipl.-Ing. Lars Uffmann Microgravity User Support Center (MUSC) Deutsches Zentrum für Luft- und Raumfahrt e.V. Linder Höhe D-51147 Köln phone: +49 (0)2203 601 2171 http://www.dlr.de/musc |
From: LRN <lr...@gm...> - 2010-06-15 10:24:14
|
On 15.06.2010 13:06, Lars Uffmann wrote: > Muhammad, > > M. Bashir Al-Noimi wrote: > >> so I encourage MinGW admin to migrate this project from sf.net >> to another open source hosting which real free, >> > Thank you for bringing this to attention, I wasn't aware of this until > just now. This is taking internet localization one step further (and the > last steps were already too far) > > I FULLY SUPPORT THIS NOTION! If we ignore censorship like that, it will > be the end of many open source projects. > > Best Regards, > > Lars > > Not sure about censorship, but sf's experiments with page layouts and methods to access the files hosted didn't make the experience the most easiest one to developers, as far as i know. So switching to different host might be a good idea. I wish i knew other good free software hosts besides the ones already mentioned, but i don't. |
From: Tor L. <tm...@ik...> - 2010-06-15 09:40:47
|
> I FULLY SUPPORT THIS NOTION! If we ignore censorship like that, it will > be the end of many open source projects. Film at 11. --tml |
From: Lars U. <lar...@dl...> - 2010-06-15 10:07:29
|
Tor Lillqvist wrote: > Film at 11. Honestly, this is the wrong place and time for attempts at being funny. -- Dipl.-Ing. Lars Uffmann Microgravity User Support Center (MUSC) Deutsches Zentrum für Luft- und Raumfahrt e.V. Linder Höhe D-51147 Köln phone: +49 (0)2203 601 2171 http://www.dlr.de/musc |
From: Earnie <ea...@us...> - 2010-06-15 16:55:21
|
M. Bashir Al-Noimi wrote: > Hi folks, > > Lately sf.net <http://sf.net> forbids many open source projects although > most these projects are not owned by sourceforge, so I(we) suffer a lot > because of their racism policy (They said they've to apply the law but > this isn't full truth) so I encourage MinGW admin to migrate this > project from sf.net <http://sf.net> to another open source hosting which > real free, real applying FOSS principles, or at least allow me(us) to > download MinGW by activating related tick from MinGW admin webpage... > for more information read the following please: > > http://arabcrunch.com/2010/01/following-clintons-internet-freedom-speech-us-based-sourceforge-blocked-syria-sudan-iran-korea-cuba-is-open-source-still-really-open.html > http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ > http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/ > 1) SourceForge is a United States of America company and must follow United States of America laws including sanctions placed on corporations toward delivery of product to certain other countries. 2) We are not moving to another VCS other than CVS for the sake of just moving. We will continue to use CVS until we are forced by SF itself to move to a different VCS. 3) We will continue to put up with SourceForge and its changes to their UI since moving to another site would just mean more work than any of the contributors want to give. -- Earnie -- http://www.for-my-kids.com |
From: Mauricio G. <mgp...@gm...> - 2010-06-15 17:30:34
|
Right now, SF has put the liability risk to the project owners / admins. It is up to them to flag the product as exportable or not. Please see http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/ I am no law expert but I think if there are contributors from other countries and in addition to this considering that mingw is not a commercial product I would guess the restriction do not apply. But again, it is not my neck on the line. M. Bashir Al-Noimi, I understand you are angry (and rightly so in my opinion) but I think if your request was in the line of "Could you please set the flag in your project so that we can continue to access mingw" it would be more productive. Calling racists people who provide good free services and that are under law restrictions is not productive and a little harsh in my opinion. I know this is not the forum for political discussions but I could not resist ... If you allow me I would like to recommend the following book: http://www.amazon.com/All-Shahs-Men-American-Middle/dp/0471265179 Best regards, Mau. 2010/6/15 Earnie <ea...@us...>: > M. Bashir Al-Noimi wrote: >> Hi folks, >> >> Lately sf.net <http://sf.net> forbids many open source projects although >> most these projects are not owned by sourceforge, so I(we) suffer a lot >> because of their racism policy (They said they've to apply the law but >> this isn't full truth) so I encourage MinGW admin to migrate this >> project from sf.net <http://sf.net> to another open source hosting which >> real free, real applying FOSS principles, or at least allow me(us) to >> download MinGW by activating related tick from MinGW admin webpage... >> for more information read the following please: >> >> http://arabcrunch.com/2010/01/following-clintons-internet-freedom-speech-us-based-sourceforge-blocked-syria-sudan-iran-korea-cuba-is-open-source-still-really-open.html >> http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ >> http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/ >> > > 1) SourceForge is a United States of America company and must follow > United States of America laws including sanctions placed on corporations > toward delivery of product to certain other countries. > > 2) We are not moving to another VCS other than CVS for the sake of just > moving. We will continue to use CVS until we are forced by SF itself to > move to a different VCS. > > 3) We will continue to put up with SourceForge and its changes to their > UI since moving to another site would just mean more work than any of > the contributors want to give. > > -- > Earnie > -- http://www.for-my-kids.com > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- Mauricio Gomes Pensar Digital 55-11-9698-1683 (Brazil - mobile) |
From: M. B. Al-N. <ad...@mb...> - 2010-06-15 19:12:11
Attachments:
admin.vcf
|
On 15/06/2010 07:30 م, Mauricio Gomes wrote: > Right now, SF has put the liability risk to the project owners / admins. > It is up to them to flag the product as exportable or not. > > Please see http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/ > > I am no law expert but I think if there are contributors from other > countries and in addition to this considering that mingw is not a > commercial product I would guess the restriction do not apply. But > again, it is not my neck on the line. > > M. Bashir Al-Noimi, I understand you are angry (and rightly so in my > opinion) but I think if your request was in the line of "Could you > please set the flag in your project so that we can continue to access > mingw" it would be more productive. You think that so, sf.net have thousands of projects that means we've to send thousands of messages to tell projects admins for this problem.. do you think this is practical procedure? All what I understand open source must be opened not forbids! > Calling racists people who provide > good free services and that are under law restrictions is not > productive and a little harsh in my opinion. > If you read the link provided before you'll find that sf.net didn't hear from us until some big projects warning them and promised that if they didn't find a solution they will move at once. but sf.net was clever and found an evil solution by putting forbidding tick. in this way they absorbed the storm quietly although the problem didn't fixed at all. > I know this is not the forum for political discussions but I could not > resist ... If you allow me I would like to recommend the following > book: > http://www.amazon.com/All-Shahs-Men-American-Middle/dp/0471265179 > This is real situation don't mix it with political propaganda, forbidding policy strike the sole of open source licenses. It's huge problem with simple solution, but nobody in sf.net really want to fix. > Best regards, > Mau. > > 2010/6/15 Earnie<ea...@us...>: > >> M. Bashir Al-Noimi wrote: >> >>> Hi folks, >>> >>> Lately sf.net<http://sf.net> forbids many open source projects although >>> most these projects are not owned by sourceforge, so I(we) suffer a lot >>> because of their racism policy (They said they've to apply the law but >>> this isn't full truth) so I encourage MinGW admin to migrate this >>> project from sf.net<http://sf.net> to another open source hosting which >>> real free, real applying FOSS principles, or at least allow me(us) to >>> download MinGW by activating related tick from MinGW admin webpage... >>> for more information read the following please: >>> >>> http://arabcrunch.com/2010/01/following-clintons-internet-freedom-speech-us-based-sourceforge-blocked-syria-sudan-iran-korea-cuba-is-open-source-still-really-open.html >>> http://sourceforge.net/blog/clarifying-sourceforgenets-denial-of-site-access-for-certain-persons-in-accordance-with-us-law/ >>> http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blocking/ >>> >>> >> 1) SourceForge is a United States of America company and must follow >> United States of America laws including sanctions placed on corporations >> toward delivery of product to certain other countries. >> >> 2) We are not moving to another VCS other than CVS for the sake of just >> moving. We will continue to use CVS until we are forced by SF itself to >> move to a different VCS. >> >> 3) We will continue to put up with SourceForge and its changes to their >> UI since moving to another site would just mean more work than any of >> the contributors want to give. >> >> -- Best Regards Muhammad Bashir Al-Noimi My Blog: http://mbnoimi.net |
From: Conan K. (ニール・ゴ. <ngo...@gm...> - 2010-06-16 03:11:38
|
Okay people. Mr. Al-Noimi is understandably upset about being blocked from SourceForge because he lives in a country on the embargoed countries list. However, that doesn't mean we need to move from SourceForge. We have plenty of space and resources on MinGW.org to run a mirror of the source tree, or at least provide mirrors of the release tarballs. So, why not do that? If you want to mirror the CVS on MinGW.org or move it to MinGW.org (meh, CVS is blech), that could be done too. It is just a matter of getting somebody willing to set up the mirroring information. It isn't even extremely difficult to mirror the CVS repository and SourceForge repository. Mirroring the SourceForge releases would take a lot of time, but it could easily be done. And some automation could be done to speed things up too. We could migrate from CVS to SVN or Mercurial or something at the same time. I've got experience with Mercurial, and some with Subversion. But I don't think we should abandon SourceForge. |
From: M. B. Al-N. <ad...@mb...> - 2010-06-16 07:57:11
Attachments:
admin.vcf
|
On 16/06/2010 05:11 ص, Conan Kudo (ニール・ゴンパ) wrote: > Okay people. Mr. Al-Noimi is understandably upset about being blocked > from SourceForge because he lives in a country on the embargoed > countries list. However, that doesn't mean we need to move from > SourceForge. Actually I can't understand why you don't want to understand ! Is mingw open source project or not? how you can block open source project? how you can find this situation is right? mingw or any open source project owned by maintainers and contributers not by hosting service! I think this is clear enough to understand. -- Best Regards Muhammad Bashir Al-Noimi My Blog: http://mbnoimi.net |
From: Mauricio G. <mgp...@gm...> - 2010-06-16 14:29:14
|
I have followed this thread but something is not clear to me. What is the position of the projects admins on the export option setting ? Have you guys decided what to do ? Best regards, Mau. |
From: Mauricio G. <mgp...@gm...> - 2010-06-16 15:23:34
|
Hi Earnie, After your post I checked my project and you are right, the text in the export control only says about encryption ( I reproduce the text at the end of this message for the readers convenience and reference). I used the first option in mine. I guess this is the one but the text needs to be fixed otherwise it just refers to encryption. In this case, until they do change the language you can safely set the first option (if I am not mistaken about encryption in mingw). Best regards, Mau. # Export Controls: This project does NOT incorporate, access, call upon, or otherwise use encryption of any kind, including, but not limited to, open source algorithms and/or calls to encryption in the operating system or underlying platform. This project DOES incorporate, access, call upon or otherwise use encryption. Posting of open source encryption is controlled under U.S. Export Control Classification Number "ECCN" 5D002 and must be simultaneously reported by email to the U.S. government. You are responsible for submitting this email report to the U.S. government in accordance with procedures described in: http://www.bis.doc.gov/encryption/PubAvailEncSourceCodeNotify.html and Section 740.13(e) of the Export Administration Regulations ("EAR") 15 C.F.R. Parts 730-772. 2010/6/16 Earnie <ea...@us...>: > My position is, not all contributors nor admins are US Citizens and > therefore the project cannot abide solely on US law. But, because some > contributors and admins are US Citizens a mix of country laws are in > play. Countries have reasons for laws and as good citizens we must > abide by those laws as best we can. Do I agree with all the laws, no, > of course not, but I must live in the country of my choosing so > therefore I must abide by its laws. > > -- > Earnie > -- http://www.for-my-kids.com > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > -- Mau |
From: Charles W. <cwi...@us...> - 2010-06-17 01:49:18
|
On 6/15/2010 12:55 PM, Earnie wrote: > 2) We are not moving to another VCS other than CVS for the sake of just > moving. We will continue to use CVS until we are forced by SF itself to > move to a different VCS. It seems idea of "switch to another VCS" gets mentioned about once a month. Most recently, somebody suggested that MinGW/MSYS would somehow magically obtain more developers if we stopped using the most widely deployed VCS system in history other than the filing cabinet, and started using something else (subversion, I think). In addition to the effort involved, for very little gain, there's one (additional) problem with switching VCS implementations: we don't provide any *clients* for VCS implementations other than cvs. If we were to switch to hg, we'd have to provide not only an msys-hg, but also msys-python (and all of ITS dependencies). msys-svn would require msys-neon, msys-apr, msys-libserf, msys-libproxy, and msys-sqlite, msys-berkdb, and msys-sasl. The simplest alternative VCS is msys-git, since the MSYS Phoenix project already has a port, but we'd need to validate and package it for mingw-get; it also requires a more recent perl than we currently provide... All that effort...for what, exactly? True, cvs is ancient and not very flexible. It doesn't follow the latest Distributed VCS fad. It works poorly with renames and directories and binary files. This matters...why? Does the MinGW/MSYS project REALLY push the capabilities of its own repo that hard? No. Of course, there are arguments for providing clients of other VCS's so that people who use MinGW/MSYS can interact with other projects using those VCS tools. But that's not an argument for switching MSYS's OWN VCS. So...if somebody really wanted to encourage MinGW/MSYS to "switch", they need to do a couple of things: 1) port the appropriate client to MSYS, and package it appropriately for mingw-get -- including all necessary dependencies. 2) Get that uploaded and accepted as an official tool, distributed by mingw.org as part of the standard toolkit. This would probably involve committing to provide end-user support FOR that tool, on this list. 3) Come up with a rationale for how switching from CVS to 'whatever' for the MinGW/MSYS repository would actually benefit the development of MinGW/MSYS itself. With apologies to the underpants gnomes, the following is not a good example: 1) switch to $my_favorite_vcs 2) ??? 3) PROFIT! So far, we haven't even seen step #1... -- Chuck |
From: Jasper H. <jas...@gm...> - 2010-06-17 02:47:18
|
Charles Wilson wrote: > In addition to the effort involved, for very little gain, there's one > (additional) problem with switching VCS implementations: we don't > provide any *clients* for VCS implementations other than cvs. Just out of curiosity (no, I am not proposing a change), to what degree is msysgit actually msys? (note: I am aware such a topic may have been discussed previously as well, but the sourceforge mailing list search seems to be broken as I can't find anything) Jasper Horn |
From: Charles W. <cwi...@us...> - 2010-06-17 13:26:47
|
On 6/16/2010 10:46 PM, Jasper Horn wrote: > Charles Wilson wrote: >> In addition to the effort involved, for very little gain, there's one >> (additional) problem with switching VCS implementations: we don't >> provide any *clients* for VCS implementations other than cvs. > > Just out of curiosity (no, I am not proposing a change), to what > degree is msysgit actually msys? Last time I checked, "msysgit" was actually an entire distribution of most of the core tools of msys, PLUS a port of git to msys. Whether they modified any of those core tools -- like the MSYS runtime itself -- I don't know; I doubt they modified much, and only as needed to support git. I do know the bundled perl they ship is newer than ours. -- Chuck |
From: Earnie <ea...@us...> - 2010-06-18 15:16:58
|
Charles Wilson wrote: > On 6/16/2010 10:46 PM, Jasper Horn wrote: >> Charles Wilson wrote: >>> In addition to the effort involved, for very little gain, there's one >>> (additional) problem with switching VCS implementations: we don't >>> provide any *clients* for VCS implementations other than cvs. >> >> Just out of curiosity (no, I am not proposing a change), to what >> degree is msysgit actually msys? > > Last time I checked, "msysgit" was actually an entire distribution of > most of the core tools of msys, PLUS a port of git to msys. Whether > they modified any of those core tools -- like the MSYS runtime itself -- > I don't know; I doubt they modified much, and only as needed to support git. > I'm thinking that the MSYSGIT package is a bundling of a native Windows git that uses MSYS for the shell of choice for scripting. In fact if you grep the git.exe program you'll not find MSYS in it nor in any of the libexec/git-core/*.exe files. > I do know the bundled perl they ship is newer than ours. > I was interested to know what I needed to copy from the MSYSGIT package to determine what exactly was needed from it. While perl is used in some scripts like git-difftool, I didn't need the one distributed by the package. So, while not MSYS dependent it is still usable within MSYS, just not within RXVT. -- Earnie -- http://www.for-my-kids.com |
From: Isidor Z. <mi...@qu...> - 2010-06-17 03:29:04
|
> In addition to the effort involved, for very little gain, there's one > (additional) problem with switching VCS implementations: we don't > provide any *clients* for VCS implementations other than cvs. > Do you have some background on the "very little gain" assertion? In particular, I would be interested in knowing what VCSes you compared CVS to, and to what extent. Myself, I found that even for those projects where the maintainers have an extraordinarily strong distaste for non-antique VCS systems, the advantage from setting up a local git mirror quickly outweigh the effort to set it up, be it for efficient history-aware processing/querying of the code, for keeping local changes in sync with upstream development or to ease backporting important fixes to older versions in cases where interface stability has to be ensured on clients' systems (just to name a few applications). The cases where upstream actually uses a distributed VCS itself makes it much easier to contribute back. > All that effort...for what, exactly? True, cvs is ancient and not very > flexible. It doesn't follow the latest Distributed VCS fad. It works > poorly with renames and directories and binary files. This > matters...why? Does the MinGW/MSYS project REALLY push the capabilities > of its own repo that hard? No. > True, people are always good at working around tool deficiencies. However, it doesn't necessarily mean that not having to do so is a disadvantage. Don't get me wrong, though. I have no objections against a pragmatic decision in favour of one option after thinking through the alternatives. I'm just opposed to "we always lived in caves, so there can't be anything better" logic. Best regards, Isidor |
From: Earnie <ea...@us...> - 2010-06-18 15:29:53
|
Isidor Zeuner wrote: >> In addition to the effort involved, for very little gain, there's one >> (additional) problem with switching VCS implementations: we don't >> provide any *clients* for VCS implementations other than cvs. >> > > Do you have some background on the "very little gain" assertion? In > particular, I would be interested in knowing what VCSes you compared > CVS to, and to what extent. Myself, I found that even for those > projects where the maintainers have an extraordinarily strong distaste > for non-antique VCS systems, the advantage from setting up a local git > mirror quickly outweigh the effort to set it up, be it for efficient > history-aware processing/querying of the code, for keeping local > changes in sync with upstream development or to ease backporting > important fixes to older versions in cases where interface stability > has to be ensured on clients' systems (just to name a few > applications). The cases where upstream actually uses a distributed > VCS itself makes it much easier to contribute back. > If this project proved to have more contributors that were dependent on more modern VCS then your statements would ring true and we might consider a move from CVS. The decisions to stay with CVS isn't one of which is a better VCS but more of who has the time and who is it that really cares. Given enough documentation those contributing could use any, and I currently use CVS, SVN and GIT for various projects. There would not be an increase in developers who develop for MinGW or MSYS just based on which VCS is used so the decision to stay with the current CVS stands. Until we have a 400 percent increase in developers we will not consider a change in the VCS and even then it may require more than the 400 percent increase to convince us. -- Earnie -- http://www.for-my-kids.com |
From: Isidor Z. <mi...@qu...> - 2010-06-18 17:50:17
|
> > There would not be an increase in developers who develop for MinGW or > MSYS just based on which VCS is used so the decision to stay with the > current CVS stands. I'm not saying switching the VCS will magically spawn developers. Neither does a VCS that makes things unnecessarily hard (from a prospective of what people are used to in 2010) attract developers. Attracting developers is a matter of creating a harmonizing collaboration environment. A convenient VCS can be a part of that. > Until we have a 400 percent increase in developers > we will not consider a change in the VCS and even then it may require > more than the 400 percent increase to convince us. > I don't believe in convincing people. I was merely interested in finding out what led to the current consensus. Best regards, Isidor |