Pulp

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?"

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.

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.

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.