On Fri, 2014-05-23 at 14:31 +0530, Amita Sharma wrote: > On 05/23/2014 02:58 AM, Adam Williamson wrote: > > On Thu, 2014-05-22 at 20:22 +0530, Amita Sharma wrote: > > > >>> Thanks for working on this. I'm curious as to the context: is this > >>> really a Fedora-level effort, or is it more 389-ds upstream-level? What > >>> are the other test plans you are planning to work on? Thanks! > >> Hi Adam, > >> > >> I have updated http://fedoraproject.org/wiki/Category:Test_Cases with > >> 389 test cases section as you suggested. > > Thanks for that! But I think the category name might need to be changed. > > The name part has to match the name of the source package - that's how > > Bodhi knows which test cases to show for which updates, it looks in the > > wiki for a category called "Package_(source_package_name)_test_cases". > Thanks for the reply Adam > I accept your comment , it should be "Package_389-ds-base_test_cases" > > > > It looks like there is a '389-ds' package, but it only contains a couple > > of directories and some dependencies - that is, it's basically a > > metapackage. It very rarely gets updated, so we don't want the test > > cases associated with that package, because then people testing updated > > 389-ds bits won't see them. > > > > It looks like the 'real' 389 source packages are: > > > > 389-ds-base > > 389-ds-console > > 389-console > > 389-admin > > 389-admin-console > > 389-adminutil > > 389-dsgw > There are many :: > =============== > 389-ds-base-1.2.11.15-33.el6_5.x86_64.rpm > 389-ds-base-libs-1.2.11.15-32.el6_5.x86_64.rpm > -- These rpms are for the basic Directory Server Instance. > > 389-admin-1.1.34-1.el6.x86_64.rpm > 389-admin-console-1.1.8-1.el6.noarch.rpm > 389-admin-console-doc-1.1.8-1.el6.noarch.rpm > 389-admin-debuginfo-1.1.34-1.el6.x86_64.rpm > 389-adminutil-1.1.17-1.el6.x86_64.rpm > 389-adminutil-debuginfo-1.1.17-1.el6.x86_64.rpm > 389-adminutil-devel-1.1.17-1.el6.x86_64.rpm > --- These are for Admin Server. > > 389-console-1.1.7-1.el6.noarch.rpm > 389-ds-console-1.2.7-1.el6.noarch.rpm > 389-ds-console-doc-1.2.7-1.el6.noarch.rpm > --- These are for Directory Server Console > > 389-ds-base-debuginfo-1.2.11.15-32.el6_5.x86_64.rpm > 389-ds-base-devel-1.2.11.15-33.el6_5.x86_64.rpm > --- These are devel and debuginfo rpms I just looked at the *source* package names. That's the thing used for this 'package-related test case' mechanism - the source package, not binary packages. > > I don't know enough about 389 to know which test cases should be > > associated with which source package, but I guess you do. So create > > "Package_(source_package_name)_test_cases" categories for each source > > package for which you have relevant test cases, and put the right test > > cases in the right categories :) > So here again As you said "REAL RPMS" are only few and I don't think we > should categories the test cases on the basis of rpms because one or > more rpms are dependency rpms, serving single purpose. > Rather, we can have 2 major categories > 1. 389-ds-base (which will cover various features of DS like password > policy, SSL etc.) > 2. 389-console (which will cover admin and console functionality) I think the best way to think about it would be from the other end: the updates end. Basically, the question to ask is "when we ship an update for this package, what test cases do we think it would be useful for people to run?" Oh, and you don't need a clean "each test case is in exactly one category" mapping, sorry, I should've mentioned that earlier. You can certainly have test cases in multiple package categories. So if there's a test case that would make sense to run both when 389-ds-base is updated and when 389-admin is updated...put it in both categories. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
