On Wednesday 04 June 2008 18:35:01 you wrote: > Actually you do, but never mind. Maybe it's boring for you because you > didn't understand my point.
hehe, I highly appreciate your kernel, hardware work but this is really boring. If you think you can create a distribution that needs less amount of time in creating and maintaining and is pleasing the people that want to use the latest versions and the ones creating a stable locked down version then by all means scratch your itch and do something about it. But stating false facts is not the way I appreciate scratching an itch. <war story> At ROAD we only wanted to build from source that is available on our server with backup and archiving in place. So what we did was to change the various FETCHCOMMAND lines in bitbake.conf to /bin/false. So your build failed when you actually wanted to fetch from git, svn.... This forced us to make sure we put the sources somewhere before we could use it. </war story> > Doesn't this have ramifications for source capture, or is it about > something else: ''If we *build* a specific revision which gets > "orphaned" (no one is referencing is) and people do a fresh > checkout/clone they will not get this revision''? If so, a source > package a build time would indeed resolve it. Right? Well, like with everything this is not black and white. Sure we can stop building from any repository and only use tarballs. Then you can change the history in the repository the way you want. But you didn't progress at all. One will write scripts that will create more recent tarballs for you, people wanting to always build the latest will love you too for manually creating source packages first. The admins will love you too because they want to use their storage for archiving all the tarballs ever created, for every single revision (webkit is hundreds of mb...). Regarding rebasing. The next time you invoke git-gc the version will be gone. Now you have a tarball and the license is obeyed but you lost all the benefits of a SCM, you can not use git-log to actually see which patches your tarball contained. By means of thinking in black and white you are certainly right that putting tarballs on the infite turing tape is going to solve the issue. In the world of compromises and people wanting to always build the latest and people wanting to create a stable product such black and white thinking is not helpful. And a linear history is something you have by default with cvs,svn,hg,mtn and even for git you need a --force to create a non-linear history and is disabled by default in the repository. So not using rebase on a public branch is common sense. If you think this is not possible for "stable" please respond to that mail and we can discuss this there. z.
