Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check Request #25 - Detect Fix version change once Sprint is set up. #44

Closed
baranowb opened this issue Oct 12, 2016 · 10 comments
Closed

Comments

@baranowb
Copy link
Contributor

When sprint is up for CP, no version changes should be allowed, unless RC or GSS perform them.
ie. if Sprint 7.0.6 ( payload freeze) is up, any change of fix version in range [7.0.6 CR1,...) can't be performed by any other party than RC or GSS(?) ? If it happens, alarm should sound.

@rpelisse rpelisse changed the title Detect Fix version change once Sprint is set up. Check Request #25 - Detect Fix version change once Sprint is set up. Oct 19, 2016
@rpelisse
Copy link
Contributor

@baranowb this might be quite difficult to implement, first because Bugclerk has no knowledge of time, so it can't react on state changes, which means, it needs to parses history of the issues, which is not (unless I am wrong) propagated through Aphrodite.

We could definelty update Aphrodite to give access to the history of an issue, but I am afraid this would lead to loading a lot of data (and will require to implements some sort of lazy-loading). Also, writing the rule itself (search for changes in the version field in the history and then check if it happened after the Sprint date was set) is going to be very difficult with the MVEL syntax given by Drools.

On top of it, comes the issue of the Whitelist - where does it lives ? Who / how do we maintains it ?

I'm not saying I don't want to do it or that we should not, but just want to point out, it's not something for which Bugclerk is currently well designed for....

@rpelisse
Copy link
Contributor

@baranowb Sleeping over it, I kind of made my mind. I think we do need such feature but other check request (like #43) will need it. However this is going to be a bigger change to BugClerk/Aphrodite than what I had planned for this week.

Thus, I'll postpone this change (and the forementioned check request) to 1.0.0, which I hope to be working on next week.

@rpelisse rpelisse added this to the 1.0.0 milestone Oct 26, 2016
@rpelisse
Copy link
Contributor

rpelisse commented Dec 5, 2016

FYI, I'm still unsure where this "white list" lives (or should live) so I'm going to look at the past 6 month, see a bit who is changing those fix version generally...

@baranowb
Copy link
Contributor Author

Where/how it is just a secondary problem. Whit elist most likely should include RCs.

@rpelisse
Copy link
Contributor

Well, I do need to know where it is from a programming point of view :)

Like do I pass a file path to the program ? Do I look up data from an URL ? Or should this be somehow provided by Aphrodite ?

@baranowb
Copy link
Contributor Author

streams+aprhodite does not sound that bad.

@rpelisse
Copy link
Contributor

So the information could live in Streams then? But we have to add it right ? Right now I don't see anything related to RC ? (or maybe I missed something) ?

@baranowb
Copy link
Contributor Author

Most likely, but at the moment I would like things to settle to new streams.

@rpelisse
Copy link
Contributor

Ok, so this feature needs for the RC information to made it to Aphrodite, through the Streams. Should we open an issue on Streams about that, and link this one to it ?

@rpelisse
Copy link
Contributor

A check has been implemented to verify that state is no longer changed when issue is resolved. This will be released has part of the 1.0.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants