Add filter by release to patch testing criteria.

In my code I used a fairly simple mechanism...a textbox that accepted valid release NIDs on seperate lines.

CommentFileSizeAuthor
#3 release_regex.patch4.27 KBhunmonk
testing_criteria.png28.37 KBboombatower

Comments

hunmonk’s picture

hunmonk commented
Title: Filter by release » Improve file filtering
Status: Active » Postponed (maintainer needs more info)

let's make this issue more generally about getting the file filtering right in PIFT. there are a number of decisions to be made here:

  1. do we want to filter by component at all? not sure this is really necessary given that people can control whether a patch gets tested by filename extension
  2. do we want the status filter to be per-project, or global? in both of our current modules, it's global, but i can see an argument for making it per-project
  3. do we want to filter by release nid, or by core compatibility? i'm not sure we gain anything by filtering by release nids in terms of usability. i would argue that if you want patches from your 5.x-1.x release tested, then you'd want a patch against 5.x-1.0 to be tested as well. what about just providing a setting for a regex against the release tag column in {project_release_nodes}? we also have the option of making that regex per-project or global.
  4. how pretty do we want the interface for this filtering system to be? looks like you and i both originally opted for the no-frills "look up the nid yourself" approach, basically. do we want it to be nicer than this or not? my initial instinct is that very few people will be using this software, and they'll be power admins, and hopefully the PIFT settings will be something they don't touch all that often -- so i vote to keep it simple.
boombatower’s picture

boombatower commented

component we can ignore if you like...I just added that after reading the requests...one advantage is if we choose to add support for testing certain patches later then we just remove the component...

the statuses I would vote for global for now...lets only add what we need and make it per project if we find we need that

regex against release tag is fine...I'm just about getting this functioning and wrote the code to deal with what we need now, not the unforeseeable future.

I would vote for no-frills since it is simpler....we can always make it nicer later.

hunmonk’s picture

hunmonk commented
Status: Postponed (maintainer needs more info) » Fixed
StatusFileSize
new release_regex.patch4.27 KB

committed attached to 5.x and HEAD, which adds a MySQL compatible REGEXP filter on the tag column of {project_release_nodes}

this makes this module incompatible with postgres for now, but it would be trivial to add support if we want it.

this fix now enables us to restrict patch testing based on CVS tags associated w/ release nodes, like only testing HEAD patches.

fully tested and deployed on drupal.org

Amazon’s picture

Amazon commented
Status: Fixed » Active

The calculated 4000 patches for HEAD have only sent 1000 patches.

1 of 897 patches being reviewed, plus 243 patches tested!

Did we miscalculate the 4K HEAD patches, or did PIFT fail to send all the patches for some reason?

Kieran

hunmonk’s picture

hunmonk commented

i believe that my initial estimate query filtered by HEAD CVS tag, and drupal project, but failed to filter by issue status. so i think there are 4000 patches there, but only about 1150 of them were attached to issues that were CNR/RTBC status -- which is all PIFT sent to PIFR.

looks like PIFT and PIFR are both working perfectly to me.

boombatower’s picture

boombatower commented
Status: Active » Fixed

Shall we?

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.