On Tuesday 13 of November 2012 21:36:55 Darrell Anderson wrote:

...

One of the points for discussion in R14 Road Map is the question about naming packages. I suppose it is beyond dispute that in the name of packages should be 'trinity' (or perhaps 'tde'?). Other issues for decision I would see the following:

1. 'trinity' before name or after? Or leave it distribution specific?

2. How to mark development version of packages? What about 14.0.0~preXXX?

For example: + amarok-trinity_14.0.0~pre148.orig.tar.xz

amarok-trinity_14.0.0~pre148-0debian11+pr16~squeeze...

• amarok-trinity-14.0.0~pre148-i486-13.1_1.txz

Note0: Because the Debian / Ubuntu version number must begin with a digit, it is impossible packages with the version number beginning with the letter 'R'. Therefore, such a question was unnecessary.

Note1: I am aware that it is not currently possible to change the version numbers of packages in nightly-builds. But I want to have arranged rules to marking package versions before beta / RC versions, and before moving nightly-builds to target version 14.1.0.

My thoughts:

1. Let's agree as a community to insert the "trinity" text string in the

package name. Whether as a prefix or suffix to the package base name probably is not important.

2. Whether the "R" prefix is used in the version number probably is not

important. Let distro packaging rules prevail.

3. I believe the GIT short version is the best way to identify the snapshot

version. Whether text strings such as "pre" are used probably is not important.

Recently I updated my package names to include the "trinity" string to avoid potential package name conflicts with KDE4. Currently I have the "trinity" string at the beginning of all package names. I could modify that to insert the "trinity" string after the base package name.

Because of the different rules for distro package naming, I suspect that where the "trinity" string is included in the package name is not as important as much that we all include the string.

I prefer the string "trinity" rather than "tde" because for many users who use package managers to search for packages, "trinity" is more descriptive than "tde."

Regarding development packages I have been pulling the GIT short version and using that number as part of the package names:

GIT_VERSION="`git shortlog . | grep -E '^[ ]+\w+' | wc -l`"

I build package sets for different Slackware releases. I use the Slackware release number and either "32" or "64" to note CPU architecture. I haven't been using other strings such as "pre," but I see no reason why others can't do that if they want. I include R14.0.0 in the package name although some people might argue I should be using "3.5.13." But the next release is forking version numbers and we have no easy way to show that the development packages are 3.5.13.90 or something similar as with other projects. Thus I stick with R14.0.0 for now.

Whether all of us agree to use "R" in the version number probably is not important. If distro packaging rules require not using then do that and if there are no such rules with other distros then let the packager decide. I prefer using the "R" prefix because the current Slackware release is 14.0 and the "R" prefix helps distinguish the two numbers. :)

Just my initial thoughts on the topic. :)

This topic is important. If we agree now on a very basic naming scheme then we all have plenty of time to adjust our build scripts before we begin to approach any soft freeze. Better now to do that work than scramble like Keystone Kops when we approach the release date. :)

Darrell

I also prefer the 'trinity' prior to 'tde'. Although it is longer, it is better distinguishable from 'kde'. Since it is used for 'deb' packages as well as the 'rpm' packages, for 'trinity' are apparently consensus. The question remains whether we want to seek consensus also for the location? Before × after × it does not matter?

Using git hash in version numbers has one major drawback - git hash is not growing number == without additional informations cannot be used to distinguish the "earlier × newer" version => for ensuring updates to a newer version. Use git hash is certainly a good idea, but there remains a need for an growing pre-releases number. Here we can see a similar way used in the linux kernel - version number for new relase are combined with 'rc' number. What then combine both - pre-release (growing) version number and also git hash? The problem is that it will be long :)

For example: + amarok-trinity_14.0.0~pre148+d2812a09.orig.tar.xz amarok-trinity_14.0.0~pre148+d2812a09-0debian11+pr16~squeeze

Slavek --

For git names just do the date it was built. Not as precise but easier to understand

A challenge with using the date is GIT is a moving target. Any version method used represents a snapshot moment of the repository. The GIT shortlog version better represents that snapshot moment than a date. A person could update a local repository but build a package set a week later. In that case the date would be incorrect.

If there was a way to pull a date from within the sources then a date could provide a better snapshot representation of the sources. But all Trinity packagers would need to use the same mechanism to pull the date to be consistent with one another.

Darrell

Dne st 14. listopadu 2012 Calvin Morrison napsal(a):

Let me further explain.

example: krita-trinity-2012-06-12-a2c24b62-i686.rpm.xz

has: name of package, trinity, date and git hash

On 14 November 2012 14:00, Darrell Anderson humanreadable@yahoo.com

wrote:

...

...

For git names just do the date it was built. Not as precise but easier

to understand

A challenge with using the date is GIT is a moving target. Any version method used represents a snapshot moment of the repository. The GIT shortlog version better represents that snapshot moment than a date. A person could update a local repository but build a package set a week later. In that case the date would be incorrect.

If there was a way to pull a date from within the sources then a date could provide a better snapshot representation of the sources. But all Trinity packagers would need to use the same mechanism to pull the date to be consistent with one another.

Darrell

This is an unnecessarily long. Date information can be misleading - not related to the date of GIT version. Not solve the correct sequence of multiple versions in one day. In this case, the "meaningless number" is more neutral. Simply only going to increase with each pre-release.

Slavek --

...

This is an unnecessarily long. Date information can be misleading - not related to the date of GIT version. Not solve the correct sequence of multiple versions in one day. In this case, the "meaningless number" is more neutral. Simply only going to increase with each pre-release.

It occurred to me - the number would not be "meaningless" - for example, it could be the number of commits since the last release. For example:

cd tde/main/tdelibs && git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l

This would automatically resets this number after each official release.

What do you think?

For the development branch, part of the package name should convey information that we all are packaging in a similar manner.

Thus, whether we name a package krita-trinity or trinity-krita is not as important as we all consistently use the text string "trinity."

Likewise for conveying GIT snapshot information about the package.

I ran the command above:

git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l 384

The result "384" conveys little information to end-users. That is, end-users would not be able to know from that number the snapshot moment of the package.

Our goal should be to adopt a package naming scheme that ensures a reasonable degree of consistency among all packagers. There is no way for all of us to have the exact same text strings in the packages because each distro is different. None of us create packages at the exact same moment. We are only seeking a reasonable degree of consistency.

Using dates or hashes is sensible but only when we use them consistently.

My concern with hashes is they are gibberish when used by themselves. They convey no useful information by themselves.

Dates make sense to me when related to the snapshot moment of the repository. Dates do not make sense to me when representing when the package was created. Nothing stops a person from updating a local repository and then building packages from that snapshot a week later. In such an example the date provides no meaningful information. When a person builds a package a week later but the date represents the snapshot moment of the repository then the date retains meaning.

Because of the recent server updates, I have not updated my local repository for several days. At this moment in my local repository, the date/time stamp of tdelibs/.git/ORIG_HEAD is Nov 10 11:46. I could convert that to 201211101146 or some other combination such as 2012_11_10_11_46. With that method I don't need to extract a hash from anywhere.

I could use both date and a hash: 20121110-03733ab1 or 201211101146-03733ab1. The hash and time stamp will change with each patch pushed, even when there are multiple pushes during a day. Thus, both date-hash and date-time convey useful information about the repository snapshot moment. Yet to end-users, I believe a date-time string conveys more useful information.

The following command extracts the date-time:

find tdelibs/.git/ORIG_HEAD -printf "%TY%Tm%Td%TH%TM\n" 201211101146

I could extract the module's most recent hash:

cat tdelibs/.git/ORIG_HEAD | cut -c 1-8 03733ab1

With all of that said, the git shortlog method I have been using runs into the same challenge. The number has meaning to me because the number is always increasing. A date is a much better informational guide. We only need agree on a consistent way to extract that date from the module. :)

Darrell

On Wednesday 14 of November 2012 21:49:40 Slávek Banko wrote:

I mean the combined number of commits and git hash. For example:

TARGET=14.0.0 cd tde/main/tdelibs echo $(basename $PWD)-trinity-$TARGET~pre$(git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l)+$(git rev-parse HEAD | colrm 9)

This will give for all the exact same results. This will contain important information == git hash. And also the growing number useful to simple compare "older < later".

For example, my results for the current tdelibs (in both branches):

+ tdelibs-trinity-14.0.0~pre385+189c12d0 + tdelibs-trinity-3.5.13.2~pre12+205b3397

Slavek :) --

On Wednesday 14 of November 2012 22:29:07 Darrell Anderson wrote:

...

For example, my results for the current tdelibs (in both branches):

• tdelibs-trinity-14.0.0~pre385+189c12d0
• tdelibs-trinity-3.5.13.2~pre12+205b3397

I'm not against the idea. :) More than likely the people using development branch versions will be above average computer literate users. People with whom hash numbers convey some information.

I'm concerned that to other end-users the string provides little meaning. Most end-users are not geeks. They don't want to deal with hashes. To them a hash is gibberish. A hash is familiar to developers. A date is familiar to all people. :)

tdelibs-trinity-14.0.0_201211101146 tdelibs-trinity-3.5.13.2_201211101146

Darrell

Yes, the date is known by everyone. But, on the other hand - users has only interested in "it's newer?" This will recognize easily using 'pre' numbers. And when user wants to us - developers - to tell which version have, we prefer for git hash. And user will be able to provide git hash.

Date is less useful for us. Find the appropriate git hash requires extra work. And 'pre' number i combination with git hash therefore provides information for both - for users and also for developers. Bear in mind that this designation applies only to development versions.

Slavek --

On Thursday 15 of November 2012 01:00:13 Darrell Anderson wrote:

...

Yes, the date is known by everyone. But, on the other hand - users has only interested in "it's newer?" This will recognize easily using 'pre' numbers. And when user wants to us - developers - to tell which version have, we prefer for git hash. And user will be able to provide git hash.

Date is less useful for us. Find the appropriate git hash requires extra work. And 'pre' number i combination with git hash therefore provides information for both - for users and also for developers. Bear in mind that this designation applies only to development versions.

Okay. I understand your point. As I mentioned, I'm not against the idea.

Unless there are objections, seems we could proceed with the following package name guideline:

• Use the text string "trinity" in the package name. Whether the string is

a prefix to the base name or a suffix is not important. This applies to both development branch packages and official release packages.

• Use a "pre" number and the module GIT hash in the package name. This

applies only to development branch packages. To generate this information, use the following commands in build scripts:

cd [module name] git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l cat .git/ORIG_HEAD | cut -c 1-8

The result will look something like this:

tdelibs-trinity-14.0.0~pre385+189c12d0 tdelibs-trinity-3.5.13.2~pre12+205b3397

Or

trinity-tdelibs-14.0.0~pre385+189c12d0 trinity-tdelibs-3.5.13.2~pre12+205b3397

• The remainder of the package name is distro-specific.

Does this sound agreeable to everybody?

Darrell

I tried to prepare a script that under the proposed rules create a tarball for module from the active folder. In the script is solved searching for last tag in current branch. Besides, are added checks if the current tree corresponds to the state on the server. And it is also added support for the creation of the final tarballs, when the number of commits since the last tag is zero.

Please, test it. If it proved to be useful, script could be added into the git scripts.

Slavek --

On Thursday 15 of November 2012 04:12:57 Darrell Anderson wrote:

...

Thanks, adjustments look good - just like I imagined it. If there are no other suggestions or objections, I will push it along with the update git scripts into 'tde/scripts'.

Looks like at least you and me agree about package naming guidelines. I wrote a note for myself to post a snippet somewhere in the wiki. Now I have to spend time updating my build scripts. Ugh. :)

...

Yes, the tilde is used deliberately because then for Debian is version 14.0.0~pre considered as older version than 14.0.0.

Okay. I likely will modify that for Slackware. I don't want to upset the natives. :)

Darrell

I added check if submodules were initialized. Second script can be useful for create tarballs for all modules. Please, look at this.

The question is whether adding label 'trinity' for packages that already contain 'tqt' in the name? For example: avahi-tqt, dbus-tqt,...

Slavek --

Let me further explain. example: krita-trinity-2012-06-12-a2c24b62-i686.rpm.xz has: name of package, trinity, date and git hash

Sure. I understand. All I'm saying is there should be a consistent method of using a date.

From where is the date and hash extracted?

A wiki mini how-to is needed. :) Then everybody could use the same method.

Darrell