Folks,
For the first time we are in the first 30 downloads (position 29 :)) on SourceForge:
http://sourceforge.net/top/toplist.php?type=downloads_week
We need to make it to the fist 10, so we are always featured on the front page :) But we need to more than quadruple our downloads to achieve that. Alexandre, I think you need to release more often ;)
Dimitrie O. Paun a écrit:
Folks,
For the first time we are in the first 30 downloads (position 29 :)) on SourceForge:
http://sourceforge.net/top/toplist.php?type=downloads_week
We need to make it to the fist 10, so we are always featured on the front page :) But we need to more than quadruple our downloads to achieve that. Alexandre, I think you need to release more often ;)
I can help by making several small packages rather than a big one :)
More seriously, the machine I intended to use for RH9 has some HD problems (IBM 75GXP, not dead yet, but in critical condition). So it will be a couple weeks probably for me to get a replacement part.
Vincent
On Thu, 15 May 2003, Vincent Béron wrote:
More seriously, the machine I intended to use for RH9 has some HD problems (IBM 75GXP, not dead yet, but in critical condition). So it will be a couple weeks probably for me to get a replacement part.
That's too bad -- we really need RH9 packages. I have a RH9 box, I can compile stuff if you give me the .spec files + instructions.
Dimitrie O. Paun a écrit:
On Thu, 15 May 2003, Vincent Béron wrote:
More seriously, the machine I intended to use for RH9 has some HD problems (IBM 75GXP, not dead yet, but in critical condition). So it will be a couple weeks probably for me to get a replacement part.
That's too bad -- we really need RH9 packages. I have a RH9 box, I can compile stuff if you give me the .spec files + instructions.
I, know, but the devil's in the details :( It'll be a couple round trips, with "does it works now?" back and forth. The biggest problem I had in the one day I could use it was a weird difference in needed dependancies (libntdll.dll.so was listed as required, but not provided, so the package didn't want to install. RH8 gets it correctly though).
In the mid-time, I can try to get a 8.4GB back from another machine (just need to do a proper backup before), so I can return to it quickly.
Vincent
I can also get you a compile if you supply me with some instractions I have mandrake 9.1 and always get the latest cvs and tools mandrake update supplies....
And yes my mechine is up ~22/7 (the rest is windows gaming/testing :) ) and have a 24/7 net connection....
Hatky. --- "Dimitrie O. Paun" dimi@intelliware.ca wrote:
On Thu, 15 May 2003, Vincent B�on wrote:
More seriously, the machine I intended to use for
RH9 has some HD
problems (IBM 75GXP, not dead yet, but in critical
condition). So it
will be a couple weeks probably for me to get a
replacement part.
That's too bad -- we really need RH9 packages. I have a RH9 box, I can compile stuff if you give me the .spec files + instructions.
-- Dimi.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
Why not use the sourceforge compile farm to get some more releases and how about getting a live cvs version in there ....
Just getting some ideas, Hatky --- "Dimitrie O. Paun" dimi@intelliware.ca wrote:
Folks,
For the first time we are in the first 30 downloads (position 29 :)) on SourceForge:
http://sourceforge.net/top/toplist.php?type=downloads_week
We need to make it to the fist 10, so we are always featured on the front page :) But we need to more than quadruple our downloads to achieve that. Alexandre, I think you need to release more often ;)
-- Dimi.
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
hatky a écrit :
Why not use the sourceforge compile farm to get some more releases and how about getting a live cvs version in there ....
The CVS is fine where it is. SF also has some downtime, plus a limit on the number of concurrent anonymous users, plus there's only one person really commiting to our CVS.
As for the compile farm, I looked at it once, and IIRC, they have some older debian version for x86, plus a few others. No MDK, no RH.
VIncent
On Tue, 20 May 2003, Vincent Béron wrote:
The CVS is fine where it is. SF also has some downtime, plus a limit on the number of concurrent anonymous users, plus there's only one person really commiting to our CVS.
Moreover, we can't install our patch tools [1], and those are rather important IMO.
Le mar 20/05/2003 à 16:02, Dimitrie O. Paun a écrit :
On Tue, 20 May 2003, Vincent Béron wrote:
The CVS is fine where it is. SF also has some downtime, plus a limit on the number of concurrent anonymous users, plus there's only one person really commiting to our CVS.
Moreover, we can't install our patch tools [1], and those are rather important IMO.
Actually, it's possible to run something on each commit on sf. I'm not familiar enough with either system (winehq and sf), but it might be possible to coerce the tools to work on sf. The remaining point would be the storage space for all those patches, as IIRC there's a 100MB soft limit on web space usage by each project...
-- Dimi.
[1] The 'patch tools' are the scripts that give you the URLs in the wine-cvs mails to retrieve the patch, for example: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commit&id=8113
Vincent
On 20 May 2003, Vincent Béron wrote:
Actually, it's possible to run something on each commit on sf. I'm not familiar enough with either system (winehq and sf), but it might be possible to coerce the tools to work on sf. The remaining point would be the storage space for all those patches, as IIRC there's a 100MB soft limit on web space usage by each project...
There's no patch stored anywhere other than CVS -- the tools compute them on demand when you access the link. They do support storage of the patch for subsequent fast retrieval, but that feature is not used on WineHQ.
What about cvsup, do SF export the CVS repository through cvsup?
Le mar 20/05/2003 à 16:18, Dimitrie O. Paun a écrit :
On 20 May 2003, Vincent Béron wrote:
Actually, it's possible to run something on each commit on sf. I'm not familiar enough with either system (winehq and sf), but it might be possible to coerce the tools to work on sf. The remaining point would be the storage space for all those patches, as IIRC there's a 100MB soft limit on web space usage by each project...
There's no patch stored anywhere other than CVS -- the tools compute them on demand when you access the link. They do support storage of the patch for subsequent fast retrieval, but that feature is not used on WineHQ.
Ok, I thought it was generated once (when Alexandre applied it), then served back when asked for it.
What about cvsup, do SF export the CVS repository through cvsup?
From http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1: "Use of rsync, CVSup, etc. with SourceForge.net project CVS services is not currently supported."
So, no. Only daily tarballs of the whole repository.
Also note that I wasn't advocating such a change, more specifically the opposite :)
Vincent
On Tue, May 20, 2003 at 04:12:37PM -0400, Vincent Béron wrote:
Le mar 20/05/2003 à 16:02, Dimitrie O. Paun a écrit :
On Tue, 20 May 2003, Vincent Béron wrote:
The CVS is fine where it is. SF also has some downtime, plus a limit on the number of concurrent anonymous users, plus there's only one person really commiting to our CVS.
Moreover, we can't install our patch tools [1], and those are rather important IMO.
Actually, it's possible to run something on each commit on sf. I'm not familiar enough with either system (winehq and sf), but it might be possible to coerce the tools to work on sf. The remaining point would be the storage space for all those patches, as IIRC there's a 100MB soft limit on web space usage by each project...
Why change the current CVS setup? It is working just fine ...
Ciao, Marcus
-
Dimitrie O. Paun -
hatky -
Marcus Meissner -
Vincent Béron