From: Lars U. <lar...@dl...> - 2010-06-17 06:40:19
|
Charles Wilson wrote: > 1) port the appropriate client to MSYS, and package it appropriately for > mingw-get -- including all necessary dependencies. Do I understand MSYS correctly, that - with some luck - this *might* not involve any coding *at all* - and instead just ./configure make make install on the dependencies' source code, and then on ghostscript? Then pack up all the output files into according directories, and make it a tar.lzma and it would be usable just like any other standard tool package? > 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! That brought out some memories :D -- 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: Charles W. <cwi...@us...> - 2010-06-17 13:29:42
|
On 6/17/2010 2:41 AM, Lars Uffmann wrote: > Charles Wilson wrote: >> 1) port the appropriate client to MSYS, and package it appropriately for >> mingw-get -- including all necessary dependencies. > > Do I understand MSYS correctly, that - with some luck - this *might* not > involve any coding *at all* - and instead just ./configure make make > install on the dependencies' source code, and then on ghostscript? Uhm, what? We're talking about porting VCS clients here. The ghostscript thing was another thread. > Then pack up all the output files into according directories, and make > it a tar.lzma and it would be usable just like any other standard tool > package? See the recent thread on mingw-devel regarding PDCurses. That's how it's done. Unfortunately, there is almost ALWAYS some coding involved; not everything supports cygwin (or msys) out of the box. And, we usually like for ported packages' -src components to included an automated buildscript...so that's "coding" of a sort. -- Chuck |
From: Charles W. <cwi...@us...> - 2010-06-17 13:53:13
|
On 6/16/2010 11:28 PM, 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. I've heavily used many VCS's from SCCS to bzr to git and in between. The only ones I haven't used are hg and darcs. My favorite is actually git. That having been said... You have to realize that very little of "MinGW/MSYS" is actually maintained in our own VCS. MOST of the packages -- like mingw-gcc -- have external repositories, and "our" development happens "there", not "here". Many are simply shipped just like linux RPMS: we grab the upstream source tarball, and package that with whatever patches are needed (think "SRPM")...none of which is maintained in a repo (except, perhaps, privately). If you browse thru our repo, most of it is obsolete and unused -- like all the VERY old "ports" of many msys tools. This switch in development/delivery practice occurred as we transition from the "monolithic installer" to "multiple independent packages" model. At some point, somebody should probably make the effort of deleting all that now-unused cruft; sigh. As far as current data, it's mostly the msys runtime source code some stuff packaged into msysCORE (icons, batch files) mingw-get lpr-enhanced mingw-utils pexports mingw-catgets the cross-build scripts and maybe a few other items. But by FAR the bulk of the MinGW/MSYS corpus is "maintained" as "here's a tarball including upstream src, some patches, and a build script". So...how much benefit will we get by migrating that tiny portion of the corpus from CVS to anything else? > 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. It's a lot of effort to accurately migrate a VCS while preserving history (anybody can simply import a current snapshot into a brand new repo of any VCS, of course -- but that's not very helpful). Given the small amount of the msys project that actually belongs IN the repo at all, that's a lot of effort to give some users a warm fuzzy when interacting with that small subset of the full MinGW/MSYS codebase. Effort that is (a) in short supply, and (b) much better spent working on stuff outside our VCS, like better mingw-gcc, or a newer port of perl, or... Wasting time on a email thread haranguing us about policies outside our control, whose only "acceptable" resolution is to spend man-months of effort setting up new hosting. man-months we don't have. > 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. Sure. CVS sucks. Wave a magic wand and instantly convert everything to git or svn or whatever, with full history support, AND instantly provide a nice mingw-get-compatible set of packages for msys ports of that VCS client and all of its depedencies...wonderful. But I don't have a magic wand. It comes down to available manpower and time. The core devs are tapped out; look how long it's taking to get mingw-get out the door -- and even there, we have a mega-thread from non-core-devs about writing python scripts to install msys/mingw "in the interim until mingw-get is ready" -- INSTEAD OF ACTUALLY HELPING TO GET MINGW-GET READY. Insanity. So, no, until (a) somebody ports the appropriate VCS clients and packages them, as described previously, and (b) makes a convincing case for why the effort of transforming our own VCS repo to $my_favorite_vcs is beneficial (to the ongoing development of that portion of the corpus actually IN the VCS) -- it ain't gonna happen. We don't have the time or manpower. If that's not the definition of a "pragmatic decision", I don't know what is. -- Chuck |
From: Stefano S. <ste...@po...> - 2010-06-17 14:26:35
|
On date Thursday 2010-06-17 09:52:53 -0400, Charles Wilson wrote: [...] > It comes down to available manpower and time. The core devs are tapped > out; look how long it's taking to get mingw-get out the door -- and even > there, we have a mega-thread from non-core-devs about writing python > scripts to install msys/mingw "in the interim until mingw-get is ready" > -- INSTEAD OF ACTUALLY HELPING TO GET MINGW-GET READY. Insanity. Hi Charles, first of all I want to thank you mingw guys for the time and effort spent on this project. Current installation of MinGW/MYSY is quite painful and possibly scaring away many potential users and contributors, documentation also lacks so it has not been immediate for me to arrive at mingw-get. I understand your feeling, but honestly you can't realistically expect each new user to turn immediately into a contributor. People need to find quick solutions as they need to pay their bills and fix their problem *now*, and it's far easier to find a quick'n'dirty solution hacked in an hour or so rather than immediately turn yourself into an active contributor for each project you stumble across, as a free software developer I don't expect that from most users. At least I tried to be collaborative and posted back the result of my work. Regards. |
From: Isidor Z. <mi...@qu...> - 2010-06-17 23:43:00
|
> On date Thursday 2010-06-17 09:52:53 -0400, Charles Wilson wrote: > [...] > > It comes down to available manpower and time. The core devs are tapped > > out; look how long it's taking to get mingw-get out the door -- and even > > there, we have a mega-thread from non-core-devs about writing python > > scripts to install msys/mingw "in the interim until mingw-get is ready" > > -- INSTEAD OF ACTUALLY HELPING TO GET MINGW-GET READY. Insanity. > > Hi Charles, > > first of all I want to thank you mingw guys for the time and effort > spent on this project. > > Current installation of MinGW/MYSY is quite painful and possibly > scaring away many potential users and contributors, documentation also > lacks so it has not been immediate for me to arrive at mingw-get. > It's the same for me. I fear the way mingw strives for being self-hosting might split the community too much to allow for huge amounts of contributions. At least from my point of view. I use mingw to cross-compile from Linux, but I had working packaging before (I think most Linux deployments have), so it was just much easier to adapt the existing packaging for a new cross-compile target than to set up a completely separate development environment for mingw. I would love to see a deployment infrastructure which is suitable for self-hosting and integration in cross-compile environments with the same codebase. Maybe yum/rpm ports. Best regards, Isidor |
From: Isidor Z. <mi...@qu...> - 2010-06-17 23:43:00
|
> But by FAR the bulk of the MinGW/MSYS > corpus is "maintained" as "here's a tarball including upstream src, some > patches, and a build script". > Well, I often have to deploy software packages to RPM platforms, and I found it very convenient to manage the unpatched/patched upstream source trees in a repo so I can avoid manual rediffing. Since I switched to that approach, I can sync up with upstream changes much more often because it is usually almost zero effort to do so. However, I wouldn't have thought of that approach when using CVS because it doesn't exactly scale well. So I wouldn't say a packaging project cannot profit from a technically superior VCS. > So...how much benefit will we get by migrating that tiny portion of the > corpus from CVS to anything else? > Ideas on how to use existing technology to improve processes usually come after working with the technology for some time. See above for one example on how I found it useful for packaging. In another post, you mentioned that msysgit is actually a msys distribution on its own. So there seems to be a community need to adapt msys. If it was using a distributed VCS, the most common way for people to do so would be to clone the repo and make their changes on their copy. Mingw could then pull their changes and cherry-pick. If I'm not missing something, improving mingw through changes from such external efforts is harder with the current maintenance approach. I think the point here is not that using better tools could not bring much improvement. We simply can't tell before someone tried it. I think the relevant point is simply the effort needed to do a switch. > > 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. > > It's a lot of effort to accurately migrate a VCS while preserving > history A lot of effort, consisting of one line of code starting with "git cvsimport..." > > > 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. > > Sure. CVS sucks. Wave a magic wand and instantly convert everything to > git or svn or whatever, with full history support, See above. > AND instantly provide > a nice mingw-get-compatible set of packages for msys ports of that VCS > client and all of its depedencies...wonderful. > The code seems to be already there, in msysgit. I don't know much about mingw-get so I can't tell what exactly is missing. > But I don't have a magic wand. > > It comes down to available manpower and time. The core devs are tapped > out; look how long it's taking to get mingw-get out the door -- and even > there, we have a mega-thread from non-core-devs about writing python > scripts to install msys/mingw "in the interim until mingw-get is ready" > -- INSTEAD OF ACTUALLY HELPING TO GET MINGW-GET READY. Insanity. > Agreed. But I think it's a chicken-egg problem. Once a convenient infrastructure consisting of binary deployment software and a distributed VCS is in place, it is probably easy enough to work on own adaptions in a way reasonably compatible to what official mingw does so more of these adaptions can be contributed back easily. Best regards, Isidor |
From: Isidor Z. <mi...@qu...> - 2010-06-18 17:50:17
|
> > > 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. > > > > It's a lot of effort to accurately migrate a VCS while preserving > > history > > A lot of effort, consisting of one line of code starting with "git > cvsimport..." > ..and because I prefer to act and contribute rather than to hypothesize about how things could be, I put up a git mirror of the CVS sources, so the mystics have something to get a warm and fuzzy feeling about, the nostalgics have something to ignore, and the gimmick lovers have something to try getting productive with: [1]. Clone away... > > > > It comes down to available manpower and time. The core devs are tapped > > out; look how long it's taking to get mingw-get out the door -- and even > > there, we have a mega-thread from non-core-devs about writing python > > scripts to install msys/mingw "in the interim until mingw-get is ready" > > -- INSTEAD OF ACTUALLY HELPING TO GET MINGW-GET READY. Insanity. > > > However, I do wonder to what extent it can be considered insanity when people try to put up mingw-get alternatives when the mingw homepage explicitly states "the maintainer is not yet accepting patches" ([2]). I think people interested in a working mingw-get will strive to simply get things working, be it through patching what doesn't work well for them. Best regards, Isidor [1] http://gitorious.org/mingw-unofficial [2] http://www.mingw.org/wiki/Official_CVS_Repository |
From: Erwin W. <wat...@xs...> - 2010-06-17 15:15:01
|
Op 17-06-10 03:48, Charles Wilson schreef: > 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. > You don't need other clients in MSYS, you can use Cygwin for that. That is how I work. Compile in an MSYS shell and run Subversion in a Cygwin environment. Erwin |
From: Earnie <ea...@us...> - 2010-06-18 15:03:18
|
Erwin Waterlander wrote: > Op 17-06-10 03:48, Charles Wilson schreef: >> 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. >> > You don't need other clients in MSYS, you can use Cygwin for that. > That is how I work. Compile in an MSYS shell and run Subversion in a > Cygwin environment. > I use a native Subversion from within MSYS without RXVT just fine. Note that you must get rid of RXVT. One way to do that is by issuing the command ``start /msys --norxvt'' and then working in the new window. -- Earnie -- http://www.for-my-kids.com |
From: Charles W. <cwi...@us...> - 2010-06-17 16:21:11
|
Stefano Sabatini writes: > On date Thursday 2010-06-17 09:52:53 -0400, Charles Wilson wrote: > [...] > > It comes down to available manpower and time. The core devs are tapped > > out; look how long it's taking to get mingw-get out the door -- and even > > there, we have a mega-thread from non-core-devs about writing python > > scripts to install msys/mingw "in the interim until mingw-get is ready" > > -- INSTEAD OF ACTUALLY HELPING TO GET MINGW-GET READY. Insanity. > Current installation of MinGW/MYSY is quite painful and possibly > scaring away many potential users and contributors, Yes, that's why we'd love for mingw-get to finally reach at least beta state. (My personal definition of beta, not sure if it matches Keith's, is "capable of installing all msys and mingw components correctly". It may not be able to uninstall anything, and updating an old (ex: gzip) package to a newer release might or might not work. Initial installation. That's it. What we need for that is validation of all the xml manifests already published: do they work? Are there errors, typos, missing dependencies, etc?) > documentation also > lacks so it has not been immediate for me to arrive at mingw-get. > > I understand your feeling, but honestly you can't realistically expect > each new user to turn immediately into a contributor. No, of course not. But look at the download stats. There are hundreds of thousands of people who have downloaded MinGW -- somewhere in there are people who are not new users. Of the ten thousand or so who have downloaded MSYS, surely there are more than the handful of current contributors, who could assist? > People need to > find quick solutions as they need to pay their bills and fix their > problem *now*, and it's far easier to find a quick'n'dirty solution > hacked in an hour or so rather than immediately turn yourself into an > active contributor for each project you stumble across, as a free > software developer I don't expect that from most users. At least I > tried to be collaborative and posted back the result of my work. Agreed. And there have actually already been several posted scripts to do much of what you suggest. But in each case, they were intended as quick'n'dirty workarounds...and in each case (including my own *) they took time away from the REAL solution. Let me put it this way: if you're knowledgeable enough to figure out exactly which elements should be downloaded, and how to install them, so that you can create a working MSYS installation...you're perfect. You're EXACTLY the person that Keith needs to help alpha-, beta-, and rc- test mingw-get. (*) I adapted one shell script into a whole installation manager, which installs both msys and mingw as specified in a directive file, because I needed it for my dev team at work. But I never posted it, because polishing it up into "releasable" state would take too much time away from other MSYS tasks, and it already took me five months to do the 'rebuild all msys with new msys-gcc' project... -- Chuck |
From: Charles W. <cwi...@us...> - 2010-06-17 16:06:55
|
Erwin Waterlander writes: > Op 17-06-10 03:48, Charles Wilson schreef: > > 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. > > > You don't need other clients in MSYS, you can use Cygwin for that. > That is how I work. Compile in an MSYS shell and run Subversion in a > Cygwin environment. And that's just fine if you want to use MSYS/MinGW to develop third party code for native windows. But...it's a little schizophrenic if we were to set things up so that you'd need a separate cygwin installation, to work with the MSYS and MinGW code in our own repository...when MSYS is *supposed* to be self-hosting. Now, granted, Keith and some others do all their work on a linux-hosted cross env -- but that's a platform choice (ix-nay indows-way). But either MSYS is self-hosting or it isn't. If the source code is accessible only thru tools which can't (*) be accessed from an msys shell, and require an entirely separate posix API library...that's just silly. (*) "can't" as in "don't be surprised if your shell hangs". There are/have-been some issues with cygwin and msys processes not interoperating well, although that may, in SOME cases, no longer be an issue. We still don't official support calling msys apps from cygwin shells, or vice versa. -- Chuck |
From: guenter <gue...@ar...> - 2010-06-15 17:08:04
|
Am 15.06.2010 10:35, schrieb M. Bashir Al-Noimi: > 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: [...] Thanks for the info! Greetings, Günter (from DE) |
From: Conan K. (ニール・ゴ. <ngo...@gm...> - 2010-06-15 17:18:10
|
On Tue, Jun 15, 2010 at 12:07 PM, guenter <gue...@ar...> wrote: > Am 15.06.2010 10:35, schrieb M. Bashir Al-Noimi: > > 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: > [...] > > Thanks for the info! > > Greetings, > Günter (from DE) > > > As far as I'm aware, you can switch that on or off in the Project Administration. It may be on by default, but you can toggle the access on and off under Project Settings in Project Administration. |
From: Tor L. <tm...@ik...> - 2010-06-15 19:28:10
|
> this is absolute racism You seem to be confusing politics with racism. Are North Koreans a different "race" than South Koreans? Are Cubans in Cuba a different "race" than Cuban-Americans? Are Sudanese a much different "race" than, say, Egyptians? Also, as far as I know, Freedom (in a broader sense) that you seem to value so much, is in rather short supply in the countries on the US's embargo list. (Not that this is the reason for the embargo, of course.) --tml |
From: Dobrescu M. <msd...@ya...> - 2010-06-16 05:18:22
|
Indeed, 'racism' is not the right word. But, to be precise, Sudanese Nubians are close to Egyptians, but there are also Acholi, for instance, which are a different race. Sadly, different color made people think they are fundamentally different, which is SO wrong. ________________________________ From: Tor Lillqvist <tm...@ik...> To: MinGW Users List <min...@li...> Sent: Tue, June 15, 2010 10:27:47 PM Subject: Re: [Mingw-users] MinGW forbidden by sf.net > this is absolute racism You seem to be confusing politics with racism. Are North Koreans a different "race" than South Koreans? Are Cubans in Cuba a different "race" than Cuban-Americans? Are Sudanese a much different "race" than, say, Egyptians? Also, as far as I know, Freedom (in a broader sense) that you seem to value so much, is in rather short supply in the countries on the US's embargo list. (Not that this is the reason for the embargo, of course.) --tml ------------------------------------------------------------------------------ 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 |
From: M. B. Al-N. <ad...@mb...> - 2010-06-15 19:54:17
Attachments:
admin.vcf
|
On 15/06/2010 09:27 م, Tor Lillqvist wrote: >> this is absolute racism >> > You seem to be confusing politics with racism. Are North Koreans a > different "race" than South Koreans? Are Cubans in Cuba a different > "race" than Cuban-Americans? Are Sudanese a much different "race" > than, say, Egyptians? > > Also, as far as I know, Freedom (in a broader sense) that you seem to > value so much, is in rather short supply in the countries on the US's > embargo list. (Not that this is the reason for the embargo, of > course.) > > It easy to change whole the discussion from direction to another by focusing on none related points as you said before. MinGW forbidden by sf.net because they apply US embargo the solution is simple one or both of the following: If Mingw still open source and respects open source licenses it have to be available for anyone from east to west and north to south of the global earth thus it can move to another open source hosting service or at least activate tick option which allow users from US blacklist to be able to access mingw otherwise I think mingw will not be open source anymore. -- Best Regards Muhammad Bashir Al-Noimi My Blog: http://mbnoimi.net |
From: Tor L. <tm...@ik...> - 2010-06-15 22:41:11
|
> It easy to change whole the discussion from direction to another by focusing > on none related points Perhaps you then should try to concentrate on your actual points then and not throw in wild exaggerations, like accusations of "racism". --tml |
From: Vincent T. <vt...@un...> - 2010-06-15 22:29:40
|
On Wed, 16 Jun 2010, M. Bashir Al-Noimi wrote: > You can read about Notepad++ decision at the above links and the hot > discussions about it at: > http://my.reddit.com/r/programming/comments/ccu2f/wtg_notepadd_this_action_is_totaly_absurd_the/ > > By the way, Notepad++ moved to http://notepad-plus-plus.org/ which hosted by > tuxfamily.org in France. maybe the mingw guys can provide mirrors somewhere. Vincent Torri |
From: Tor L. <tm...@ik...> - 2010-06-15 22:38:47
|
> maybe the mingw guys can provide mirrors somewhere. Maybe anybody else can do it? That is what Open Source allows, and encourages. But no, instead it is so much easier to just angrily demand that somebody who already is doing a lot of (unpaid) work for the benefit of others, does even more to work around some technical, or in this case political, problems they are not responsible for. --tml |
From: Vincent T. <vt...@un...> - 2010-06-15 22:45:20
|
On Wed, 16 Jun 2010, Tor Lillqvist wrote: >> maybe the mingw guys can provide mirrors somewhere. > > Maybe anybody else can do it? That is what Open Source allows, and > encourages. But no, instead it is so much easier to just angrily > demand was my comment really "angrily" ? It was a suggestion. And with a little script and some scp, it should be possible to automatize that, no ? Again, it's a suggestion. We do that for a project i'm working on. Vincent Torri > that somebody who already is doing a lot of (unpaid) work for > the benefit of others, does even more to work around some technical, > or in this case political, problems they are not responsible for. > > --tml |
From: M. B. Al-N. <ad...@mb...> - 2010-06-15 23:18:45
Attachments:
admin.vcf
|
On 16/06/2010 12:38 ص, Tor Lillqvist wrote: >> maybe the mingw guys can provide mirrors somewhere. >> > Maybe anybody else can do it? That is what Open Source allows, and > encourages. Currently I can't because I jailed by US embargo hehe, but this problem needs real solution exact official solution from mingw admins. Until now I didn't find any admin here in the list, is it? > But no, instead it is so much easier to just angrily > demand that somebody who already is doing a lot of (unpaid) work for > the benefit of others, Noway all open source community without any exception doing prefect efforts and personally I consider my myself owned by that community. > does even more to work around some technical, > or in this case political, problems they are not responsible for. > No I don't agree with you completely, admins must a give us a clear statement about these injustice rules just like many other projects because mingw isn't a corporation or commercial company it raised from the community to it. In this way admins are completely responsible for mingw project's policy. -- Best Regards Muhammad Bashir Al-Noimi My Blog: http://mbnoimi.net |
From: Isidor Z. <mi...@qu...> - 2010-06-16 06:16:03
|
I think we should all try to keep cool. I think each involved side's point is somehow valid. Hosting is incredibly cheap in the US, so it was just a matter of time that the US government figures out how to use that fact for their econo-warfare against countries they find undesirable. Contributors and users from those countries are justifiably upset about being locked out. And project admins who are unwantedly caught in the crossfire most likely have had other plans than putting extra effort in such issues. > > maybe the mingw guys can provide mirrors somewhere. > > Maybe anybody else can do it? That is what Open Source allows, and > encourages. I think that's the most reasonable solution to the issue. It is often frustrating to try educating people. And while I don't necessarily think it's the best strategy, it is fair enough for the project admins to passively support the US government's move. But the GPL does not virally propagate export embargoes, and setting up a mirror is not rocket science. And, as Stefano pointed out, there is some interest in having a more modern VCS. So someone willing to do so will have a resource with at least two advantages: more contributors, and more convenient version control. Personally, as I heard that Germany as also decided to bow down to US pressure and stricten trade relations with US-embargoed contries, I would not do so right now without prior legal consultation. But whoever is willing and capable to do so right now will have incredibly good conditions to jump-start his community contribution. Best regards, Isidor |
From: M. B. Al-N. <ad...@mb...> - 2010-06-16 01:20:35
Attachments:
admin.vcf
|
On 16/06/2010 02:09 ص, Tor Lillqvist wrote: >> And if this company decides to make MONEY from hosting open source projects, and the country they reside in has some export control legislation, forbidding them to provide open source(!) software to some countries, which is *clearly against the concept of open source* >> > I am not so sure about that. One is free to redistribute open source > software to just a small number of parties. One is not required to > provide it to anybody who asks for it. In this case, SF provides it to > quite a lot of parties, i.e. anybody with an internet connection in a > country not on the US embargo list. That doesn't mean SF would *have > to* provide it also to people in countries on the embargo list. > > Just like I don't have to provide a copy of my MinGW installation to a > random person on the street asking for it, even if I might have given > such a copy to a friend. > > Does the "concept of open source" also require anybody who has some > open source software to mail it on physical media to anybody who asks > for it and doesn't have an Internet connection? To be sure I suggest to do the following before allowing starting downloading process by anonymous buddy: ******** Tor's open source software download application ******** Dear visitor before downloading this "open source" product you've to fill out the following form: name: nick name: mother name: father name: how many brothers you're: how many sisters you're: age: birthday date: IP: country: city: address: picture (no more than 1 year old): passport number: sex: color: do you've any diseases? do you accept my open source concept? do you accept the following: In the future if I hate you. you've to return back this software because of my embargo rules? do you accept to contribute in this project just in case i like you otherwise you'll loose your rights to access your contributions? do you accept to beg me before starting download process? do you hate me? Click here to send this application by mail for look into our database because you may ugly guy. > All this, of course, in my humble opinion, I am not a lawyer, etc, yadda yadda. > Be a human and this could be enough. Try to put yourself in my situation. If someone in US (or somewhere else) decided to block all Finlands from accessing their sf.net ACCOUNTS... what you'll do as a person? The right way is clear nobody can miss it otherwise someone who want to. OPEN SOURCE SHOULD BE OPENED FOR EVERYBODY FOR ALL CONTRIBUTES. NO ONE CAN LOOSE HIS/HER CONTRIBUTIONS IN ANY CASE BECAUSE OPEN SOURCE PROJECTS BUILT BY CONTRIBUTORS NOT BY POLITICIANS. -- Best Regards Muhammad Bashir Al-Noimi My Blog: http://mbnoimi.net |
From: Tatsh <dd...@gm...> - 2010-06-16 16:42:08
|
Any issue with migrating to Google Code? I know it's Google but it's fast. It's the main reason I migrated my project to Google Code because I hate SF lately. All the layout issues, the social networking nonsense. I THINK you can still look at Japanese SourceForge and see it is a SERIOUS site, not some 'share this, like that' site like everything else is becoming. (If you can't tell already, I HATE social networking; warping minds.) M. Bashir Al-Noimi wrote: > 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-acce > ss-for-certain-persons-in-accordance-with-us-law/ > http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blo > cking/ -- Tatsh www.tatsh.net dd...@gm... |
From: M. B. Al-N. <ad...@mb...> - 2010-06-16 17:28:02
Attachments:
admin.vcf
|
On 16/06/2010 06:41 م, Tatsh wrote: > Any issue with migrating to Google Code? I know it's Google but it's fast. > It's the main reason I migrated my project to Google Code because I hate SF > lately. All the layout issues, the social networking nonsense. Google Code takes same policy because it uses servers in US. > I THINK you can > still look at Japanese SourceForge and see it is a SERIOUS site, not some > 'share this, like that' site like everything else is becoming. (If you can't > tell already, I HATE social networking; warping minds.) > Actually I didn't know that there is Japanese SourceForge I'll check it now to see if they applying blocking policy although I suspect not. > M. Bashir Al-Noimi wrote: > >> 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-acce >> ss-for-certain-persons-in-accordance-with-us-law/ >> http://sourceforge.net/blog/some-good-news-sourceforge-removes-blanket-blo >> cking/ >> -- Best Regards Muhammad Bashir Al-Noimi My Blog: http://mbnoimi.net |