Release Script

Sat Jul 7 18:27:42 UTC 2012

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04-07-2012 17:44, Michael Jansen wrote:
> 
>>> 
>>> If you have a problem with us setting up weekly snapshots in
>>> that format, then you may have a point because i am thinking
>>> about that use case. Afaik some distros provide weekly
>>> snapshots straight from our branches. If our release system is
>>> fully scripted we could make weekly snapshot releases and ask
>>> them to use those. They might look like that. Or perhaps have
>>> the git or subversion number somewhere in the name.
>> 
>> Then please *really* forget it.
> 
> I have no idea why to tell me something like that: "Stop doing
> thinking about stuff, stop trying to improve stuff, just go away.
> That is what comes around here", instead of telling me just how you
> guys work currently and together we figure out how everyone can be
> happy?

I'm not telling you to stop improving stuff, I'm asking you to forget
a naming scheme that as I tried to show you will cause a lot of work
for us (Gentoo and I assume other source distributions) with IMHO
little gain. I even presented alternatives to make sure the tarballs
convey a precise release without adding "unpredictable" strings to
their version.

> Glass half full please.
> 
> If i would answer you in the same way i would just say:
> 
> You guys currently get no snapshot releases from us so please
> explain to me why us releasing some you can't use makes things
> worse for you? Just ignore those snapshot releases, those that can
> use them will be happy. But thats not my intention.
> 
> I want to make clean i really appreciate that you are taking part
> in the discussion here. So don't take offense. I just wanted to
> point out that your emails look MUCH better without your first
> sentence. And much more constructive.

My first sentence was meant to convey how much your proposal (naming
scheme) affects us and worries me. The reminder of the email was meant
to show that I'm not just "flipping out" or making noise just for
making noise.

>> In the case of Gentoo, we start our work of doing a new KDE
>> release by bumping the ebuild (Gentoo package format) version -
>> for example we bump kdelibs-4.8.3 to kdelibs-4.8.4 or kate-9999
>> to kate-4.8.95. As the name of the tarball that we try to
>> download is based on the package version, if you have a
> 
> So you guys have some artificial version 4.x.49.9999 which
> downloads sources from a branch and builds them? Artificial in not
> released by kde?

What you call an "artificial version" is a mean for us to provide the
users who want to do it a package they can install and update whenever
they want to track a specific branch or the head of your git
repositories. But you're right, users will be using something that
wasn't released by KDE. As Andreas already mentioned, these packages
are only available on our KDE overlay and require extra work from
users before they can use them.

> So everyone out there having this version does not really know
> which version he has? Because it depends on when he built?

The same way as any KDE developer that uses packages from the git
repositories.

> You guys currently have no support to build snapshot versions (and
> i realize we currently don't bprovide any). And it would be hard to
> do unless we release all snapshot versions under the same PACKAGE
> NAME EVERY TIME. What version is in the package is irrelevant.
> Right?

As you mention, we can't provide support for something you don't
provide. We did provide for a while support for snapshots when you
briefly released them sometime ago.
We can do almost anything that can be done with bash to track your
packages, but it will be much simpler and quicker to add support for
packages that have reasonable and *predictable* names / versions.
I expect that you release kate snapshot tarballs with the same name
than the releases / pre-releases (kate). I haven't seen any suggestion
to do otherwise. In the past there were some changes of package  /
tarball names or moves of a package from a tarball to another. That
creates extra work for us, but as long as it isn't done without
thinking or worse you do it a few times in a row, we can live with it.
The package / tarball version is the crux of this discussion. We can
support several naming schemes, so we're open to talk about that. What
we really need is *consistency* and *predictability*. Whenever you
name a package / tarball with an unpredictable name, you force us to
have to check each package and to manually update our naming scheme.
If you use a consistent and predictable naming scheme, all we need to
do is copy a file and use the new package name (without having to go
and check what tag was used for each of the packages that we're touching).

> So something like this (taking scotts email into account)
> 
> kdebase-4.8.5-20120624-<GIT ID or SVN VERSION> 
> kdebase-4.8.5-20120701-<GIT ID or SVN VERSION> 
> kdebase-4.8.5-SNAPSHOT -> kdebase-4.8.5-20120701-<GIT ID or SVN
> VERSION>
> 
> would solve your problem?

No. As I've explained in the previous email and above, using git or
version tags force us to manually update packages and to go check each
and every package to determine what commit id was used on the package
name. As I've argued on the previous email, add that to a file inside
the tarball or make that available through the package UI, but don't
add that to the tarball name.

> Can i interpret that that you guys would get problems too if we
> would not release all our packages with 4.9.2 . Remember we are
> talking about leaving unchanged packages out of the release on
> minor releases!

This will cause issues for us now. But we're willing and ready to
update our tools if that's what will lay ahead. What we would like to
ask is that you please think it over so that we don't have the trouble
of updating our tools and in 1 month you rethink and reverse such a
change.
As Andreas already presented on his email, before you start doing
this, we really need you to document all your dependencies for each
package.
The best (easiest?) way to do that would be through the cmake files or
if you're willing to do that, to have a text file inside the tarballs
with that info.

>>> I think we did it for a time. At least i remember some " a new
>>> snow storm, a new snapshot" commits by dirk. But no idea how
>>> they got released/packaged.
>> 
>> Yes, you did that in the past and we really disliked it.
> 
> Could you find out how they were named back then for me? Just for
> information.
> 
> Mike

I can't recall the names used back then, but I'm pretty sure they
included the svn id in the names and dir inside the tarball.
I tried asking in #gentoo-kde but no one got back to me so I can't
help with that.

PS - I'm sorry for not replying sooner, but I got busy with other
stuff / real life.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP+H+eAAoJEC8ZTXQF1qEP8jwP/3s2DC9hsfsbeeToyX1sZ5l/
YFQNalFx7nF2AvblfsungBGpvl4MIU1QrK9VMtbA5bA5Lt+rko8qDLSQBabkqlFQ
DDUoZZikZSoJfDTZZzH60GQAhJ/3jAPI8HrJO+PwqsTI/2OknI8hdfoKk0MlsvOp
CtvSf1/NIiEXPVJltWqcthQgO6pQVJl3f+lR3HgMuNlWSYVvlEuoIJmcmiPD9VMk
DFhP4BeEIi7zIdHhDY2AbXUE1YuhBMS7aVt5z5Q1f1E++Z6IIQ6Li11+lOItXV+q
ug1k6j0fp9gYeXi6R9wHNCrVU3vROMabTB1adokYZDdnPze9K7bxZbROHAfauGKN
mOK8DuIJ55DiOdmE1U48A3IJGUu1snONMhq5/CYt5QPXod2MYbXf/0GtUq2a9DHp
ZokCtRb7kkiF6r/E5KemXEPFbkhuEdTqKkaK985gKAQKfR714UAqTt2KAJVU7OwE
u6GMOZjw+bFbmLzWFK7kVJWiEjDU9HfoHL5F0cwLs17TCcWrYEUqke4dElGlhly+
vCT2f96QfQppkuUfzVcky0M+iPMpGMN8o5zGFHaWqjCDC/74ExN1MzLSqT4m1QoV
6xY+I/hvvW7K9uyOnDL4F8V+QYOkPyKFpI8nKQgImCXAHhFv0cfF2SSA2S/E9KAb
4CjIgdGZbUYDzcx1YmzF
=1IuM
-----END PGP SIGNATURE-----