Posted by dww on May 31, 2006 at 11:10am
Jump to:
| Project: | Project issue tracking |
| Version: | 6.x-1.x-dev |
| Component: | Issues |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
many issues apply to more than 1 version of the code. most bugs should be fixed in at least 2, if not 3 (or even 4) different branches. why don't we just let issues be assigned to multiple versions? i know it'll be a little harder to display changes as a followup alters the values in the multi-select, but i think we can solve that. seems like this would be useful for tracking issues that need to be back/forward ported, things that are more serious than they seem, since they apply to all version sof drupal, etc... (for example, http://drupal.org/node/66483 is a bug i just submitted for 4.6.7 core, but it's also relevent in 4.7.1 and HEAD).
Comments
#1
This would be handy, I agree. The display of the versions in the metadata fields won't be a problem now, since the tables can accept multiple values. Upping the version since this is still very relevant.
#2
Moving to the right queue...
#3
I agree. And this would be very useful for us. :)
Another reason for tracking multiple "affected versions" is that this can be a huge factor in rapid triage. When deciding where to spend precious development resources, one important consideration is "how many releases are affected?"
Admittedly, many projects seem to move in a more or less straight line.
But some projects have multiple versions, affecting different customers. It's important to be able to filter on that data -- and not just by searching the bodies of comments.
Carlos
#4
I too think that this would be useful, but I am reluctant due to possible implications when it comes to the UX.
I am also cross-linking/pointing out #1050616: Figure out backport workflow from Drupal 8 to Drupal 7, because I believe is relevant.
#5
Subscribing, we really need this instead of tags.
We could improve the UX here by only showing branches in the version drop-down - there is no reason to post issues against point releases - even if this had to be custom d.o code for core to remove the options.
#6
Some technical hurdles to solve:
A) Currently, version is just a single column in a DB table. I guess we'd have to split this out into a separate table of issue nid -> release nid mappings.
B) Due to A, the views queries to filter on version are going to become unindexable again, since the WHERE is going to span multiple tables. Ugh. nnewton and killes will hate me.
C) What exactly would the UI look like on the issue node and comment forms? Multi-select is error-prone and would take a lot of space (see http://drupal.org/project/issues/search/project_issue for an example). Magic "Add more" AJAX stuff like multi-valued CCK fields? Other? Mockups please. ;)
D) What do you display in the version column on issue queue views? Also, I guess this column would no longer be sortable (although I'm not sure anyone cares about that).
Also, I disagree with "there is no reason to post issues against point releases", even on d.o. If I find a bug in a specific version of a module, it's relevant and important to communicate exactly what version I'm using so that the maintainer (and others) can attempt to reproduce the bug. Although it might make sense to pull all the branches to the top of the list(s), I don't think it's a good idea to hide all the point releases entirely. Especially if this becomes multi-valued, I think it'd be great to flag bugs as being in 7.0 and 7.x-dev, then removing them from 7.x-dev once the fix has been committed (or something) so you can see which versions are affected, etc. If a bug still isn't fixed in 7.1, you'd mark it 7.0, 7.1. From my perspective, a lot of the value (although certainly not all) in making these multi-valued is to capture more precisely what versions a given bug impacts. It'd *also* be nice for tracking issues that span multiple branches, but that's not the only use-case.
Anyway, if this was trivial, I probably would have done it by now. ;) But, there are some thorny questions to resolve before we can plow ahead with this... Input and ideas most welcome!
Cheers,
-Derek
#7
Well, I am not a UX expert, but here's an idea of how the "Version" drop-down could be replaced by a "Branches" multi-select list:
- Project information --------------------------------------------------------| |
| Project: Branches: * Per-branch versions affected: |
| <project_name> [ ] 7.x __________________________________________ |
| [v] 6.x | 6.x | |
| Component: * [v] 5.x |_____ [v] 6.x-2.x-dev | |
| [ <none> |v] [ ] 4.x | 5.x | [v] 6.x-2.1 | |
| |_____| show more 6.x versions... | |
| |____________________________________| |
------------------------------------------------------------------------------
Selecting a branch from the list, enables a respective tab on the right...
- Project information --------------------------------------------------------| |
| Project: Branches: * Per-branch versions affected: |
| <project_name> [v] 7.x __________________________________________ |
| [v] 6.x | 7.x | |
| Component: * [v] 5.x |_____ [v] 7.x-1.x-dev | |
| [ <none> |v] [ ] 4.x | 6.x | [v] 7.x-1.0 | |
| |_____| show more 7.x versions... | |
| | 5.x | | |
| |_____|____________________________________| |
------------------------------------------------------------------------------
Each branch's tab could have the latest stable + its dev (if/where available) versions pre-selected for convenience.
The "show more versions" link is there to show other hidden versions of the same branch...
- Project information --------------------------------------------------------| |
| Project: Branches: * Per-branch versions affected: |
| <project_name> [v] 7.x __________________________________________ |
| [v] 6.x | 7.x | | |
| Component: * [v] 5.x |_____| [v] 6.x-2.x-dev | |
| [ <none> |v] [ ] 4.x | 6.x [v] 6.x-2.1 | |
| |_____ [ ] 6.x-2.0 | |
| | 5.x | [ ] 6.x-2.0beta | |
| |_____| [v] 6.x-1.x-dev | |
| | [ ] 6.x-1.7 | |
| | [ ] 6.x-1.6 | |
| |____________________________________| |
------------------------------------------------------------------------------
No more version switching! Instead of "But I am having this issue in version x.y.z" there'll be "I am seeing this in x.y.x too" ;)
#8
...or we can skip the "Branches" select list and have tabs for all available branches of each project.
Each tab could also hold links to any patches available (if any) for the respective branch, ...but that's another UI issue ;)
#9
A) yes.
B) There is mv, custom denormalization via hooks and solr. All of these are probably a huge job, but I expect the queries would be sufficiently bad they'd not be acceptable otherwise.
C) branches instead of tags would make it a smaller multi-select. Looks like klonos is suggesting hierarchical select for this.
D) probably all affected versions, and skip the sorting.
#10
...not exactly. Unless of course HS allows the selection of multiple parent items besides multiple children (don't actually know this, since I never had such a use case so far).
As for how the effected versions could be displayed in the issue summary, this could be either a simple 5.x, 6.x, 7.x list (where each branch could be link that would serve as a show more/details button for each specific branch), or if we wish to make things more complicated, the list could be in the form of ranges: 5.x-min to 5.x-max, 6.x-min to 6.x-max, 7.x-min to 7.x-max (where -of course- the min and max represent the actual minimum and maximum versions verified to be effected). I doubt that for example the 6.x-1.3 through 6.x-1.7 versions would be effected and 6.x-1.5 would not - even if not specifically confirmed.
In fact, here's an updated mockup with the "Branches" select list removed and ranges of effected versions displayed as tab summaries:
- Project information ----------------------------------------------------| |
| Project: Branches & versions affected: * |
| <project_name> ____________________________________________________ |
| | 7.x | | |
| | 7.x-1.3 to 7.x-2.1 | [v] 6.x-2.x-dev | |
| Component: * |________________________| [v] 6.x-2.3 | |
| [ <none> |v] | 6.x [v] 6.x-2.2 | |
| | 6.x-1.7 to 6.x-2.x-dev [v] 6.x-2.1 | |
| |________________________ [ ] 6.x-2.0 | |
| | 5.x | [ ] 6.x-2.0beta | |
| | (branch not effected) | [v] 6.x-1.x-dev | |
| |________________________| [v] 6.x-1.8 | |
| | [v] 6.x-1.7 | |
| | [ ] 6.x-1.6 | |
| |__________________________ | |
--------------------------------------------------------------------------
#11
...I think that "through" instead of "to" makes more sense in English when referring to ranges, but you get the point ;)
#12
...that + I'm mixing my "affected" and "effected".
#13
Subscribing...
#14
This is a good point, I can think of three use-cases the field supports then:
* Currently the version really means 'target version'. Sometimes maintainers want a decent patch for more than one branch, but often you can post against one branch, get that committed, then work on the backport (or forward port depending on the project) afterwards. It's also the version that tests run against etc.
* For tracking multiple releases it'd mean "affected versions", this is what the 'needs backport' tags abuse is for - although it's not possible to do lists like WHERE (version = '8.x' AND issue_tag = 'Needs backport to D7') OR 'version = 7.x', so it's a bit unwieldy.
* This is a bit different to "fixed in versions". For example there are a tonne of views patches that have been committed in the past year, that weren't in the security release, but they've been marked fixed/closed - and before that release came out. In an ideal world, we could base the automated change from fixed to closed based on whether the issue has been fixed in a stable release or not. That's a different feature request again but it's related.
If we left the current version as 'target version', it wouldn't be inconceivable to add nodereferences for affected and fixed - but that's going to make for an even more complicated form, and there is still listing and query performance (although if it's not the default listing it might be a tiny bit less critical if they're a bit slow).
#15
In #1050616-117: Figure out backport workflow from Drupal 8 to Drupal 7, @fietserwin suggested to simply have two fields: "version reported" and "version targeted". The latter being the current version field.
I like that proposal because of its simplicity. But of course, it presumes some built-in internal knowledge about release relationships and history. Reporting a bug against 6.x-1.1 and targeting 6.x-1.x would naturally imply that 6.x-1.1, 6.x-1.2, 6.x-1.3, ... and 6.x-1.x are affected. Switching the target to 7.x-1.x would additionally imply that possibly existing 7.x-1.0, 7.x-1.1, etc are affected, too.
Thinking further, it could also be three fields, "minimum version reported", "maximum version reported", and lastly "current issue/patch version", so actual work on the issue won't affect search queries.
A simple range would solve the database query/indexing issue, as it boils down to
version_min >= :version_min AND version_max <= :version_max. The technical challenge would be to separately prepare + store release versions in a way that "puts them in natural order"; i.e., something along the lines of:6.x-1.1 » 61016.x-1.1 » 6102
6.x-1.x-dev » 6199
7.x-2.3 » 7203
... and thus allows for chronological filtering of release versions.
People searching for issues would mainly use the min_version selector, in turn only leading to
rid >= :version_minin the query. Obviously, also making the UI less of a challenge.#16
6.x-1.1 » 6102?? I'm sure you meant: 6.x-1.2 » 6102
Using 99 in the last 2 digits to denote dev releases is pretty smart, but what about alphas, betas & RCs?
Projects use the w.x-y.z[-dev/alpha#/beta#/rc#] format. I take it that core would simply be 622 (6.22), 699 (6.x-dev), 722 (7.22), 799 (7.x-dev) and 899 (8.x-dev). Right?
#17
An extra column and min/max version sounds like a good compromise between UI and performance - would mean two select lists, but the extra one could default to the value of the first. It could get confusing for some, but no worse than people switching 8.x issues back to 6.x every few hours like they do now.
#18
Argh, I composed a reply here that I seem to have lost -- thought I submitted but perhaps I killed that browser tab accidentally or something. Ugh...
Anyway, to re-cap:
A) project_release already knows how to properly sort versions, even given unstable/alpha/beta/rc. However, the table sort on issue views doesn't use this (#177523: Sorting of versions in project_issues table not in correct order) nor does the version selector on the issue/comment forms (#767366: Sort version lists with version_compare()). I should have mentioned that when I was talking about the table sort, I really don't care *that* much if it's not there.
B) The real problem isn't getting ORDER BY right, it's that WHERE is going to be spanning different tables again, and that makes the queries un-indexable. Given the vast number of issues on d.o, un-indexable queries really, Really, REALLY hurt.
C) I *hate* to say this, since I fear it's going to slow down progress here and this would be cool and useful for all sorts of reasons, but I think the only way to make this performant is via #949372: Consider a Solr backend for issue views. Once we're talking range queries and sorting on a multi-valued field like this, on top of all the other crap we're doing with issue queue views for filters and sorts, it screams "Solr!" at me. To scale up to d.o-sized sites, I think we'll have to stuff everything imaginable into the solr doc for each issue, and use Solr to power the views, not SQL queries.
D) Even though the performance concerns are real, we still have UX/UI work to do here. I'd be open to splitting this issue into a performance task and a UX task, but for now, I'm okay keeping all the discussion in one place. We still need clear answers to a number of questions:
- What multi-valued field(s) do we really want to add?
- What exactly are they called?
- How do they appear and behave?
I very much appreciate klonos, catch and sun's contributions to these questions, although I don't think we've converged on a set of clear answers. I don't have the mental space right now to synthesize what's been proposed and try to help, but I just wanted to express where I think we're at.
Thanks everyone!
-Derek
#19
If you de-normalized the data, you could keep your indexed queries. In other words, the
project_issuestable should retain its currentridcolumn, to reflect the highest selected version of the most recentproject_issue_comment.Of course, that means that searches would only match the version stored in the
project_issuestable, but that's how it works now, isn't it?#20
@pillarsdotnet: If the project_issues table contains a single rid value, then queries for issues will only match that version. That's the whole point of this issue -- e.g. we want queries looking for D7 criticals to include all the issues that are currently languishing in the D8 queue but also affect D7. If the indexed query is only looking at a single value, we're basically gaining nothing by allowing people to specify multiple values here. Plus, what happens if the most recent project_issue_comment marked the issue that it affects 2 branches or even 10 point releases? What do you put in the column?
No, we need to keep the version information normalized and worry about optimizing the queries via other means, in particular, solr.
#21
#1171958: Allow patches to be assigned to a certain branch/version and thus tested against it.
#22
Sorry; I thought the fact that we can't test patches against multiple versions in the same issue was the big problem. I had no idea people were complaining about lack of search options.