-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
|> 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. Actually I have made my own distro based on cross RPM singlehanded in the past for my projects, with some quite complex stuff in it like postfix, dovecot, openssl and so on. It didn't "please" anybody but me, but I did do it. So unfortunately this gives me an RPM-centric baseline that I know very well to compare the OM / OE dev offering to. |> 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 Not flat tarballs, source packages. If you look inside a source RPM you find an upstream dist-tarball and any number of discrete patches which are applied by the spec file at build time. (hundreds in the past on Fedora kernels for example). If you look at our kernel tree we could certainly handle our git patchset in a source package as a patchset, more sustainable would be making a tarball from the last release tag and then the rest as a patchset. | 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...). All I can say is, tell it to Redhat. RHEL and Fedora are obviously much older and larger than OE / OM in every metric, but their distros ARE far more widely loved and used. They use the methodology I describe and if a newbie dev needs to build against their packages, he googles a bit and then is compiling in ten minutes, even if it links to other libs. If he googles some more and meddles for an hour or two his first app is packaged. That is not what we got here. | 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. Source packages do not have this problem since they are not flat tarballs. In fact, nothing stops you choosing to manage the patchset inside the source package by putting an attenuated ./.git into the source package. | 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. I never understood why you have a centralized build host, pretty good example of monolithic black and white thinking if you ask me. If people want the latest Qtopia that's changing five times a day, shouldn't it be that the folks working on Qtopia - and building it locally already - build it and put binary packages up somewhere, while the official repo has a slower, more stable approach and is not involved in the white-hot development madness? What is wrong with decentralized and distributed build that package signing doesn't resolve? It'd certainly simplify your mission. | 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. No, I agree that is a normal and good way, and by keeping stuff in "andy" branch for a while it should be OK the bulk of the time without reverts. It was just curious to hear the reason and that the build system takes such close note of the patchset. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhG8lMACgkQOjLpvpq7dMpaZQCfSOJZ0lfg6VeaOSqas3csnUAj aTUAn1NROSERCKOFe3UCdTKU7kws28wO =UT0f -----END PGP SIGNATURE-----
