> -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt- > project.org] On Behalf Of Prav > Sent: Thursday, 21 July 2016 4:06 PM > To: development@qt-project.org > Subject: Re: [Development] [QtMultimedia] Still is supported, active? > > Hello, Everyone. > > >> If "Fix Version" is filled by Yoann Lopes 6 months ago then he will > >> get this estimation and can decide to hire Woboq or someone else to > >> fix or whatever. > > > This is an unreasonable expectation to place on developers. For > > blockers (which, as far as I understand, this was not), yes, the fix > > version is most likely going to be known, but for many bugs, it's > > extremely difficult to know when they will be fixed. Things happen, > > priorities change. Also, there are always lots of bugs waiting to be > fixed. It's a huge product. > > Agree with you if this field was unchangeable once it was set (nobody > knows the future exactly ... ). > But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is how > maintainer see planning of it currently.
It sure is changeable, and we do change it... when: 1) It's a blocker and it has to be fixed by a certain version. 2) The bug is fixed. Read this thread: http://lists.qt-project.org/pipermail/development/2015-November/023847.html The conclusion from the chief maintainer was: > I think this makes most sense. The old way where we had a Fix Version set for > open bugs is at the minimum confusing to users. Usually it's worse, because > it creates false expectations. Setting a Fix Version on an open bug is > somewhat of a commitment by us that we will do what we can to get that bug > fixed for this version. And that's more the exception than the rule, ie. It > makes the bug a showstopper for that release. Which implies that if anything, we'd create a separate field for estimated fix dates, if we ended up doing that at all. Being an estimated fix date, and given everything that has already been said so far, this field will never be close to accurate enough to be relied upon. This defeats the purpose of it for situations where someone actually wants to contribute a fix and is (for some reason) relying on it to know whether they can begin working on it, rather than just taking action and contacting the responsible developer. And if it's not useful in that scenario, when would it be useful? That is to say, P1s and P0s will (hopefully) always get fixed quickly, but anything beyond that depends on a huge factor of things. There's no useful estimate that can be given unless the set of bugs is tiny. Even if estimates could be given for some specific bugs, there's no guarantee it would be for the ones that Denis is interested in, and so you'd still end up with people being wished away to hell... and I think we can both agree that hell is not a productive working environment. > If you maintain something you know best about plans. So share your > estimation! (this field is here for a reason). Nope, that's not what it's for. > You know tasks, you visit meetings there plans are discussed, you > communicate with other who involved ... you know situation with module > better then others ... so why not share your vision in this simple field? See above. > Moreover this field can be used to better support prioritization for > maintainer plans. I don't see how this changes anything. The maintainer already has an overview over the priority of bugs. As always, people will disagree with that priority, and, as always, they'll get told the same things they're being told by others in this thread. > Bugs with same priority but lower Fix Version have higher priority. So > actually beneficial for maintainers too. > > > Moreover there are other 2 fields which also need to be set. And not > filling them give instability for the bug too. > Do not want instability in feedback ... make bug's state stable. Easy! > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
