> Yes things are mirrored.. > http://hg.osunix.org/osunix-gate/
thanks, that's awesome! > Also realize that there's more sources/patches and a > lot of other things which are mirrored as well since onnv-gate alone > won't build itself. You are saying that osunix-gate contains a lot more than onnv-gate? Or are you instead saying to build osunix-gate you must track down a lot of other source which is mirrored in various places? Also I don't understand hg as well as I wish. Does the clone include all the branches and tags and old revisions in the original, or is a clone include only what CVS would call the HEAD? For example if you wanted to mirror a BSD project it'd be very important to mirror the repository itself with rsync, not just check out HEAD with 'cvs update'. > If you want to help provide mirroring either for the > binaries I build or source please contact me off list. > contact me off list if you're a developer and can > help.. why off-list? After a few burns, I'm a huge fan of transparency now. :) It seems like you want to set up public mirrors, so you need not so much a developer as someone with lots of disk space and free transit, which I do not have, but some of my friends do if they were to become interested. I think it's a good idea, but since the Sun infrastructure is still available I'm not sure it's a desperate hurry. Rather it's good enough for a few people interested in openness to make private archives, but with the goal that they should be as complete as possible. Thus, what I'd be most interested in is a guide to what needs to be mirrored and where to get it, something similar to the existing guides for doing a nightly build, except refocused on building as much as possible from source, and pulling in as little as possible from binaries released through non-onnv ``gates'', as little as possible from the host system. And the guide should remind where to get the patched sfw source and how to build it, because this source can differ in hard-to-recreate ways from the upstream GPL source because of stuff with lots of local patches like Samba and just the fact that sfw works on SPARC while the mostly-GPL sfw stuff is mostly developed on little-endian 32-bit so there are no doubt lots of endyness bugs fixed in sfw as there are in netbsd pkgsrc and gentoo sparc and so on. Are you documenting what you do as you work on these mirrors? Maybe you already have such a guide. This would not only be useful for making the project forkable to evade relicensing. I think it'd be good for ordinary developers, too. There is not just ``source'' and ``binary'' with opensolaris, there is ``source'', ``hidden/scattered/`subproject' source'', ``redistributable binary'', and ``non-redistributable binary''. The hidden source does not need to be hidden, and apparently sometimes the same binary (Sun studio) is available as both ``redistributable'' and ``non-redistributable'' depending on which link you click. We are just a tiny bit of documentation away from a much less frustrating situation for license-pedants like me, but this isn't the first time I've found it's hard to ask for this documentation, or even ask questions that would help me write the documentation, because one gets called a troll, or called stupid because he hasn't already found what he's looking for (even though he doesn't know whether what he's looking for exists or not---god help whoever a sks THAT question and gets told ``how DARE you imply what happens to exist might not exist? kick him out of the project like Joerg!''). Twice I have bought hardware that a mailing list told me worked on SPARC based on incorrect examination of what looked like source but wasn't (I was called a troll for asking, ``don't disasterize. just upgrade.'' then the card did NOT work on sparc), and then another card that I thought came with CDDL drivers and didn't (determining what driver attaches to a pci id differs depending on whether the driver comes with source or not). so the questions are NOT dumb, but it turns into a touchy political issue to ask them. I think this recent (which will hopefully one day look baseless in retrospect) fearfest might be a great opportunity to round up all the source and build procedures, reduce the stfw-barrier for new developers, without riling anyone up or making people feel like we're being negative because ``why don't you just google for `opensolaris source' and spend half a day searching, it's there i found it on comstar-src4u.dyndns.org port 5000 what's ur prblem d00d.'' I am not interested at all in ``the binaries [you] build''---I'm sure they're helpful to someone, but for this issue I think they only make the problem worse by mixing up the ``source'' and ``redistributable binary'' categories which for me is where the slipped-through-the-cracks source problem starts. I *am* interested in mirrors of redistributable binaries, especially ones that are also released non-redistributable, because the redistributable link could easily be shut down later, screwing us if we don't have a mirror. > if people actually read the whole damn thread > instead of just picking the points to troll on. I do not follow the list but did read everything in the thread to which I posted that the forum software collected. And don't think what I wrote makes a very good troll since you seem to basically agree with me, far enough that you're already implementing things I suggested would be helpful before I even mentioned them. But for whatever it's worth, it was meant to be constructive, so I'm sorry/dismayed/frustrated if it wasn't. -- This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
