Open Stack

On Tue, 2020-05-19 at 09:49 +0200, Balázs Gibizer wrote:
> 
> On Mon, May 18, 2020 at 18:49, Sean Mooney <smooney at redhat.com> wrote:
> > On Mon, 2020-05-18 at 18:11 +0200, Balázs Gibizer wrote:
> > >  Hi,
> > > 
> > >  [This is a topic from the PTG etherpad [0]. As the PTG time is
> > >  intentionally kept short, let's try to discuss it or even conclude 
> > > it
> > >  before the PTG]
> > > 
> > >  We have more than 800 open bugs in nova [1] and the oldest is 8 
> > > years
> > >  old.
> > >  Can we close old bugs?
> > 
> > realitically i think yes but we might want to mark them in some way 
> > so we
> > know it may or may not have been fixed when we do.
> 
> How do we decide that a bug might have been fixed? If a human brain 
> needs to check the bugs one by one, then given the time such check 
> needs and the amount of bugs we have, I don't think this is feasible.
oh i was thinking that instead of checking if they are fixed we add a 
unknown-if-fixed tag or something to them an close them

so if we do a launchpad search for an issue we are seeingin the future
we will still find the closed bug and see the tag and know that it was not fixed
and can reopen it.

i agree we likely dont have the time to check them 1:1
> 
> > >  If yes, what would be the closing criteria? Age and status?
> > 
> > so downstream we debate this from time too time.
> > ultimately if a release in no longer supported and we dont have 
> > customer using it
> > then we can close "bugs" for those older release provided we dont 
> > think they affect current/supported
> > release too. we have a 30 rule for bugs that are in "need info" e.g. 
> > if  i asked the reporter to provide
> > more info such as logs and  they dont do so in 30 days we close it. 
> > they are free to reopen it if they
> > eventually provide the info requested. i think this would be 
> > equiveltnt to the incomplete state upstream
> > 
> > where the bug report is marked as incompelte because we are missing 
> > info we need.
> > upstream we might want to extend the time frame form 30 days to say 6 
> > months/one cycle but after a cycle if a bug
> > is still in incomplete its likely that any upstream momentum that may 
> > have existed to go fix it has long since
> > fizzeled out.
> 
> When I request additional logs / information in a bug I immediately 
> mark it Incomplete and ask the author to put it back to New when she 
> provides the requested information. Also the 800 bugs in [1] does not 
> contain the Incomplete bugs.

yes if i need more info i do the same and move it to incomplete.
i was just suggesting that one way of closing bug would be in addtion to the 2
years in new state we could also close incomplete bugs that are older the 6 months or 1 release
cycle which ever is longer.
> 
> > 
> > there might still genuinly be an issue that we shoudl fix which is 
> > why i think we should have some way to mark the bug
> > as closed without resolution due to age such as a tag but i dont 
> > think it makes sense to leave them open for ever.
> > > 
> > >  Personally I would close every bug that is not updated in the last 3
> > >  years and not in INPROGRESS state.
> > 
> > you are rather geourse in your tiem as i would close any bug in that 
> > state which si not on a maintianed
> > branch. which would be 18 months to 2 years ish but we could start 
> > with 3 years.
> 
> I'm fine to close more bugs so 2 years works for me.
> 
> Cheers,
> gibi
> 
> > > 
> > >  Cheers,
> > >  gibi
> > > 
> > >  [0] https://etherpad.opendev.org/p/nova-victoria-ptg
> > >  [1]
> > > 
> > 
> > 
https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE
> > > 
> > > 
> > > 
> 
>