From: techtonik <tec...@us...> - 2007-01-30 05:38:39
|
The stuff with File Release System on SF will not be fixed. Unfortunately. ---------- Forwarded message ---------- From: SourceForge.net <no...@so...> Date: Jan 29, 2007 11:46 PM Subject: [ alexandria-Support Requests-1647115 ] Package listing hides important releases To: no...@so... Support Requests item #1647115, was opened at 2007-01-29 08:57 Message generated for change (Comment added) made by fincher You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1647115&group_id=1 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: SF.net File Release System >Group: Second Level Support >Status: Closed Priority: 5 Private: No Submitted By: anatoly techtonik (techtonik) >Assigned to: Jeremy Fincher (fincher) Summary: Package listing hides important releases Initial Comment: New file release design hides important files from users. Take a look at our MinGW project. http://sourceforge.net/project/showfiles.php?group_id=2435 We have several packages ranged on maturity status. Each package (Current, Candidate, etc.) contains several releases of various tools. Unfortunately only last three releases (tools) are displayed for each package and developers need to make additional step following a link to "view older releases". Is it possible to fully expand package releases for this project? http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721 In case of automated scenario or universal solution if manual intervention is not possible I could propose hide older releases only if they have similar names and different versions. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (fincher) Date: 2007-01-29 16:46 Message: Logged In: YES user_id=1019020 Originator: NO Greetings, Unfortunately, what you're asking for is not possible. The issue, however, exists because you're not using the File Release System (FRS) as intended. Each "release" that you currently have should be a "package," and different versions (current, candidate, etc.) should be a "release" for its particular package. SourceForge.net Support ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1647115&group_id=1 -- --t. |
From: Paul G. <pga...@co...> - 2007-01-30 20:25:35
|
Hi folks, Without going into tmi, I've been quietly continuing my work on Mngw through an open source consulting organization. I have been watching these issues with SF increase frustration and decrease development efficiency for quite some time. It does appear, imho, that it is time to make a change. As much as I have enjoyed SF and the fact that it has, in the past, always been a proponent for OpenSource (at least until the last six months) development and support; in as much as that has been the case, it does appear that it is time to define a new place for Mingw, at the very least. Msys, of course, will probably follow in defining that need to move on. In that Sourceware.org has always been there, and it still has much the same philosophy as it has had when Mingw began. Fwiw, if it is determined that sourceware.org is the way to go, my vote would be cast for moveing to sourceware.org if there exist no other alternatives. My biggest concern with moving to sourceware.org is that we, as developers, would lose our control over where Mingw will, in the future, and in terms of a collective developers vision, will move to. Paul G. On 30 Jan 2007 at 11:43, Earnie Boyd wrote: > Quoting Greg Chicares <chi...@co...>: > > > > > > Yet cjf has offered us sourceware.org facilities as an alternative. > > > > [some history about MinGW and sf snipped] > >> > >> I've asked about this before; but should we reverse our logic > >> again? > > > > I guess our options are > > - live with the current problems > > - adapt to the way sf feels everything should work today > > - move elsewhere, e.g., sourceware.org > > I think moving elsewhere is the best long-term solution. I guess a > > piecemeal migration has already begun anyway, with cvs. Would it be > > a lot of work to move released files there next, if that's > > acceptable to sourceware.org? > > > > I ran out of time to look at doing this. I had started looking at the > ezmlm users admin manual and just simply didn't have time to move it > further. Chris had set up a mingw-dvlpr list for Keith and I to play > with. As far as the CVS migration you speak of, mingw runtime and > w32api have always been a part of Cygwin since their creation. As far > as the files themselves Chris has given us ftp access and an htdocs > area. The problem of course is the management of the move. > > I do not have time to be involved with the move. Greg are you > offering your time to coordinate this effort, if yes I can support > this? If we could get a MySql DB on sourceware.org we could use > Drupal with its project module to control the bugs, etc for each > package we offer. > > Earnie > > ---------------------------------------------------------------------- > --- Take Surveys. Earn Cash. Influence the Future of IT Join > SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys - and earn > cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEV > DEV _______________________________________________ MinGW-dvlpr > mailing list Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ea...@us...> - 2007-02-01 13:35:23
|
Quoting techtonik <tec...@us...>: > On 1/31/07, Earnie Boyd <ea...@us...> wrote: > >> > My first impression about sourceware.org is "that's suxx", sorry. =) >> You must bite the hand that feeds you. Sourceware.org is offering >> hosting services not middleware for that service. > > "Red Hat is pleased to provide sourceware.org, a site aimed at > providing first-rate hosting of open source projects for software > developers." Seems ok, if that means we shouldn't use their middleware > and could install Drupal to manage it independently. > > Still I'd like to know if they might want something for that service? > For example, SF wants buttons displayed on main page. Sometimes it is > worth to check if the feeding hand is clean of drugs and there is no > some suspictious trap mechanizm around. > The offer is a free service. At the time of the offer and as lives today their was no such requirement and I would expect to put a complementary "hosting services provided by" type of blurb on the page. >> If you do not know then the best thing to do is to be silent about >> opinions and ask questions to learn. Chris' offer is nothing more than >> something similar to, we have a server with mail, MySql, ftp and apache >> services. We point www.mingw.org to the sourceware.org server and we >> develop the UI. > > Sounds Ok. No shell? I.e. should we sync design or other web-site > changes with RCS manually? > Yes a shell is provided to those that meet the qualifications for one. >> > I'd like to use Google Code, but they possess all sorts of >> > prejudices about Public Domain projects. There are also no pretty >> > statistical charts or comparative download ratings at Google's, but >> > downloads are rather progressive - you can assign different tags to >> > them to sort as you wish. >> >> I don't know what this has to do with MinGW. You learning others API >> on our behalf when our behalf isn't served by anything you've learned >> isn't anything I'm interested in giving you approval for. I'm not >> interested in serving AJAX from the MinGW pages. > > No, no, no. Google Code has a faciliy for hosting open source projects. > * Project workspaces with simple membership controls > * Version control via Subversion > * Issue tracking > * Mailing lists at groups.google.com > * Wiki > * Downloads > FAQ: http://code.google.com/support/bin/topic.py?topic=10380 > Example: http://code.google.com/p/airbag/ > Appears to be a bit too controlling for my tastes. > No custom web-site hosting, yep, but hence more easy to maintain. And from the two example links you give it rather ``suxx''. Beauty must be in the eye of the beholder. > It could be better than Drupal + MySQL + another two passwords to > remember in case we will switch to SourceWare. One more reason is > that AFAIK Drupal doesn't have any wiki embedded. > You dwell on the password bits (get over the fact that each account has a password) and third party wiki can be added to the sight if needed. Or we could easily add the bits to allow changes to certain content types that we call a wiki. So an authenticated user is allowed to change the content on a content type we call a wiki. I like that, every user can modify it and revisions would be on for that type. > I like SVN and Google Groups, because they intuitive and make life easier > in comparison with rivals. > Just because you know it or perceive that it is better. Again, beauty is in the eye of the beholder. > >> I'm not sure we're you're coming from, the user PoV or the developer >> PoV? Shell access is important only to those maintaining a) cron and >> b) some configuration item. CVS access is important only to those who >> maintain the code. There are only a few users who would be able to do >> either. > >> From web-developers PoV. With SVN things are getting better and more > simple. It is convenient to sync web-site from SVN and you need shell > accound for that. > To activate the sourceware.org htdocs all I have to do is commit to the CVS area already setup. >> > >> > I do not mind migrating MinGW/MSYS CVS to SourceWare and leaving only >> > SVN for the development of installer, >> >> CVS, SVN, any other code change management software are tools that when >> used properly produce the same results. So far the biggest plus I've >> heard tauted about SVN is that it uses port 80 and the SSL is self >> contained. Not a good enough reason for me to go switching from CVS to >> SVN. > > If you have extra free space in your Palm IIIc, try this book - it > really rocks. > http://svnbook.red-bean.com/nightly/en/svn-book.html > You have more toys that I do. > In short: > 1. Port 80 and SSL also means that SVN is able to operate through proxies. > And I've provided a link to help move your ssh connection to port 80. Really, if you corporation doesn't want you accessing the ssh port externally, then my guess is they probably don't like SVN very well either. > 2. I've rarely used CVS from command line, because I find all its keys rather > confusing. With SVN things are much better. > Ahha, the crux of the problem with CVS is you don't know it. SVN is no better. I've used both. > 3. I like tree-based commits or transactions, which make history > really useful > as you can see changes for different files at once (and do not need > to specify > each file in commit message manually). > Uhm, you lost me. To commit changes with cvs I do ``cvs commit''. It goes and looks at the changed files. CVS may be a little slower because it uses flat text files instead of a DB like SVN but with CVS I can do some manual corrections I cannot do with SVN. Also, with SVN don't I have to copy the entire tree to another directory just to create a branch. With CVS that tagging is internal to the code pieces. > 4. SVN is less bandwidth consuming due to more advanced binary diff > and remote access algorithms > Maybe. Is that compared with using the CVS -z9 switch? > 5. No line ending problems > CVS doesn't have line ending problems. It handles line endings the way it is supposed to. The issues with line endings come from the developers. But I suppose you think that ignoring line ending differences is what a good tool is supposed to do. See the mingw lists archives for the outcome of that debate. > http://www.google.com/search?q=why+CVS+is+better+than+SVN =) > > The only drawback is branch/tag system, but it is a good simplicity tradeoff. > You haven't sold me on the simplicity. I have experience with both. I consider the branch/tag one of the best reasons to stick with CVS. I don't have more than one repository of code to deal with on the server side. SVN forces branching to be copied on the server side. >> >> One of the reasons I keep pusing Drupal is that the content is database >> driven. The content changes can be tracked with revisions. We could >> supply MinGW developer blog pages and we can easily create our own >> theme. We aggregate the SF news entries and the FRS changes. We could >> even aggregate other news that is pertinent to MinGW and Windows. > > There is no better way to leave a negative impression about the > project than deserted blog. =) All other things sound good. > People tend to like history. :) Negative impressions. Impressions like beauty are in the eye of the beholder. :p If it is that bothersome some editor can easily disable the content. >> We currently have htdocs in CVS. We accept patches for those in the >> patch tracker. We apply automated changes to trial/htdocs so that >> interested editores (we used to have more than one) could give a vote >> for or against the change. > > This is errm.. what is the synonym for stupid? =) Thanks, I really appreciate being labeled stupid. So you think the changes should go to production untried. How stupid is that? I suppose you put your code into production without testing. Man would I hate to live with the maintenance your production systems. When we had editors the trial/htdocs was a peer to peer approval before production. The peers have left and no one has blazed me with I want to be the editor, may I please take control. > From what I've seen > trial/htdocs contain exactly the changes needed to be present on the > site. Yes, I have stated we do not have an editor to take the changes into production. No editor responsible, no changes to the production environment. > There should be fast and easy way to commit changes (and to > rollback as well) for everyone. I hear Drupal with content revisions calling. > An ideal variant is RCS sync - if site > is broken and developer is not responding - you just rollback site to > the previous version and enjoy. And trial/htdocs prevented the bad code from reaching the masses. The editor would log onto the shell server and install into production manually using ``cvs update foo'' commands. > >> As I've already said MinGW editorialism has >> nearly vanished and no one has really stepped up to take on the task. > > Must be completely vanished with no editorialism at all until serious > conflicts among developers. =) > No editor, no changes to stable content. >> >> I'm not interested at all to moving to someone's private hosting. So, >> no, there is no way _you_ can provide hosting but thank you for the >> offer. Sourceware.org is kind enough to offer and we have yet to do >> that. We are stuck in our ways with the SF UI and change takes time >> that we have yet to find. >> > > Ok. I understand. If we prove that this "organization" is non-profit > under U.S. law, we could get completely independent commercial-quality > hosting for the lifetime (although still shared plan). > > http://wiki.dreamhost.com/index.php/Non-profit_Discount > MinGW has no organization from a legal perspective. It is a cooperative formed by agreeing individual parties. The dreamhost statements leave a little to be desired as there are those that take MinGW and make money with it. Since those individual parties most likely also contribute in some way in the cooperative then some cunning individual could state that the cooperative as a whole is a profit organization. Too much legal for this very non profit person to get involved with. Earnie |
From: techtonik <tec...@us...> - 2007-02-02 09:30:59
|
On 2/1/07, Earnie Boyd <ea...@us...> wrote: > Quoting techtonik <tec...@us...>: > > > > No, no, no. Google Code has a faciliy for hosting open source projects. > > * Project workspaces with simple membership controls > > * Version control via Subversion > > * Issue tracking > > * Mailing lists at groups.google.com > > * Wiki > > * Downloads > > FAQ: http://code.google.com/support/bin/topic.py?topic=10380 > > Example: http://code.google.com/p/airbag/ > > > > Appears to be a bit too controlling for my tastes. They do not allow Public Domain license anyway. > > > No custom web-site hosting, yep, but hence more easy to maintain. > > And from the two example links you give it rather ``suxx''. Beauty > must be in the eye of the beholder. Well, I mustn't use "web-site hosting" phrase at all, because they do not provide any web-site hosting services. The example page you've seen is a project page similar to http://sourceforge.net/projects/mingw/ but without ads and other unneeded stuff. Minimalism and simplicity, but no lack of design and stale information as it with MinGW web-page for now. > You dwell on the password bits (get over the fact that each account has > a password) and third party wiki can be added to the sight if needed. > Or we could easily add the bits to allow changes to certain content > types that we call a wiki. So an authenticated user is allowed to > change the content on a content type we call a wiki. I like that, > every user can modify it and revisions would be on for that type. Revisions are not the main idea. Cross-linking is the power. For revision system you may even use SVN (like Google Wiki does) and maintain everything in HTML (or MarkDown). Drupal is useful only because of edit form in browser. That doesn't mean I do not want to try it though. > > I like SVN and Google Groups, because they intuitive and make life easier > > in comparison with rivals. > > Just because you know it or perceive that it is better. Again, beauty > is in the eye of the beholder. Just because I tried. I am administering several mailman lists on SF, I also subscribed to some Yahoo groups and prefer Google Groups as the most appealing since the times of GoldED+TMail+FastEcho. It is very convenient to post directly from web-interface and yes, I am almost sold to it. ;) > > In short: > > 1. Port 80 and SSL also means that SVN is able to operate through proxies. > > > > And I've provided a link to help move your ssh connection to port 80. > Really, if you corporation doesn't want you accessing the ssh port > externally, then my guess is they probably don't like SVN very well > either. I would be amazed to see web-developer able to learn/use SSH+CVS+Putty I know about that stuff only because I develop some SourceForge projects and must read all the accompaniying documents. I'd never do these actions without clear understanding of security implications behind. I hope you will not expect all corporative contributors to pass through this initiation. > > 2. I've rarely used CVS from command line, because I find all its keys rather > > confusing. With SVN things are much better. > > Ahha, the crux of the problem with CVS is you don't know it. SVN is no > better. I've used both. I started with CVS and used it daily for some years through WinCVS. It was a a big step forward in sourcecoding. I've even written proof-of-concept implementation of CVS protocol with PHP and I must admit I wasted a lot of time debugging CVS options. The plan was to edit PHP documenation online and use CVS as backend, but it failed as technically non-feasible, unreliable and unsafe. I successfully migrated my last project from old washing powder to SVN and now my hair is soft and shining. I left PHP in CVS and now I am being eaten by Python bit-by-bit (not because of SVN, but because Python to PHP as SVN to CVS - i.e. has more optimistic future trends and is properly supported from community PoV). > > 3. I like tree-based commits or transactions, which make history > > really useful > > as you can see changes for different files at once (and do not need > > to specify > > each file in commit message manually). > > Uhm, you lost me. To commit changes with cvs I do ``cvs commit''. It > goes and looks at the changed files. Yes, but you need to compose commit message manually to indicate what was changed in each file, e.g. http://mingw.cvs.sourceforge.net/mingw/MinGW/MinGW_LICENSE.rtf?view=log or else you have no way to see what files were modified during commit. > CVS may be a little slower > because it uses flat text files instead of a DB like SVN but with CVS I > can do some manual corrections I cannot do with SVN. Also, with SVN > don't I have to copy the entire tree to another directory just to > create a branch. With CVS that tagging is internal to the code pieces. As I said below branching/tagging is the only tradeoff of SVN and it is for a reason. About manual corrections - you do not mean manual corrections to repository, do you? Could you tell what for do you need to do that? If you need to delete some empty directories from repository - SVN can do this by design. > > 4. SVN is less bandwidth consuming due to more advanced binary diff > > and remote access algorithms > > Maybe. Is that compared with using the CVS -z9 switch? No. With CVS you still have to transmit whole files over the network just to make a simple diff. In SVN you don't, because pristine copies are located in working copy on your HDD. To fairly compare the speed add SSH tunneling to this CVS operation and you could easily reach speed ratio of 1:100 if no more on simple diff. > > 5. No line ending problems > > CVS doesn't have line ending problems. It handles line endings the way > it is supposed to. The issues with line endings come from the > developers. But I suppose you think that ignoring line ending > differences is what a good tool is supposed to do. See the mingw lists > archives for the outcome of that debate. Very gracious from you side. I won't go for that, but just tell you that even faulty developers in Developer + SVN combination do not have any problems with line endings and the talk about that is meaningless in SVN world. > > http://www.google.com/search?q=why+CVS+is+better+than+SVN =) > > > > The only drawback is branch/tag system, but it is a good simplicity tradeoff. > > You haven't sold me on the simplicity. I have experience with both. I > consider the branch/tag one of the best reasons to stick with CVS. The only one reason to be correct. ;p > I don't have more than one repository of code to deal with on the server > side. SVN forces branching to be copied on the server side. > Yes, SVN branches are copied. You can do this remotely without the necessity to checkout any working copy at all (i.e. operating with URLs only). After that easily switch your working copy to it. I do not see any inconveniences in this scenario. You may copy branch inside of your working copy and send commited files over the network as usual. > >> > >> One of the reasons I keep pusing Drupal is that the content is database > >> driven. The content changes can be tracked with revisions. We could > >> supply MinGW developer blog pages and we can easily create our own > >> theme. We aggregate the SF news entries and the FRS changes. We could > >> even aggregate other news that is pertinent to MinGW and Windows. > > > > There is no better way to leave a negative impression about the > > project than deserted blog. =) All other things sound good. > > > People tend to like history. :) Negative impressions. Impressions > like beauty are in the eye of the beholder. :p If it is that > bothersome some editor can easily disable the content. So far I can see only two persons in this list who could generate a reasonable amount of traffic to feed the blog and one of them is hereby stating at 95% probability that he will not be able to keep that pace in the future. =) > >> We currently have htdocs in CVS. We accept patches for those in the > >> patch tracker. We apply automated changes to trial/htdocs so that > >> interested editores (we used to have more than one) could give a vote > >> for or against the change. > > > > This is errm.. what is the synonym for stupid? =) > > Thanks, I really appreciate being labeled stupid. You appreciation is invaluable, but unfortunately this epithet is designed for process - not for a person. > So you think the changes should go to production untried. How stupid is that? I > suppose you put your code into production without testing. Exactly - web-site changes should go directly to production unless there is a major risk of losing data or access. In a case something needs to be fixed and I do not have time to fix something myself I try to expose the issue to extreme until me or somebody else will get finally annoyed to fix that. For resolution of the problem it is better to make the problem extremely annoying than to skip it. As for production code - I have a clear understanding of what production is and how critical it could be. At first "web-site" and "code" are very different things for MinGW. Second - site errors are annoying, but not critical - not for this project. For critical sites we usualy use some enterprise application monster and a test framework to track and detect incidents. > Man would I hate to live with the maintenance your production systems. You will hate it even before you could get appropriate clearance or qualifications to work in such hazardous conditions. =) Most of the systems we design work automatically and require only supervisory control. Needless to say what they are checked several times and people definitely know what to look for at first place and what could/should be fixed during commissioning and test operation. No dangerous cpp coding is involved - only specialized CAD-like instruments. Stable and conservative. Oh, I hate some. > > And trial/htdocs prevented the bad code from reaching the masses. The > editor would log onto the shell server and install into production > manually using ``cvs update foo'' commands. > As you may see editor works only in theory. > >> As I've already said MinGW editorialism has > >> nearly vanished and no one has really stepped up to take on the task. > > > > Must be completely vanished with no editorialism at all until serious > > conflicts among developers. =) > > > > No editor, no changes to stable content. Stable content.. heh. =) Stable content == dead content. It is a website - not a book or critical GCC code to kill people if misused properly. Web-site "development" and design is different - it needs feedback and appreciation from audience - not from editorial. Design is an art, when coding is an addiction. My PoV, of course. =) -- --t. |
From: Earnie B. <ea...@us...> - 2007-02-02 13:32:41
|
Quoting techtonik <tec...@us...>: > >> >> We currently have htdocs in CVS. We accept patches for those in the >> >> patch tracker. We apply automated changes to trial/htdocs so that >> >> interested editores (we used to have more than one) could give a vote >> >> for or against the change. >> > >> > This is errm.. what is the synonym for stupid? =) >> >> Thanks, I really appreciate being labeled stupid. > > You appreciation is invaluable, but unfortunately this epithet is > designed for process - not for a person. > People create processes. >> So you think the changes should go to production untried. How >> stupid is that? I >> suppose you put your code into production without testing. > > Exactly - web-site changes should go directly to production unless > there is a major risk of losing data or access. In a case something > needs to be fixed and I do not have time to fix something myself I try > to expose the issue to extreme until me or somebody else will get > finally annoyed to fix that. For resolution of the problem it is > better to make the problem extremely annoying than to skip it. > > As for production code - I have a clear understanding of what > production is and how critical it could be. At first "web-site" and > "code" are very different things for MinGW. Second - site errors are > annoying, but not critical - not for this project. For critical sites > we usualy use some enterprise application monster and a test framework > to track and detect incidents. > If only. >> Man would I hate to live with the maintenance your production systems. > > You will hate it even before you could get appropriate clearance or > qualifications to work in such hazardous conditions. =) Most of the > systems we design work automatically and require only supervisory > control. Needless to say what they are checked several times and > people definitely know what to look for at first place and what > could/should be fixed during commissioning and test operation. No > dangerous cpp coding is involved - only specialized CAD-like > instruments. Stable and conservative. Oh, I hate some. > >> >> And trial/htdocs prevented the bad code from reaching the masses. The >> editor would log onto the shell server and install into production >> manually using ``cvs update foo'' commands. >> > As you may see editor works only in theory. > No editor, no changes; no commits to CVS, no changes. The only difference at the moment I'm aware of between trial/htdocs and htdocs production is the CSS file. >> >> As I've already said MinGW editorialism has >> >> nearly vanished and no one has really stepped up to take on the task. >> > >> > Must be completely vanished with no editorialism at all until serious >> > conflicts among developers. =) >> > >> >> No editor, no changes to stable content. > > Stable content.. heh. =) Stable content == dead content. It is a > website - not a book or critical GCC code to kill people if misused > properly. Web-site "development" and design is different - it needs > feedback and appreciation from audience - not from editorial. Design > is an art, when coding is an addiction. My PoV, of course. =) > There currently is no editor to take charge of changes to the website. No one to making changes == no editor == dead content. If someone wants to control the website content let him or her speak up. No one has stepped forth. No changes are made. No content will change without someone changing the content. Regardless of the process if no changes are being given, it doesn't matter where the changes are being made. Who wants to take control of the website changes. Please somebody stop my madness. Anatoly, IIRC I have given you access to the mingw user shell account to make changes. Make them. Oh, that's right, I forgot, you don't do SSH. Earnie |
From: Earnie B. <ea...@us...> - 2007-02-02 12:37:52
|
Quoting techtonik <tec...@us...>: > > Revisions are not the main idea. Cross-linking is the power. For > revision system you may even use SVN (like Google Wiki does) and > maintain everything in HTML (or MarkDown). Drupal is useful only > because of edit form in browser. That doesn't mean I do not want to > try it though. > See my links at http://del.icio.us/earnie/wiki if you're interested. Earnie |
From: Earnie B. <ea...@us...> - 2007-02-02 12:43:19
|
Quoting techtonik <tec...@us...>: >> > I like SVN and Google Groups, because they intuitive and make life easier >> > in comparison with rivals. >> >> Just because you know it or perceive that it is better. Again, beauty >> is in the eye of the beholder. > > Just because I tried. I am administering several mailman lists on SF, > I also subscribed to some Yahoo groups and prefer Google Groups as the > most appealing since the times of GoldED+TMail+FastEcho. It is very > convenient to post directly from web-interface and yes, I am almost > sold to it. ;) > I'm using a web form to post to this list. Others have used nabble or some other service to post to mingw-users. So, please don't try to sell me on other clients. Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Earnie B. <ea...@us...> - 2007-02-02 13:18:41
|
Quoting techtonik <tec...@us...>: >> >> And I've provided a link to help move your ssh connection to port 80. >> Really, if you corporation doesn't want you accessing the ssh port >> externally, then my guess is they probably don't like SVN very well >> either. > > I would be amazed to see web-developer able to learn/use SSH+CVS+Putty > I know about that stuff only because I develop some SourceForge > projects and must read all the accompaniying documents. I'd never do > these actions without clear understanding of security implications > behind. I hope you will not expect all corporative contributors to > pass through this initiation. > There are several hundred web-developer type using CVS daily but neither of us have proof one way or another. And yes, if you join a coooperative group that has established practice then you must be initiated and broken into submission of the standard for that cooperative. >> > 2. I've rarely used CVS from command line, because I find all its >> keys rather >> > confusing. With SVN things are much better. >> >> Ahha, the crux of the problem with CVS is you don't know it. SVN is no >> better. I've used both. > > I started with CVS and used it daily for some years through WinCVS. It > was a a big step forward in sourcecoding. I've even written > proof-of-concept implementation of CVS protocol with PHP and I must > admit I wasted a lot of time debugging CVS options. The plan was to > edit PHP documenation online and use CVS as backend, but it failed as > technically non-feasible, unreliable and unsafe. I successfully > migrated my last project from old washing powder to SVN and now my > hair is soft and shining. I left PHP in CVS and now I am being eaten > by Python bit-by-bit (not because of SVN, but because Python to PHP as > SVN to CVS - i.e. has more optimistic future trends and is properly > supported from community PoV). > And we further are enlightened into your sourness toward CVS. Tens of hundred thousands of man years have been put into using and supporting CVS. It is still a viable tool. Just because a different politician comes along I'm not going to go jump on his band wagon. We've managed with CVS I see no reason to jump on the SVN band wagon. And everyone else has said to remain with CVS. >> > 3. I like tree-based commits or transactions, which make history >> > really useful >> > as you can see changes for different files at once (and do not need >> > to specify >> > each file in commit message manually). >> >> Uhm, you lost me. To commit changes with cvs I do ``cvs commit''. It >> goes and looks at the changed files. > > Yes, but you need to compose commit message manually to indicate what > was changed in each file, e.g. > http://mingw.cvs.sourceforge.net/mingw/MinGW/MinGW_LICENSE.rtf?view=log > or else you have no way to see what files were modified during commit. > I am asked once for a commit message for all the changed files. CVS opens a vi session and I read into a separate buffer the ChangeLog and copy the ChangeLog entry of the changes and paste it into the output buffer. I exit the vi session and all commits are performed. A differences is mailed to mingw-cvs list and I know what has been modfied in whole. >> CVS may be a little slower >> because it uses flat text files instead of a DB like SVN but with CVS I >> can do some manual corrections I cannot do with SVN. Also, with SVN >> don't I have to copy the entire tree to another directory just to >> create a branch. With CVS that tagging is internal to the code pieces. > > As I said below branching/tagging is the only tradeoff of SVN and it > is for a reason. But I like CVS style branching/tagging it saves on my server resources. > About manual corrections - you do not mean manual corrections to > repository, do you? Yes. > Could you tell what for do you need to do that? If you need to delete > some empty directories from repository - SVN can do this by design. > No, empty directories are not my concern. I'm not going to continue to defend this. >> > 4. SVN is less bandwidth consuming due to more advanced binary diff >> > and remote access algorithms >> >> Maybe. Is that compared with using the CVS -z9 switch? > > No. With CVS you still have to transmit whole files over the network > just to make a simple diff. In SVN you don't, because pristine copies > are located in working copy on your HDD. To fairly compare the speed > add SSH tunneling to this CVS operation and you could easily reach > speed ratio of 1:100 if no more on simple diff. > Ok. >> > 5. No line ending problems >> >> CVS doesn't have line ending problems. It handles line endings the way >> it is supposed to. The issues with line endings come from the >> developers. But I suppose you think that ignoring line ending >> differences is what a good tool is supposed to do. See the mingw lists >> archives for the outcome of that debate. > > Very gracious from you side. I won't go for that, but just tell you > that even faulty developers in Developer + SVN combination do not have > any problems with line endings and the talk about that is meaningless > in SVN world. > So in the SVN world I have files that are \r\n formatted. If I check them out in UNIX do they remain \r\n formatted or are they converted to \n formatted? If they convert then it is not correct because I believe the \r\n format needs to be preserved even in UNIX. Not all files stored in a repository are code files that get read by a compiler. >> > http://www.google.com/search?q=why+CVS+is+better+than+SVN =) >> > >> > The only drawback is branch/tag system, but it is a good >> simplicity tradeoff. >> >> You haven't sold me on the simplicity. I have experience with both. I >> consider the branch/tag one of the best reasons to stick with CVS. > > The only one reason to be correct. ;p > At least. :) >> I don't have more than one repository of code to deal with on the server >> side. SVN forces branching to be copied on the server side. >> > Yes, SVN branches are copied. You can do this remotely without the > necessity to checkout any working copy at all (i.e. operating with > URLs only). After that easily switch your working copy to it. I do not > see any inconveniences in this scenario. You may copy branch inside of > your working copy and send commited files over the network as usual. > SVN branches are multiple trees on the SERVER side as well as the CLIENT side. CVS branches only maintain one SERVER side tree. On the CLIENT side the user must have different copies for different branches just like for SVN. The multiple trees on the SERVER side has an easier visual effect but with several branches and releases over the course of an applications life it could be burdensome to deal with. Earnie |
From: techtonik <tec...@us...> - 2007-02-05 09:20:02
|
On 2/2/07, Earnie Boyd <ea...@us...> wrote: > Quoting techtonik <tec...@us...>: > > There are several hundred web-developer type using CVS daily but > neither of us have proof one way or another. And yes, if you join a > coooperative group that has established practice then you must be > initiated and broken into submission of the standard for that > cooperative. In my world the ratio of web developers aware of CVS to the ones who uploads site by FTP and maintains history in .zip files is about 1:20 For SVN it is about 4:20, where two were enlightened during my last year campaign. ;p SVN is much more easier to learn and to explain (thanks to SVN book) given the same amount of motivation. > And we further are enlightened into your sourness toward CVS. Tens of > hundred thousands of man years have been put into using and supporting > CVS. It is still a viable tool. Just because a different politician > comes along I'm not going to go jump on his band wagon. We've managed > with CVS I see no reason to jump on the SVN band wagon. And everyone > else has said to remain with CVS. Isn't it a true democracy, is it? =) I am not convincing you to switch to SVN, but to consider its awesome features. In spite of everything being moved to sourceware I could see the benefits in migrating windows installer on SourceForge's SVN - at a least a small model to try out. > >> > 3. I like tree-based commits or transactions, which make history > >> > really useful > >> > as you can see changes for different files at once (and do not need > >> > to specify > >> > each file in commit message manually). > >> > >> Uhm, you lost me. To commit changes with cvs I do ``cvs commit''. It > >> goes and looks at the changed files. > > > > Yes, but you need to compose commit message manually to indicate what > > was changed in each file, e.g. > > http://mingw.cvs.sourceforge.net/mingw/MinGW/MinGW_LICENSE.rtf?view=log > > or else you have no way to see what files were modified during commit. > > > > I am asked once for a commit message for all the changed files. CVS > opens a vi session and I read into a separate buffer the ChangeLog and > copy the ChangeLog entry of the changes and paste it into the output > buffer. I exit the vi session and all commits are performed. A > differences is mailed to mingw-cvs list and I know what has been > modfied in whole. Command line SVN works just the same - you can specify any editor you like, add hook scripts to send mail and do other weird things etc. It is somehow irrelevant to CVS vs SVN and more like post-commit code review for best practices, but -- I'd say that Changelog entries are not suitable for commit logs. In Changelog you need an overview for each released revision, in commit message - exact explanation of why this modification has been made. If you browse the history for mingw.nsi - http://mingw.cvs.sourceforge.net/mingw/MinGW/mingw.nsi?view=log there is a lot of irrelevant information for this file like "* MinGW_LICENSE.rtf: Update version". It is convenient to get only relevant log entries for particular file when looking its own log entries, but it is also convenient to view what other files are modified in this revision. SVN does this automatically (have I already said that before?). E.g. http://colorer.svn.sourceforge.net/viewvc/colorer?view=rev&revision=880 > > As I said below branching/tagging is the only tradeoff of SVN and it > > is for a reason. > > But I like CVS style branching/tagging it saves on my server resources. > The trailing wagon is not from this train - better admit you just like it. =) It won't be hard to get addicted to SVN as well. As for disk space - SVN doesn't copy every files when you create branches. Branch is an ordinary directory and copy operation in a repository is like a hard link if no changes are made. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.using.create.dia-1 (it's a big file, so be careful) > So in the SVN world I have files that are \r\n formatted. If I check > them out in UNIX do they remain \r\n formatted or are they converted to > \n formatted? If they convert then it is not correct because I believe > the \r\n format needs to be preserved even in UNIX. Not all files > stored in a repository are code files that get read by a compiler. Exactly. All files are treated as binary (and hence binary diff is used to store them) and by default no keyword expansion is made. But you can add this if you want, including required EOL behaviour. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.forcvs.binary-and-trans > >> I don't have more than one repository of code to deal with on the server > >> side. SVN forces branching to be copied on the server side. > >> > > Yes, SVN branches are copied. You can do this remotely without the > > necessity to checkout any working copy at all (i.e. operating with > > URLs only). After that easily switch your working copy to it. I do not > > see any inconveniences in this scenario. You may copy branch inside of > > your working copy and send commited files over the network as usual. > > > > SVN branches are multiple trees on the SERVER side as well as the > CLIENT side. CVS branches only maintain one SERVER side tree. On the > CLIENT side the user must have different copies for different branches > just like for SVN. The multiple trees on the SERVER side has an easier > visual effect but with several branches and releases over the course of > an applications life it could be burdensome to deal with. > SVN branches are ordinary directory trees in the same repository. Nothing more, nothing less. It depends of best practices to treat them as branches. Usually that means you have these three separate directories at the root for trunk, tags and branches, but you may have them anywhere. Making a branch is ordinary copy - just a hard link in a repository. As ordinary directories they share the same repository wide revision numbers for commits and that bugged me for some time, but now I do not pay much attention on it at all. It is possible to checkout and work with any subtree of SVN repository and to quickly "switch" between them. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.ref.svn.c.switch -- --t. |
From: Hin-Tak L. <hin...@ya...> - 2007-02-05 00:15:23
|
Earnie Boyd wrote: > Quoting techtonik <tec...@us...>: > >> On 1/31/07, Earnie Boyd <ea...@us...> wrote: <snipped> >>> We currently have htdocs in CVS. We accept patches for those in the >>> patch tracker. We apply automated changes to trial/htdocs so that >>> interested editores (we used to have more than one) could give a vote >>> for or against the change. >> This is errm.. what is the synonym for stupid? =) > > Thanks, I really appreciate being labeled stupid. So you think the > changes should go to production untried. How stupid is that? I > suppose you put your code into production without testing. Man would I > hate to live with the maintenance your production systems. When we had > editors the trial/htdocs was a peer to peer approval before production. > The peers have left and no one has blazed me with I want to be the > editor, may I please take control. > >> From what I've seen >> trial/htdocs contain exactly the changes needed to be present on the >> site. > > Yes, I have stated we do not have an editor to take the changes into > production. No editor responsible, no changes to the production > environment. > <snipped> > > And trial/htdocs prevented the bad code from reaching the masses. The > editor would log onto the shell server and install into production > manually using ``cvs update foo'' commands. > >>> As I've already said MinGW editorialism has >>> nearly vanished and no one has really stepped up to take on the task. >> Must be completely vanished with no editorialism at all until serious >> conflicts among developers. =) >> > > No editor, no changes to stable content. > <snipped> I kind of agree with techtonik - I am sorry, I read the above paragraphs as when Earnie wrote "peer to peer approval before production", "editors", he more or less meant "my approval" or "my secretary". The whole point of delegating a piece of work (and a piece of *volunteer* work as that) to somebody is that you trust the "best judgement" of the person responsible for it (and not watch over his shoulder for every key stroke, or "micro-manage"); and the best reward for volunteer work is the appreciation from the community that one has done a good job - that means ownership of the work, for better or worse. One is constantly seeking "meaning", partcularly where no money/fame is changing hand. Do you think these "editors" want to be watched over for every move? I think you had a valid argument that 'no code/html should go into production untested', but OTOH, in 'production system', you trust your colleagues and co-workers to do their job properly to their best judgement, *without you watching over their shoulder*; a production system allow for sickness, the occasional screw-ups and somebody not doing his or her job correctly and another person needs to step in and perform corrective measures, sometimes people even get fired for screwing up too many times, but... if you have the choice of two companies to work for, everything being equal, one has a policy of watch over your every key stroke and log every web site you ever visited; and substitute that with, you have some spare some in the evening and or looking for some intellectual challenges or needed some piece of open-source project to fill a gap, one open-source project has somebody watching every keystroke you commit, and another project doesn't, everything being equal, which one do you want to participate in? Particularly for these unattractive/unglamourous(?) tasks like web site maintenance - if somebody shows up with even the slightest interest, the best strategy is, *let* him/her do it. Trying to get him/her to obtain your micro-approval, IMHO, is a lot of discouragement. HTL ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html |
From: Earnie B. <ea...@us...> - 2007-02-05 14:19:08
|
Quoting Hin-Tak Leung <hin...@ya...>: > <snipped> > > I kind of agree with techtonik - I am sorry, I read the above paragraphs as > when Earnie wrote "peer to peer approval before production", "editors", he > more or less meant "my approval" or "my secretary". > Fine, you can peer to peer with techtonik to change it. No one is submitting changes. No changes I am deaf to the argument. Earnie |
From: techtonik <tec...@us...> - 2007-02-05 09:26:03
|
On 2/2/07, Earnie Boyd <ea...@us...> wrote: > > I'm using a web form to post to this list. Others have used nabble or > some other service to post to mingw-users. So, please don't try to > sell me on other clients. > Where is this form? Nabble looks ok. Why not to add it to official references for those who prefer groups instead of mail list? > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr > -- --t. |
From: Earnie B. <ea...@us...> - 2007-02-05 15:14:59
|
Quoting techtonik <tec...@us...>: > On 2/2/07, Earnie Boyd <ea...@us...> wrote: >> >> I'm using a web form to post to this list. Others have used nabble or >> some other service to post to mingw-users. So, please don't try to >> sell me on other clients. >> > > Where is this form? My own implementation of Horde/IMP. > Nabble looks ok. Why not to add it to official > references for those who prefer groups instead of mail list? > Because, no patches, no maintenance. I don't have time to keep up with the changes. Earnie |
From: techtonik <tec...@us...> - 2007-02-05 09:44:08
|
On 2/2/07, Earnie Boyd <ea...@us...> wrote: > Quoting techtonik <tec...@us...>: > > > > > Revisions are not the main idea. Cross-linking is the power. For > > revision system you may even use SVN (like Google Wiki does) and > > maintain everything in HTML (or MarkDown). Drupal is useful only > > because of edit form in browser. That doesn't mean I do not want to > > try it though. > > > > See my links at http://del.icio.us/earnie/wiki if you're interested. > I am not very interested in development, but glad to see something developed. Still it seems to be too young for production use and I haven't found any schemes for spam protection (except they are built-in in Drupal). It is impossible to estimate for how long this project will survive, but it is in active development and new MinGW site can serve as a great testbed with all amount of information already available. I think you should ask if somebody is interested to help us. Unfortunately, my vacation is almost over and I am unlikely to provide any help except for migration of data from old Wiki format to the New one. Feel free to mail me directly when the time comes. -- --t. |
From: Earnie B. <ea...@us...> - 2007-02-05 16:10:52
|
Quoting techtonik <tec...@us...>: > > Unfortunately, my vacation is almost over and I am unlikely to provide > any help except for migration of data from old Wiki format to the New > one. Feel free to mail me directly when the time comes. > Typical. Earnie |
From: techtonik <tec...@us...> - 2007-02-05 19:56:29
|
On 2/5/07, Earnie Boyd <ea...@us...> wrote: > > Unfortunately, my vacation is almost over and I am unlikely to provide > > any help except for migration of data from old Wiki format to the New > > one. Feel free to mail me directly when the time comes. > > > > Typical. Do you have an alternative plan how to reach financial independence? =) -- --t. |
From: Keith M. <kei...@us...> - 2007-02-14 21:51:40
|
On Thursday 01 February 2007 13:35, Earnie Boyd wrote: > > If you have extra free space in your Palm IIIc, try this book - it > > really rocks. > > http://svnbook.red-bean.com/nightly/en/svn-book.html > > You have more toys that I do. I think he's referring to *my* Palm IIIc; he's so tied up in trying to push= =20 his *minority* (of one on this list) POV, that he couldn't even be bothered= =20 to remember who he's corresponding with! In fact, he's trying to restart the war he's already lost; I'm so heartily= =20 sick of his interminable whingeing, that I'm just not listening any more. =46rom my POV, the CVS vs SVN issue is closed, unless a *democratic* majori= ty of=20 MinGW Developers ask for the change. So far, I've heard one voice bleating= =20 in the wilderness. Techtonic, you lost that war; CVS won, and it's time yo= u=20 stopped carping. Regards, Keith. |
From: techtonik <tec...@us...> - 2007-02-14 22:31:46
|
On 2/15/07, Keith Marshall <kei...@us...> wrote: > > I think he's referring to *my* Palm IIIc; he's so tied up in trying to push > his *minority* (of one on this list) POV, that he couldn't even be bothered > to remember who he's corresponding with! Sorry, there are two girls and only that fact confuses me. =) Happy Valentines Day! ;) > In fact, he's trying to restart the war he's already lost; I'm so heartily > sick of his interminable whingeing, that I'm just not listening any more. I'm still here so there is no reason to talk about me like I am already dead in public. > >From my POV, the CVS vs SVN issue is closed, unless a *democratic* majority of > MinGW Developers ask for the change. So far, I've heard one voice bleating > in the wilderness. Techtonic, you lost that war; CVS won, and it's time you > stopped carping. Its over if it was a war ever. Just an intrusive probe to calm my conscience to go alone with installer. :-p ..and put some more arguments to the CVS part of the scales for research. I must admit I failed or "lost the war" if you put it this way. -- --t. |
From: Earnie B. <ea...@us...> - 2007-01-30 13:55:30
|
Quoting techtonik <tec...@us...>: > The stuff with File Release System on SF will not be fixed. Unfortunately. > I am aware that what SF believes to be the way to use its FRS isn't satisfactory for our design of its use. The FRS display has gotten really ugly with the way we perceive it should be used. We are using what SF calls a package as a release type and what SF calls a release as a package. I have been contemplating the correct words to send of to SF in my dislike for the development of the SF UI. Ajax is all the rage and that rage is really getting in the way of usefulness. If SF used Open Source techniques for its Open Source foundation it would have a higher regard in the industry. SF has been good but I fear that others are beginning to move away because of the corporate politics being played. To fix the issue SF would have to implement a Feature Request that I opened years ago to allow sub projects to be created. We would then open a sub project for each package just so that we could use the FRS correctly. At one time we had the packages arranged with the package as a package and each had it own release. The issue with that is you have too many packages. I've asked about this before; but should we reverse our logic again? > ---------- Forwarded message ---------- > From: SourceForge.net <no...@so...> > Date: Jan 29, 2007 11:46 PM > Subject: [ alexandria-Support Requests-1647115 ] Package listing hides > important releases > To: no...@so... > > > Support Requests item #1647115, was opened at 2007-01-29 08:57 > Message generated for change (Comment added) made by fincher > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1647115&group_id=1 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: SF.net File Release System >> Group: Second Level Support >> Status: Closed > Priority: 5 > Private: No > Submitted By: anatoly techtonik (techtonik) >> Assigned to: Jeremy Fincher (fincher) > Summary: Package listing hides important releases > > Initial Comment: > New file release design hides important files from users. > Take a look at our MinGW project. > > http://sourceforge.net/project/showfiles.php?group_id=2435 > > We have several packages ranged on maturity status. Each package > (Current, Candidate, etc.) contains several releases of various tools. > Unfortunately only last three releases (tools) are displayed for each > package and developers need to make additional step following a link > to "view older releases". > > Is it possible to fully expand package releases for this project? > http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721 > > In case of automated scenario or universal solution if manual > intervention is not possible I could propose hide older releases only > if they have similar names and different versions. > > > ---------------------------------------------------------------------- > >> Comment By: Jeremy Fincher (fincher) > Date: 2007-01-29 16:46 > > Message: > Logged In: YES > user_id=1019020 > Originator: NO > > Greetings, > > Unfortunately, what you're asking for is not possible. The issue, > however, exists because you're not using the File Release System (FRS) as > intended. Each "release" that you currently have should be a "package," > and different versions (current, candidate, etc.) should be a "release" > for its particular package. > > SourceForge.net Support > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1647115&group_id=1 > > > -- > --t. > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr > Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Greg C. <chi...@co...> - 2007-01-30 15:10:18
|
On 2007-1-30 13:55 UTC, Earnie Boyd wrote: > > [...] If SF > used Open Source techniques for its Open Source foundation it would > have a higher regard in the industry. IIRC, the sf software was "open source" originally, but current versions are no longer, so it's been forked, e.g.: https://savannah.gnu.org/ https://gna.org/ https://savannah.cern.ch/ I use savannah.gnu.org for my own work. I'm very pleased with their service (it's really the gna.org people who run it, AFAICT). Then again, I share their philosophy, and anyone who doesn't would be unhappy there. Yet cjf has offered us sourceware.org facilities as an alternative. [some history about MinGW and sf snipped] > > I've asked about this before; but should we reverse our logic again? I guess our options are - live with the current problems - adapt to the way sf feels everything should work today - move elsewhere, e.g., sourceware.org I think moving elsewhere is the best long-term solution. I guess a piecemeal migration has already begun anyway, with cvs. Would it be a lot of work to move released files there next, if that's acceptable to sourceware.org? |
From: Earnie B. <ea...@us...> - 2007-01-30 16:43:14
|
Quoting Greg Chicares <chi...@co...>: > > Yet cjf has offered us sourceware.org facilities as an alternative. > > [some history about MinGW and sf snipped] >> >> I've asked about this before; but should we reverse our logic again? > > I guess our options are > - live with the current problems > - adapt to the way sf feels everything should work today > - move elsewhere, e.g., sourceware.org > I think moving elsewhere is the best long-term solution. I guess > a piecemeal migration has already begun anyway, with cvs. Would > it be a lot of work to move released files there next, if that's > acceptable to sourceware.org? > I ran out of time to look at doing this. I had started looking at the ezmlm users admin manual and just simply didn't have time to move it further. Chris had set up a mingw-dvlpr list for Keith and I to play with. As far as the CVS migration you speak of, mingw runtime and w32api have always been a part of Cygwin since their creation. As far as the files themselves Chris has given us ftp access and an htdocs area. The problem of course is the management of the move. I do not have time to be involved with the move. Greg are you offering your time to coordinate this effort, if yes I can support this? If we could get a MySql DB on sourceware.org we could use Drupal with its project module to control the bugs, etc for each package we offer. Earnie |
From: Greg C. <chi...@co...> - 2007-01-31 04:07:46
|
On 2007-1-30 16:43 UTC, Earnie Boyd wrote: > Quoting Greg Chicares <chi...@co...>: > >> Yet cjf has offered us sourceware.org facilities as an alternative. >> >> [some history about MinGW and sf snipped] >>> I've asked about this before; but should we reverse our logic again? >> I guess our options are >> - live with the current problems >> - adapt to the way sf feels everything should work today >> - move elsewhere, e.g., sourceware.org >> I think moving elsewhere is the best long-term solution. I guess >> a piecemeal migration has already begun anyway, with cvs. Would >> it be a lot of work to move released files there next, if that's >> acceptable to sourceware.org? > > I ran out of time to look at doing this. I had started looking at the > ezmlm users admin manual and just simply didn't have time to move it > further. Chris had set up a mingw-dvlpr list for Keith and I to play > with. As far as the CVS migration you speak of, mingw runtime and > w32api have always been a part of Cygwin since their creation. As far > as the files themselves Chris has given us ftp access and an htdocs > area. The problem of course is the management of the move. > > I do not have time to be involved with the move. Greg are you offering > your time to coordinate this effort, I need to know more about what it would take, and also what others think--for instance, techtonik has presented contrary arguments. > if yes I can support this? If we > could get a MySql DB on sourceware.org we could use Drupal with its > project module to control the bugs, etc for each package we offer. We've got several things: released files mailing lists defect and patch trackers the wiki web pages and I figure we could move one thing at a time (assuming there's a consensus to move them). Released files are the topic of the moment. I examine ftp://ftp.cygwin.com/pub/bzip2/v01pl2 for example, and it looks pretty simple. Moving the old files over is a bunch of work, and it has to be done painstakingly, but it only needs to be done once. I don't see why I couldn't handle it. What am I missing? If some php thing like http://sourceforge.net/project/showfiles.php?group_id=2435 is viewed as essential, then that's outside my experience. The only other thing that really bothers me is the mailing lists: advertising added to each message, and unreliable search tools. I wouldn't mind giving a hand there, either--I manage a (low-volume) mailman list already, and ezmlm seems roughly the same. But what does the task entail? Just setting up the lists? Moderating them actively, say, to delete spam? Moving the list archives (which was not done when we moved from egroups to sf)? |
From: techtonik <tec...@us...> - 2007-01-30 20:27:54
|
On 1/30/07, Greg Chicares <chi...@co...> wrote: > I use savannah.gnu.org for my own work. I'm very pleased with their > service (it's really the gna.org people who run it, AFAICT). Then > again, I share their philosophy, and anyone who doesn't would be > unhappy there. > > Yet cjf has offered us sourceware.org facilities as an alternative. My first impression about sourceware.org is "that's suxx", sorry. =) Lots of text and absolutely no design. I do not know what is inside though. I'd like to use Google Code, but they possess all sorts of prejudices about Public Domain projects. There are also no pretty statistical charts or comparative download ratings at Google's, but downloads are rather progressive - you can assign different tags to them to sort as you wish. > [some history about MinGW and sf snipped] > > > > I've asked about this before; but should we reverse our logic again? > > I guess our options are > - live with the current problems > - adapt to the way sf feels everything should work today > - move elsewhere, e.g., sourceware.org > I think moving elsewhere is the best long-term solution. I guess > a piecemeal migration has already begun anyway, with cvs. Would > it be a lot of work to move released files there next, if that's > acceptable to sourceware.org? I am afraid it will not be beneficial for MinGW to move from SF where it once deserved POM status. It is more convenient to have one login for different projects and contributors are more accustomed to SF than to any kind of SourceWare, Berlios, GNA etc. Even the download system of SF has some positive aspects like load balancing and statistics (but is limited nevertheless). I do not mind migrating MinGW/MSYS CVS to SourceWare and leaving only SVN for the development of installer, but it seems more important to concentrate on the web-site. Sensible and pleasant to look at guide at web-site with direct links to appropriate packages will do better job for people so that they will not have to struggle through SF or SW or GC or whatever repository interfaces. Links like http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721 look ok and do not arise any questions if provided from web pages different than initial FRS's. Without good looking site everything else is crutches. And of course you need to change your developers policy for web-site development, because now it is rather ridiculous from my POV. The most effective way to make something useful from it - apply all changes directly to the trunk and constantly sync the trunk with htdocs - what else do you need RCS for as not for rollback? If not convinced think about what is more important for the site at the moment - contributions or stability. If there is no another way I can provide hosting. Space is not a problem, but I need to look through security implications first and this could take time. One more thing - site should not be CPU intensive as it will be located in shared environment and not on a dedicated server. If test deployment on SF render site running rather fast I could consider it is not that CPU intensive. -- --t. |
From: Earnie B. <ea...@us...> - 2007-01-31 14:30:46
|
Quoting techtonik <tec...@us...>: >> Yet cjf has offered us sourceware.org facilities as an alternative. > > My first impression about sourceware.org is "that's suxx", sorry. =) You must bite the hand that feeds you. Sourceware.org is offering hosting services not middleware for that service. > Lots of text and absolutely no design. I don't know if you've had a look at www.mingw.org or not but it is mostly text with little design. > I do not know what is inside though. If you do not know then the best thing to do is to be silent about opinions and ask questions to learn. Chris' offer is nothing more than something similar to, we have a server with mail, MySql, ftp and apache services. We point www.mingw.org to the sourceware.org server and we develop the UI. > I'd like to use Google Code, but they possess all sorts of > prejudices about Public Domain projects. There are also no pretty > statistical charts or comparative download ratings at Google's, but > downloads are rather progressive - you can assign different tags to > them to sort as you wish. > I don't know what this has to do with MinGW. You learning others API on our behalf when our behalf isn't served by anything you've learned isn't anything I'm interested in giving you approval for. I'm not interested in serving AJAX from the MinGW pages. AJAX has many issues because it is mostly JavaScript and JavaScript is plaqued with if it is this browser you've gotta do this and if its that browser you gotta do that. Getting it correct isn't at all easy and since JavaScript is client based the code must be delivered to the client before rendering the page correctly. >> [some history about MinGW and sf snipped] >> > >> > I've asked about this before; but should we reverse our logic again? >> >> I guess our options are >> - live with the current problems >> - adapt to the way sf feels everything should work today >> - move elsewhere, e.g., sourceware.org >> I think moving elsewhere is the best long-term solution. I guess >> a piecemeal migration has already begun anyway, with cvs. Would >> it be a lot of work to move released files there next, if that's >> acceptable to sourceware.org? > > I am afraid it will not be beneficial for MinGW to move from SF where > it once deserved POM status. POM? http://acronyms.thefreedictionary.com/POM Which one do I pick? How about Playmate of the Month? No, you mean Project of the Month. ;p We would still leave the MinGW SF project open and redirect all traffic to the new site. MinGW/MSYS is considered by SF as an OS type so just to support those that have this ``artifact'' chosen for their project we would need to remain an active project. > It is more convenient to have one login > for different projects and contributors are more accustomed to SF than > to any kind of SourceWare, Berlios, GNA etc. Even the download system > of SF has some positive aspects like load balancing and statistics > (but is limited nevertheless). I'm not sure we're you're coming from, the user PoV or the developer PoV? Shell access is important only to those maintaining a) cron and b) some configuration item. CVS access is important only to those who maintain the code. There are only a few users who would be able to do either. > > I do not mind migrating MinGW/MSYS CVS to SourceWare and leaving only > SVN for the development of installer, CVS, SVN, any other code change management software are tools that when used properly produce the same results. So far the biggest plus I've heard tauted about SVN is that it uses port 80 and the SSL is self contained. Not a good enough reason for me to go switching from CVS to SVN. > but it seems more important to concentrate on the web-site. Yes it is important. > Sensible and pleasant to look at guide at > web-site with direct links to appropriate packages will do better job > for people so that they will not have to struggle through SF or SW or > GC or whatever repository interfaces. Links like > http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82721 > look ok and do not arise any questions if provided from web pages > different than initial FRS's. Without good looking site everything > else is crutches. It can be plain text for all I care. If the links are correct then the site is perfect. > > And of course you need to change your developers policy for web-site > development, because now it is rather ridiculous from my POV. Once upon a time a long time ago in the land when MinGW began we had editors that kept on top of the needed changes. As time progressed the editors grew old and were no longer available to take care of those needed changes. From *my PoV* no one else was interested enough to find the time to maintain it. Their have been some sheepish attempts at presenting this or that but no one has roared in and wowed me with updates. > The most > effective way to make something useful from it - apply all changes > directly to the trunk and constantly sync the trunk with htdocs - what > else do you need RCS for as not for rollback? If not convinced think > about what is more important for the site at the moment - > contributions or stability. > One of the reasons I keep pusing Drupal is that the content is database driven. The content changes can be tracked with revisions. We could supply MinGW developer blog pages and we can easily create our own theme. We aggregate the SF news entries and the FRS changes. We could even aggregate other news that is pertinent to MinGW and Windows. We currently have htdocs in CVS. We accept patches for those in the patch tracker. We apply automated changes to trial/htdocs so that interested editores (we used to have more than one) could give a vote for or against the change. As I've already said MinGW editorialism has nearly vanished and no one has really stepped up to take on the task. > If there is no another way I can provide hosting. Space is not a > problem, but I need to look through security implications first and > this could take time. One more thing - site should not be CPU > intensive as it will be located in shared environment and not on a > dedicated server. > I'm not interested at all to moving to someone's private hosting. So, no, there is no way _you_ can provide hosting but thank you for the offer. Sourceware.org is kind enough to offer and we have yet to do that. We are stuck in our ways with the SF UI and change takes time that we have yet to find. Earnie |
From: techtonik <tec...@us...> - 2007-02-01 08:51:28
|
On 1/31/07, Earnie Boyd <ea...@us...> wrote: > > My first impression about sourceware.org is "that's suxx", sorry. =) > You must bite the hand that feeds you. Sourceware.org is offering > hosting services not middleware for that service. "Red Hat is pleased to provide sourceware.org, a site aimed at providing first-rate hosting of open source projects for software developers." Seems ok, if that means we shouldn't use their middleware and could install Drupal to manage it independently. Still I'd like to know if they might want something for that service? For example, SF wants buttons displayed on main page. Sometimes it is worth to check if the feeding hand is clean of drugs and there is no some suspictious trap mechanizm around. > If you do not know then the best thing to do is to be silent about > opinions and ask questions to learn. Chris' offer is nothing more than > something similar to, we have a server with mail, MySql, ftp and apache > services. We point www.mingw.org to the sourceware.org server and we > develop the UI. Sounds Ok. No shell? I.e. should we sync design or other web-site changes with RCS manually? > > I'd like to use Google Code, but they possess all sorts of > > prejudices about Public Domain projects. There are also no pretty > > statistical charts or comparative download ratings at Google's, but > > downloads are rather progressive - you can assign different tags to > > them to sort as you wish. > > I don't know what this has to do with MinGW. You learning others API > on our behalf when our behalf isn't served by anything you've learned > isn't anything I'm interested in giving you approval for. I'm not > interested in serving AJAX from the MinGW pages. No, no, no. Google Code has a faciliy for hosting open source projects. * Project workspaces with simple membership controls * Version control via Subversion * Issue tracking * Mailing lists at groups.google.com * Wiki * Downloads FAQ: http://code.google.com/support/bin/topic.py?topic=10380 Example: http://code.google.com/p/airbag/ No custom web-site hosting, yep, but hence more easy to maintain. It could be better than Drupal + MySQL + another two passwords to remember in case we will switch to SourceWare. One more reason is that AFAIK Drupal doesn't have any wiki embedded. I like SVN and Google Groups, because they intuitive and make life easier in comparison with rivals. > > I am afraid it will not be beneficial for MinGW to move from SF where > > it once deserved POM status. > > POM? http://acronyms.thefreedictionary.com/POM > Which one do I pick? How about Playmate of the Month? > No, you mean Project of the Month. ;p Exactly! ;) > I'm not sure we're you're coming from, the user PoV or the developer > PoV? Shell access is important only to those maintaining a) cron and > b) some configuration item. CVS access is important only to those who > maintain the code. There are only a few users who would be able to do > either. >From web-developers PoV. With SVN things are getting better and more simple. It is convenient to sync web-site from SVN and you need shell accound for that. > > > > I do not mind migrating MinGW/MSYS CVS to SourceWare and leaving only > > SVN for the development of installer, > > CVS, SVN, any other code change management software are tools that when > used properly produce the same results. So far the biggest plus I've > heard tauted about SVN is that it uses port 80 and the SSL is self > contained. Not a good enough reason for me to go switching from CVS to > SVN. If you have extra free space in your Palm IIIc, try this book - it really rocks. http://svnbook.red-bean.com/nightly/en/svn-book.html In short: 1. Port 80 and SSL also means that SVN is able to operate through proxies. 2. I've rarely used CVS from command line, because I find all its keys rather confusing. With SVN things are much better. 3. I like tree-based commits or transactions, which make history really useful as you can see changes for different files at once (and do not need to specify each file in commit message manually). 4. SVN is less bandwidth consuming due to more advanced binary diff and remote access algorithms 5. No line ending problems http://www.google.com/search?q=why+CVS+is+better+than+SVN =) The only drawback is branch/tag system, but it is a good simplicity tradeoff. > > And of course you need to change your developers policy for web-site > > development, because now it is rather ridiculous from my POV. > > Once upon a time a long time ago in the land when MinGW began we had > editors that kept on top of the needed changes. As time progressed the > editors grew old and were no longer available to take care of those > needed changes. From *my PoV* no one else was interested enough to > find the time to maintain it. Their have been some sheepish attempts > at presenting this or that but no one has roared in and wowed me with > updates. Web is so vague that nobody will be interested to make something what is required. It is not ANSI C code you write once and it works everywhere. Quite different - if you design something in IE, it is about 50/50 that it will look the same in Opera or FF. It is like art - if you have inspiration you experiment and then something good is born. Inspiration doesn't work if you need somebody's approval. Well, it usually works but until the first time in your life when somebody says "that suxx" even in polite manner. > > The most effective way to make something useful from it - apply all changes > > directly to the trunk and constantly sync the trunk with htdocs - what > > else do you need RCS for as not for rollback? > > One of the reasons I keep pusing Drupal is that the content is database > driven. The content changes can be tracked with revisions. We could > supply MinGW developer blog pages and we can easily create our own > theme. We aggregate the SF news entries and the FRS changes. We could > even aggregate other news that is pertinent to MinGW and Windows. There is no better way to leave a negative impression about the project than deserted blog. =) All other things sound good. > We currently have htdocs in CVS. We accept patches for those in the > patch tracker. We apply automated changes to trial/htdocs so that > interested editores (we used to have more than one) could give a vote > for or against the change. This is errm.. what is the synonym for stupid? =) From what I've seen trial/htdocs contain exactly the changes needed to be present on the site. There should be fast and easy way to commit changes (and to rollback as well) for everyone. An ideal variant is RCS sync - if site is broken and developer is not responding - you just rollback site to the previous version and enjoy. > As I've already said MinGW editorialism has > nearly vanished and no one has really stepped up to take on the task. Must be completely vanished with no editorialism at all until serious conflicts among developers. =) > > I'm not interested at all to moving to someone's private hosting. So, > no, there is no way _you_ can provide hosting but thank you for the > offer. Sourceware.org is kind enough to offer and we have yet to do > that. We are stuck in our ways with the SF UI and change takes time > that we have yet to find. > Ok. I understand. If we prove that this "organization" is non-profit under U.S. law, we could get completely independent commercial-quality hosting for the lifetime (although still shared plan). http://wiki.dreamhost.com/index.php/Non-profit_Discount Or else you must use this EXTRAGR8TPROMOCODE to get a 97$ discount!!! Just joking. =) -- --t. |