Simon, Any more reference for the update method?
Any updates on this? Any chance this will happen soon?
Can you please provide a update on this?
The attached bugs only ref milestone\versions, what about targets?
(In reply to Yaniv Dary from comment #17) > Can you please provide a update on this? Nothing has been done on this yet. (In reply to Yaniv Dary from comment #18) > The attached bugs only ref milestone\versions, what about targets? Targets is a red hat customization.
(In reply to Matt Tyson from comment #19) > (In reply to Yaniv Dary from comment #17) > > Can you please provide a update on this? > > Nothing has been done on this yet. > > (In reply to Yaniv Dary from comment #18) > > The attached bugs only ref milestone\versions, what about targets? > > Targets is a red hat customization. So we won't be able to set targets after this is in?
(In reply to Yaniv Dary from comment #20) > So we won't be able to set targets after this is in? There will be an RPC api for that too. Targets is not upstream code, so there won't be a related upstream bug for it.
What time line is 5.x?
(In reply to Yaniv Dary from comment #22) > What time line is 5.x? Our current estimate is FY17 Q1.
We wanted this to be able to make our build method automatic. Without this each of our releases will be much more manual labour. The time line you stated is more than a year from now, can you please consider this for a earlier time line?
(In reply to Yaniv Dary from comment #24) > We wanted this to be able to make our build method automatic. Without this > each of our releases will be much more manual labour. The time line you > stated is more than a year from now, can you please consider this for a > earlier time line? Current estimate is not more than a year away since Red Hat FY17 starts in March 2016. We are unable to do it before Bugzilla 5.0 due to our finite resources. I will keep this a priority and try our best to make it available after we have deployed BZ 5.0 Thanks.
(In reply to Muhammad Tahir from comment #25) > (In reply to Yaniv Dary from comment #24) > > We wanted this to be able to make our build method automatic. Without this > > each of our releases will be much more manual labour. The time line you > > stated is more than a year from now, can you please consider this for a > > earlier time line? > Current estimate is not more than a year away since Red Hat FY17 starts in > March 2016. We are unable to do it before Bugzilla 5.0 due to our finite > resources. I will keep this a priority and try our best to make it available > after we have deployed BZ 5.0 > Thanks. Any updates on this?
(In reply to Yaniv Dary from comment #26) > (In reply to Muhammad Tahir from comment #25) > > (In reply to Yaniv Dary from comment #24) > > > We wanted this to be able to make our build method automatic. Without this > > > each of our releases will be much more manual labour. The time line you > > > stated is more than a year from now, can you please consider this for a > > > earlier time line? > > Current estimate is not more than a year away since Red Hat FY17 starts in > > March 2016. We are unable to do it before Bugzilla 5.0 due to our finite > > resources. I will keep this a priority and try our best to make it available > > after we have deployed BZ 5.0 > > Thanks. > > Any updates on this? If there are any updates, you will see them on this bugs. Stay tuned.
FWIW I'd *really* discourage non-RHEL products from using the releases functionality. It is specifically for RHEL and if changes to its functionality breaks non-RHEL workflows it will not be a high priority to address. Use milestones, it's just another word for the same thing, but it's supported much better as it's upstream functionality.
Milestone API patch has been sent upstream for review. When it is approved I'll pull it back into our bugzilla.
(In reply to Jeff Fearn from comment #28) > FWIW I'd *really* discourage non-RHEL products from using the releases > functionality. It is specifically for RHEL and if changes to its > functionality breaks non-RHEL workflows it will not be a high priority to > address. > > Use milestones, it's just another word for the same thing, but it's > supported much better as it's upstream functionality. RHEL in not the only product in Bugzilla and RHEV have been using this for years and it is a major part of our process for years. If you plan to make any changes to this I see a lot of products that will be affected by this and you should mind them in making the decision. Advance notice and approval from all the product teams will be required. I suggest you place this in your process to make sure no disasters happen in the future.
The upstream API is now available, see https://bugzilla.redhat.com/docs/en/html/integrating/api/Bugzilla/WebService/Product.html Due to resource constraints we will not be modifying it to work with Red Hat's non-standard fields. Teams wishing to manipulate those fields will need to use the "temporary" API, which, due to the same resource constraints, we will not be removing. See https://bugzilla.redhat.com/docs/en/html/integrating/api/Bugzilla/Extension/RedHat/WebService/Bugzilla.html