Add command line options --bugzilla-project and --release-path
Needs ReviewPublic

Authored by habacker on Sat, Jan 11, 1:08 AM.

Details

Reviewers
jriddell
Group Reviewers
Restricted Owners Package(Owns No Changed Paths)
Summary

These values are used in the ticket template link to reduce
possible errors when manually editing the ticket template link.

Test Plan

used to release alkimia 8.0.3

Diff Detail

Repository
R572 releaseme
Branch
master
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 20934
Build 20952: arc lint + arc unit
habacker created this revision.Sat, Jan 11, 1:08 AM
Owners added a reviewer: Restricted Owners Package.Sat, Jan 11, 1:08 AM
habacker requested review of this revision.Sat, Jan 11, 1:08 AM
habacker updated this revision to Diff 73245.Sat, Jan 11, 1:11 AM
  • removed debug info
sitter added a subscriber: sitter.Sat, Jan 11, 1:13 AM

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.

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.

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.