From: Thiago A. <thi...@gm...> - 2006-01-02 14:24:21
|
Fellows, Now that the build scripts are up and running, maybe we can provide a live download page. This would let users download the very latest version of EclipseFP, with last minute changes. Does anybody know if we can use the sourceforge servers for building our project? If so, how? If not, is there another way? I have a personal server that could be used for building and then uploading the build, but it is a very slow machine (it takes about 8 minutes to fully build the project, while other machines take only 17 seconds!!). Besides that, there is also extra time required for uploading the file. I think the best solution would be to run the build on a SF server. But I don't know if that is possible. Particularly, the build requires an Eclipse installation, which I don't think we can have on the SF servers (or do we?). Cheers, Thiago Arrais |
From: Leif F. <hi...@le...> - 2006-01-03 23:11:26
|
> Now that the build scripts are up and running, maybe we can provide a > live download page. This would let users download the very latest > version of EclipseFP, with last minute changes. >=20 > Does anybody know if we can use the sourceforge servers for building > our project? If so, how? If not, is there another way? I have a > personal server that could be used for building and then uploading the > build, but it is a very slow machine (it takes about 8 minutes to > fully build the project, while other machines take only 17 seconds!!). > Besides that, there is also extra time required for uploading the > file. >=20 > I think the best solution would be to run the build on a SF server. > But I don't know if that is possible. Particularly, the build requires > an Eclipse installation, which I don't think we can have on the SF > servers (or do we?). Hm, there is this thing called the 'Compile Farm' on sf. I have never=20 used it, and I don't know what the terms of use are, but if we have an=20 automated process that just has to be uploaded, run, and then deleted, I=20 don't think there's a big problem. Maybe it is not allowed to run=20 regular builds too often, but once a day shouldn't be out of the normal. Ciao, Leif >=20 > Cheers, >=20 > Thiago Arrais >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop >=20 >=20 |
From: Thiago A. <thi...@gm...> - 2006-01-04 02:43:03
|
2006/1/3, Leif Frenzel <hi...@le...>: > Hm, there is this thing called the 'Compile Farm' on sf. I have never > used it, and I don't know what the terms of use are, but if we have an > automated process that just has to be uploaded, run, and then deleted, I > don't think there's a big problem. Maybe it is not allowed to run > regular builds too often, but once a day shouldn't be out of the normal. Good to know, I will take a look at it. For the time being, I am using my personal server and have put a new downloads page online. It is available at http://eclipsefp.sourceforge.net/download/ The page has some missing images: I didn't have write access to the images directory and didn't want to start a mess by placing the images elsewhere. I am configuring my server to build a ZIP bundle with the plugin contents and send it to the SourceForge server automatically everytime a change arrives at the repo. This should only be a matter of configuring some SSH tools and hooking something to the darcs' post-push (or something like) trigger. The process is currently being triggered manually. This should be one of the last things remaining for real live downloads. You may also notice that the live builds are hosted on the website itself. I didn't think it was the case to clutter the project releases page with them, since they are by nature very unstable files and the releases page seems to hold the data for some very long time. Maybe we'll need to seek some better solution (or ask for more storage space), since our current quota for the website (and group account) is 100MB. Cheers, Thiago Arrais |
From: Leif F. <hi...@le...> - 2006-01-04 10:23:07
|
> For the time being, I am using my personal server and have put a new > downloads page online. It is available at >=20 > http://eclipsefp.sourceforge.net/download/ >=20 > The page has some missing images: I didn't have write access to the > images directory and didn't want to start a mess by placing the images > elsewhere. Great :-). Is there a problem with the access right? You should have the=20 full access to all dirs on the server. > I am configuring my server to build a ZIP bundle with the plugin > contents and send it to the SourceForge server automatically everytime > a change arrives at the repo. This should only be a matter of > configuring some SSH tools and hooking something to the darcs' > post-push (or something like) trigger. The process is currently being > triggered manually. This should be one of the last things remaining > for real live downloads. >=20 > You may also notice that the live builds are hosted on the website > itself. I didn't think it was the case to clutter the project releases > page with them, since they are by nature very unstable files and the > releases page seems to hold the data for some very long time. Yes, they are forever ;-) I think we should only keep a number of=20 intermediate releases, say from the last month. Maybe we should promote=20 intermediate builds to releases (they are still always 0.x, that means,=20 beta releases) more frequently. Btw: did I already mention that the plugin versioning scheme in Eclipse=20 is being modified? Details are here:=20 http://www.eclipse.org/equinox/documents/plugin-versioning.html Perhaps we can work the new numbering scheme in, that way everything=20 could be updated with the Update Manager, and we would only need an=20 update site, not the zip archives. Ciao, Leif > Maybe we'll need to seek some better solution (or ask for more storage > space), since our current quota for the website (and group account) is > 100MB. >=20 > Cheers, >=20 > Thiago Arrais >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop >=20 >=20 |
From: Thiago A. <thi...@gm...> - 2006-01-04 12:19:36
|
2006/1/4, Leif Frenzel <hi...@le...>: > Great :-). Is there a problem with the access right? You should have the > full access to all dirs on the server. These are the access rights for directory "images." [tbasouza@sc8-pr-shell1 eclipsefp]$ ls -lhd im* drwxr-sr-x 2 leiffrenzel eclipsefp 4.0K Nov 16 2004 images Seems like we need to enable write access to group members. Everything on the SF server is like this. > Yes, they are forever ;-) I think we should only keep a number of > intermediate releases, say from the last month. Maybe we should use the number of live builds as a limit, rather than a time period. If we really manage to have a "live" build for every modification pushed to the repo, our storage needs can get quite large on some periods. I would bet on a 10 build history buffer, what would demand (with out current code base) about 10MB on the server. > Maybe we should promote > intermediate builds to releases (they are still always 0.x, that means, > beta releases) more frequently. How often? I mostly agree. But, with our current resources, I don't know if we can really deliver much faster. I have been thinking of doing some promotion as soon as the 0.9.1 release is ready. We could use some more users (and developers)... > Perhaps we can work the new numbering scheme in, that way everything > could be updated with the Update Manager, and we would only need an > update site, not the zip archives. My first option for the live builds was publishing two update sites: one for the unstable (live) version and another one for the stable (releases). The archive version just seemed easier to do :-) We can always put that second update site in place if there is community de= mand. Regards, Thiago Arrais |
From: Leif F. <hi...@le...> - 2006-01-04 13:08:50
|
Thiago Arrais wrote: > 2006/1/4, Leif Frenzel <hi...@le...>: >> Great :-). Is there a problem with the access right? You should have t= he >> full access to all dirs on the server. >=20 > These are the access rights for directory "images." >=20 > [tbasouza@sc8-pr-shell1 eclipsefp]$ ls -lhd im* > drwxr-sr-x 2 leiffrenzel eclipsefp 4.0K Nov 16 2004 images >=20 > Seems like we need to enable write access to group members. Everything > on the SF server is like this. Jupp. You should be able to change the access rights, though. >=20 >> Yes, they are forever ;-) I think we should only keep a number of >> intermediate releases, say from the last month. >=20 > Maybe we should use the number of live builds as a limit, rather than > a time period. If we really manage to have a "live" build for every > modification pushed to the repo, our storage needs can get quite large > on some periods. I would bet on a 10 build history buffer, what would > demand (with out current code base) about 10MB on the server. I was more thinking of a nightly build, which would happen once a day.=20 In this case, the number of days and the number of builds would be=20 equal. We can of course fill in hand-triggered intermediate builds. >=20 >> Maybe we should promote >> intermediate builds to releases (they are still always 0.x, that means= , >> beta releases) more frequently. >=20 > How often? Whenever we think something is stable enough that the wider community is=20 not harmed. I think that could be several times a week, or in some=20 periods once in several weeks ;-) > My first option for the live builds was publishing two update sites: > one for the unstable (live) version and another one for the stable > (releases). The archive version just seemed easier to do :-) Yes, I think two update sites would be better than one giant one ;-). > We can always put that second update site in place if there is communit= y demand. The cool thing about update sites is that you can even let Eclipse=20 automatically, so that it checks regularly for updates and always=20 installs the latest thing. So, if I had to choose, I would rather have=20 an update site and no zip than the other way round. (If we have to=20 choose because of disk space limits, I mean.) Apart from that, if we=20 have both, all the better. And if we have only the zips, that's cool too=20 :-) Great work, anyway. I have just pulled the entire branch and I'll see if I can re-merge it=20 into the main branch. Very probably there will be no problem at all,=20 because the main branch can have only very, very few patches. Ciao, Leif >=20 > Regards, >=20 > Thiago Arrais >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log = files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=CCk > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop >=20 >=20 |
From: Thiago A. <thi...@gm...> - 2006-01-05 12:39:11
|
2006/1/4, Leif Frenzel <hi...@le...>: > Jupp. You should be able to change the access rights, though. Maybe I am trying the wrong way, but I can't. [tbasouza@sc8-pr-shell1 eclipsefp]$ chmod g+rwx images chmod: changing permissions of `images': Operation not permitted > > My first option for the live builds was publishing two update sites: > > one for the unstable (live) version and another one for the stable > > (releases). The archive version just seemed easier to do :-) > Yes, I think two update sites would be better than one giant one ;-). I hadn't considered that yet. Maybe we can provide an unique update site with the stable and unstable releases. It would look something like this EclipseFP update site EclipseFP Development live (Unstable) Build I20060104-1714 EclipseFP Release Release 0.9.1 Why do you think two separate sites would be better? Are there any performance issues? What can we do to avoid conflicts between plugin versions on the same installation? I mean, will users experience problems when upgrading from stable to unstable (or vice-versa) versions? I am sure I wouldn't like that on _my_ installation. > I have just pulled the entire branch and I'll see if I can re-merge it > into the main branch. Very probably there will be no problem at all, > because the main branch can have only very, very few patches. I would wait a little. There is a problem that I am still working on. It is a buffer that gets filled and causes the Workbench to lock when parsing large literate programs. Cheers, Thiago Arrais |
From: Leif F. <lfr...@in...> - 2006-01-05 18:21:01
|
Thiago Arrais wrote: > 2006/1/4, Leif Frenzel <hi...@le...>: > >> Jupp. You should be able to change the access rights, though. >> > > Maybe I am trying the wrong way, but I can't. > > [tbasouza@sc8-pr-shell1 eclipsefp]$ chmod g+rwx images > chmod: changing permissions of `images': Operation not permitted > Oh, it seems everybody can only change his own files. (I can't change all files either.) But I have made all my files made group-writeable now. >>> My first option for the live builds was publishing two update sites: >>> one for the unstable (live) version and another one for the stable >>> (releases). The archive version just seemed easier to do :-) >>> >> Yes, I think two update sites would be better than one giant one ;-). >> > > I hadn't considered that yet. Maybe we can provide an unique update > site with the stable and unstable releases. It would look something > like this > > EclipseFP update site > EclipseFP Development live (Unstable) > Build I20060104-1714 > EclipseFP Release > Release 0.9.1 > > Why do you think two separate sites would be better? Are there any > performance issues? > Yes, larger update sites are not handled very well by the Update Manager, and the redundant traffic that goes over the site is considerable. It starts to get better now in Eclipse 3.2, but there are still lots of Update Managers around that are pre-3.2 :-) Also, it is more tricky to selectively delete the older files (unless the build id is in each version of the jars). > What can we do to avoid conflicts between plugin versions on the same > installation? I mean, will users experience problems when upgrading > from stable to unstable (or vice-versa) versions? I am sure I wouldn't > like that on _my_ installation. > The versioning proposal from Eclipse helps there. Development versions have always higher version numbers than stable versions, so if there is a development version in the installation, that's the one that runs. Users can revert their installation, of course. > >> I have just pulled the entire branch and I'll see if I can re-merge it >> into the main branch. Very probably there will be no problem at all, >> because the main branch can have only very, very few patches. >> > > I would wait a little. There is a problem that I am still working on. > It is a buffer that gets filled and causes the Workbench to lock when > parsing large literate programs. > Sure, just give me a notice :-) I'll go through the code anyway starting from tomorrow. Ciao, Leif > Cheers, > > Thiago Arrais > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click > _______________________________________________ > eclipsefp-develop mailing list > ecl...@li... > https://lists.sourceforge.net/lists/listinfo/eclipsefp-develop > |
From: Thiago A. <thi...@gm...> - 2006-01-05 20:24:33
|
2006/1/5, Leif Frenzel <lfr...@in...>: > I'll go through the code anyway starting > from tomorrow. Awesome! :-) I will make the jparser branch group-writable to allow you to push any changes you'd like to. Cheers, Thiago Arrais -- Mergulhando no Caos - http://thiagoarrais.blogspot.com Pensamentos, id=E9ias e devaneios sobre desenvolvimento de software e tecnologia em geral |
From: Thiago A. <thi...@gm...> - 2006-01-06 03:06:24
|
2006/1/5, Leif Frenzel <lfr...@in...>: > Oh, it seems everybody can only change his own files. (I can't change > all files either.) But I have made all my files made group-writeable now. I am done with mine too. I have also uploaded the images to the site, try taking a look at the downloads page now http://eclipsefp.sourceforge.net/download/ Cheers, Thiago Arrais |