-----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----- _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
