Story #1639
closed
As a developer, I can search Redmine for issues that need to be done for a given Pulp distribution
0%
Description
We need a way to do a single query in Redmine that can show us a prioritized list of issues that need to be done for a given Pulp distribution. It's important to note that Pulp is not just a platform, but it is also a distribution. We don't just distribute Pulp with a given version of Pulp, say 2.8, but we also distribute many other versions of packages that we write and packages that we do not write. Thus, when we talk about Pulp 2.8 we are sometime referring to Pulp the platform, but more often we are talking about Pulp the distribution. I.e., "we need to fix pulp-docker bug xyz for 2.8" really means that we need to fix pulp-docker bug xyz for pulp-docker 2.0.0, which will be distributed with the Pulp 2.8 distribution.
We can use the comments for specific implementation proposals, but the "done" criteria will be when developers can perform a single Redmine query to find out what needs to be done for a given Pulp release, such as "2.8".
Related issues
Updated by rbarlow about 8 years ago
I have a specific proposal for this: we could add a "Pulp distribution" attribute to all of our subprojects that has versions like "2.8.0" (basically, the platform versions). Then all tickets have both a Target release and a Pulp distribution target release (or similar name). Then, we can query this new field to find out what issues need to be fixed with 2.8.0, even for things that have their own version scheme (like Docker, Python, OSTree, Kombu, Celery, etc.).
These projects will also continue to use their own target release fields for convenience. We may even be able to automate the target release field so that it is automatically set correctly based on the distribution release. I.e., we know that the 2.8.0 will ship pulp-docker 2.0.0 - instead of relying on humans to do that, we could use some kind of cron script (perhaps the one we already use that maps bz to redmine?) to ensure that the target releases on the bugs are correct. This field would be used by users who want to know "which version of pulp-docker fixed bug xyz?"
Updated by semyers about 8 years ago
rbarlow wrote:
I have a specific proposal for this: we could add a "Pulp distribution" attribute to all of our subprojects that has versions like "2.8.0" (basically, the platform versions). Then all tickets have both a Target release and a Pulp distribution target release (or similar name). Then, we can query this new field to find out what issues need to be fixed with 2.8.0, even for things that have their own version scheme (like Docker, Python, OSTree, Kombu, Celery, etc.).
I believe that my proposed "Target Platform Release" meets this goal, but breaks current automation so for now we must suffer. This name would be a bit of a compromise with Redmine: Ideally, I think the field would be "Target Release" in platform, and "Pulp Distribution" in plugins, but Redmine doesn't let us to fun things like that. I think that going with "Target Platform Release" gives us a field name with clear meaning in both contexts. In the context of plugin trackers, the purpose of a "Target Distribution" or "Pulp Distribution" field becomes less obvious to me, compared to "Target Platform Release". Maybe "Target Pulp Release" is better still, since the platform could be interpreted to mean something like "Fedora 23", or "RHEL 7", for example. Thoughts?
As mentioned in a meeting earlier today, changing the name of this field will break automation. Brian should be commenting on that.
These projects will also continue to use their own target release fields for convenience. We may even be able to automate the target release field so that it is automatically set correctly based on the distribution release. I.e., we know that the 2.8.0 will ship pulp-docker 2.0.0 - instead of relying on humans to do that, we could use some kind of cron script (perhaps the one we already use that maps bz to redmine?) to ensure that the target releases on the bugs are correct. This field would be used by users who want to know "which version of pulp-docker fixed bug xyz?"
I love this idea, but think it's a separate story that depends on this story being completed.
Updated by semyers about 8 years ago
Oooh, custom fields can have descriptions. I added one to Target Release, which you can see if you bring up the edit issue UI. The field name gets a dotted underline hint and the description shows on mouseover.
Updated by rbarlow about 8 years ago
On Wed, Feb 10, 2016 at 05:22:14PM +0100, Pulp wrote:
I believe that my proposed "Target Platform Release" meets this goal, but breaks current automation so for now we must suffer. This name would be a bit of a compromise with Redmine: Ideally, I think the field would be "Target Release" in platform, and "Pulp Distribution" in plugins, but Redmine doesn't let us to fun things like that. I think that going with "Target Platform Release" gives us a field name with clear meaning in both contexts. In the context of plugin trackers, the purpose of a "Target Distribution" or "Pulp Distribution" field becomes less obvious to me, compared to "Target Platform Release". Maybe "Target Pulp Release" is better still, since the platform could be interpreted to mean something like "Fedora 23", or "RHEL 7", for example. Thoughts?
I like your proposed name "Target Platform Release". +1
I love this idea, but think it's a separate story that depends on this story being completed.
+1, I'll file it if this gets traction.
Updated by semyers about 8 years ago
- Is duplicate of Story #830: As a developer, I can view aggregated Redmine issues for plugins and platform by target release per plugin/platform added
Updated by semyers about 8 years ago
- Status changed from NEW to CLOSED - CURRENTRELEASE
We recently made a change to this effect, and it's working well. There is now a "Target Platform Release" field filled with pulp platform release numbers available on all projects and issues.
Edit: This post was redmine magic that happened after I marked this as a dupe of #830. Oops. :)
Updated by semyers about 8 years ago
- Status changed from CLOSED - CURRENTRELEASE to CLOSED - DUPLICATE
.