This should be added to the scm metadata and then picked up from there, not as an option on releaseme specifically as this isn't releaseme specific information.
That said I suppose it'd be best to actually extract this out of the source, but I am not sure there's an easy way to get that going without moving kaboutdata to cmake so metadata is likely the most reasonable thing to do :/

On a related note should bugzilla upstream ever address the feature request for adding versions to products via its API we'd need this information anyway.

In D26575#591732, @sitter wrote:

This should be added to the scm metadata and then picked up from there

Sure, will be a good addition, but will need some time for analysis, design and implementation and therefore cannot be a quick fix, which is covered by this request.

not as an option on releaseme specifically as this isn't releaseme specific information.

releaseme already requires information about the project in question, e.g. name, origin and version and provides support for specifying the release path and Bugzilla project in the ticket template link. The current way to edit the corresponding attributes in the link fails easily, as can be seen in https://phabricator.kde.org/T12521. This patch addresses this issue and will reduce the burden for sysadmins in case patching the link fails. Also it gives packagers a standard way for providing all required information for easier creating release request tickets.

That said I suppose it'd be best to actually extract this out of the source, but I am not sure there's an easy way to get that going without moving kaboutdata to cmake so metadata is likely the most reasonable thing to do :/

It needs an analysis of KaboutData usage in the git repos and related bugzilla relations. I just tried with onlinequoteseditor. In the bug report dialog I get a bunch of kde apps and an entry for onlinequoteseditor (https://bugs.kde.org/enter_bug.cgi?format=guided&product=onlinequoteseditor&version=1.0=) but the current used bugs.kde.org project is libalkimia :-(

On a related note should bugzilla upstream ever address the feature request for adding versions to products via its API we'd need this information anyway.

This would also reduce the effort for the system administrator, as they would no longer have to add project versions by hand. If there was a completion date, it would be a good time to have the bugzilla project names (and release pathes) in the metafiles.

Until that is done, this patch is well suited to reduce the maintenance effort for making releases.

In D26575#591908, @habacker wrote:

In D26575#591732, @sitter wrote:

This should be added to the scm metadata and then picked up from there

Sure, will be a good addition, but will need some time for analysis, design and implementation and therefore cannot be a quick fix, which is covered by this request.

I don't see how one is more work than the other. That's besides the point anyway though. Setting the bugzilla product via releaseme is simply a no-go. It goes against the design principles of releaseme, which is to say releaseme doesn't contain static data. We used to have static data in 4.x times, it was garbage and is the reason I am making a point not to slide down that particular slope again.

Everyone will agree that having a human change values manually sucks, but then your diff doesn't fix that. The mistake you made can still be made with the diff you propose. When the information is hardcoded in the metadata however it cannot be typo'd or forgotten or wrong and, as mentioned, it affords us greater flexibility in the future such as automatically creating versions in bugzilla.

not as an option on releaseme specifically as this isn't releaseme specific information.

releaseme already requires information about the project in question, e.g. name, origin and version and provides support for specifying the release path and Bugzilla project in the ticket template link.

Those are not the same thing, they are not information about the project. They are information about the release. Origin and version are in flux across releases, they are in fact what makes release 1 different from release 2, and name is your identifier to pick the right metadata and assign meaning to origin. By contrast the bugzilla product is not in flux and not required to assign meaning.

In D26575#592958, @sitter wrote:

We used to have static data in 4.x times, it was garbage and is the reason I am making a point not to slide down that particular slope again.

So the mistake was made in the past when it was allowed to add project-specific attributes (https://cgit.kde.org/releaseme.git/commit/?id=43b2b66f7008422ad1075b51cd2b2d23e43f95fc) and now leads to time being wasted assuming that project-specific attributes can be added :-I

Usually, after discovering a problem, I try to fix it for myself and submit it so that others can benefit. If this leads to a huge job and no intermediate steps are possible, I might have to reconsider my attitude.

You are right. The mistake is all mine.

Next time talk about things before you write the code instead of writing code and then pretend like others have to agree with it just because it is already written. You are basically guilt tripping me at this point.

One last question: You added this, in my opinion, very complicated way of having to change a text in a long and confusing url (you could have implemented it with a command line parameter) and accepted that mistakes happen with the expectation that if someone notices this and wants to solve the problem, he should rework the whole concept ?

It honestly hadn't occurred to me.
The problem at the time was that to actually get something released you needed to read a long wiki page to know where to upload things, and then come up with your own ticket text. Or, once you've released anything look up an old ticket, copy its text and update it for the new release. In either case you'd manually figure out checksums. That's annoying and also harder to get started with since you have to come up with the text yourself initially. Also more challenging to parse for sysadmins I suppose. So, the plan was to offer "quick help" text you can just copy-paste to upload the generated artifacts and then click a link to get to phabricator and have a ticket template pre-filled with checksums. Later that got extended with the bugzilla product line because people always forgot to file a separate ticket for that.

The way I imagined its use was: one runs tarme, copy-pastes the upload commands, clicks the url, reads the pre-filled text of the ticket and inserts the desired path for publishing (non-deterministic for some reason or other). And that is how I, for one, have been using it.