SRCREV and git packages

[Andy Green]

-----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-----