On Thu, 17 Aug 2006 16:45:19 -0400 Lyle Kempler <[EMAIL PROTECTED]> babbled:
> * Chady Kassouf ([EMAIL PROTECTED]) wrote: > > On 8/17/06, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> > > wrote: > > >personally i would have no problem in a server-side auto-build of > > >tarballs. what do people think? should we perhaps have the anoncvs > > >server do daily (or maybe several times per day) builds of packages? > > >not rpm or deb but "make dist"; ie something like the following run > > >maybe every 4 or 8 hours? once a day? > > I think that while this option might be useful for load, it takes a > > lot more bandwidth, and is bad for users, as they would have to > > download hundreds of megabytes each time a 1 Kb patch is in. > > > > I vote for the cvs mirrors as at least it's easier on the user's AND > > the server's bandwidth. > > Eventually I'll corner KainX and he'll tell me what setting I don't have > in mutt to read raster's emails other than through quotes.. anyway.. > > Were I suggesting merely a new tarball every day, then I'd agree. My > argument was for a weekly tarball and patches otherwise (and it doesn't > just have to be patches since the last weekly tarball). A lot of CPU > time and some bandwidth is consumed determining what changed since the > last time you sync'd up. If you _knew_ where that last sync point was > (e.g., yesterday's diff), then you'd be saving everyone a lot of > resources by just getting the pregenerated, precompressed version, > instead of making CVS do the diff, compressing on the fly (I'd like to > believe most people are using -z3 :)). As I read over and over that > people are using scripts to retrieve everything (be it ebuilds or > hand-rolled), this could easily be switched to. > > * Hisham Mardam Bey ([EMAIL PROTECTED]) wrote: > > On 8/17/06, Lyle Kempler <[EMAIL PROTECTED]> wrote: > > > Personally I don't get why we're not creating nightly diffs and a > > > tarball once a week and letting people use that (it's not exactly > > > difficult to script). I highly doubt most users care about checkins > > > in the last few hours, and I suggested doing so I think way back in > > > January on IRC.. > > Actually they are. You'd be surprised how many people build E (and > > related stuff) multiple times a day from anoncvs. Again, I agree with > > the majority that is suggesting the mirrors idea. CVS has its quirks > > here and there, but its been doing everything we wanted for a long > > time. I think that having a 2 or 3 anoncvs mirrors should solve our > > problems. > > I am actually surprised that so many people are "a CVS junkie" :) .. > that's good feedback to have. I never advocated dumping the anoncvs > servers. I was saying that we could reduce demand (and therefore improve > performance for the remainder) by providing tarballs. And, as raster > said, there's nothing keeping us from producing patches every 4 hours, > etc.. agreed. i am not advocating REMOVING anoncvs as such - just removing it as a "first priority anonymous source access" mechanism. putting anoncvs access info into fineprint in some obscure page linked off a download page. moving the "primary" access to something more server-friendly that matches people's needs better. people dont NEED cvs. developers do. they simply need a way to "get the latest code". also for those speaking of the bandwidth issues - a LOT of people DONT keep their cvs trees after build they re-checkout a new tree. so what we need to do is try alleviate the need for anoncvs mirrors and if there are mirrors - make them "last longer" bye making an alternate way of accessing updates available that gives people what they really need in a way that is light on our resources, and thus can scale better. imho making dist tarballs is also a good testing mechanism. that is our "end product" anyway - a cvs tree where you ned to run autogen.sh (autofoo) is NOT our "target product". it is an intermediate state developers can easily work with. end users will work with the result of make dist and then do the usual tar -xf file.tar.gz; cd file; ./configure && make && make install if we move and encourage the primary mechanism to be this with regular enough updates that people aren't waiting impatiently for that update/fix - then we may solve a lot of our problems? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
