[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Conformance Tests
> Well, yes, but tags and branches are really a kludge in svn. > Personally I have moved to version control software beyond svn. ;-) I have heard of such things but never seen one... there is usually just a crater and some smoke by the time I am able to observe the magic :D > And, I thought from the obligation/advice discussion that you felt > that semantics are important. ;-) They are important, I am just trying to find out what is driving your requirements. > I do think that v1 is a component. It's a component of the > conformance test package. It's not a version of the conformance test > package. Though it is a version of XACML, it's not XACML we are > versioning here. If I have a v1 compliant PDP I would want to test it against the v1 conformance tests. It doesn't seem logical that I would test it against a portion of the v3 conformance tests. I am all for breaking the test into core/profileA/profileB, but I disagree that we are not maintaining versions of the tests since it is highly likely that there may be revisions between XACML versions (making compliance test version a useful bit of meta data ;) b > > > But anyway, I could live with your suggested approach. > > Regards, > Erik > > Bill Parducci wrote: >> functionally tags and branches are the same thing in svn. if the >> semantics are an issue we can easily create/rename a directory >> structure called 'branches' rather than 'tags', but i am strongly >> opposed to creating static version names in the trunk. v1 is not a >> 'component' of v2 if for no other reason than we cannot ensure 100% >> backwards compatibility in the specification in definitely. >> >> further, this structure doesn't alleviate the "issue that spans >> version" user case. if there are multiple "live" instances of a >> test, the only solution is to replicate the changes (barring a >> merge). conversely, there are changes that may have unique results >> based upon version (e.g. deprecation of data type) >> >> b >> >> On Mar 9, 2009, at 7:00 AM, Erik Rissanen wrote: >> >>> Hi Bill, >>> >>> I propose that we keep it like this: >>> >>> current/tests/v1 >>> current/tests/v2/core >>> current/tests/v2/multiple >>> current/tests/v3/core >>> current/tests/v3/delegation >>> current/tests/v3/multiple >>> etc >>> >>> It is a convention in svn that you don't continue work on >>> something in the directory "tags". Tags are intended to be frozen >>> in time. We could make it a branch, but I think it is more >>> appropriate to see the whole thing as a set of "components", that >>> is, tests for v1, v2, v3, etc, which are all currently maintained >>> (for instance if someone reports a bug in the old tests), not >>> branches. >>> >>> In general, tags are used to store a snapshot of an old state for >>> future reference. Branches are used when development of a single >>> item goes in multiple directions at the same time. I don't see the >>> need of either tags or branches in this case. >>> >>> Regards, >>> Erik >>> >>> bill parducci wrote: >>>> I don't understand where the "mixing of versions" comes from. As >>>> you can see in the current layout the v1 tests--as they are >>>> labeled in the doc--have been tagged/branched (svn doesn't >>>> differentiate really) and are wholly independent from the trunk >>>> ("/current"). Work may continue on either independently (`svn >>>> switch` allows you to determine which branch/tag to work on). >>>> >>>> I understand the desire to break up the tests into functional >>>> groups but that it just that: a directory structure based upon >>>> categorization, not version. Since v1 has been in its current >>>> state for quite some time I suggest that this work be done on the >>>> current branch so as to only affect the work going formward. >>>> >>>> thanks >>>> >>>> b >>>> >>>> On Mar 9, 2009, at 1:19 AM, Erik Rissanen wrote: >>>> >>>>> Hi Bill, >>>>> >>>>> I was thinking that it's annoying to browse a flat structure >>>>> with hundreds of tests, mixed between different versions and >>>>> features. Note that I don't think we should ever throw away the >>>>> 2.0 tests, so it's not really a version control issue. It's >>>>> about multiple sets of files which will all be maintained. >>>>> Tagging is not a good solution for that. >>>>> >>>>> Regards, >>>>> ERik >>>>> >>>>> Bill Parducci wrote: >>>>>> I suggest we not attempt to circumvent the internal version >>>>>> control mechanism with static dirs :) How about we simply tag >>>>>> them? (We can branch the tests if we really think there will be >>>>>> a lot of work done on v2 tests after v3 tests are introduced). >>>>>> >>>>>> Sound workable? >>>>>> >>>>>> b >>>>>> >>>>>> On Mar 5, 2009, at 8:08 AM, Erik Rissanen wrote: >>>>>> >>>>>>> Thanks Bill, >>>>>>> >>>>>>> I will contribute more tests for 3.0 and the multiple resource >>>>>>> profiles. >>>>>>> >>>>>>> Could we perhaps make separate directories for v2.0 and v3.0? >>>>>>> And different profiles as well perhaps? It would make it >>>>>>> easier to find among them. >>>>>>> >>>>>>> Best regards, >>>>>>> Erik >>>>>>> >>>>>>> bill parducci wrote: >>>>>>>> I am checking in the conformance tests into subversion. I >>>>>>>> segmented the tests and schemas into separate directories for >>>>>>>> clarity. TC Members may check this out using Kavi auth using >>>>>>>> the following: >>>>>>>> >>>>>>>> svn co --username ##### --password ##### http://tools.oasis-open.org/version-control/svn/xacml/ >>>>>>>> >>>>>>>> You can simply point your browser here if you would like to >>>>>>>> browse: >>>>>>>> >>>>>>>> http://tools.oasis-open.org/version-control/browse/wsvn/xacml/?rev=0&sc=0 >>>>>>>> >>>>>>>> thanks >>>>>>>> >>>>>>>> b >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe from this mail list, you must leave the OASIS >>>>>>>> TC that >>>>>>>> generates this mail. Follow this link to all your TCs in >>>>>>>> OASIS at: >>>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe from this mail list, you must leave the OASIS >>>>>>> TC that >>>>>>> generates this mail. Follow this link to all your TCs in >>>>>>> OASIS at: >>>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe from this mail list, you must leave the OASIS TC >>>>>> that >>>>>> generates this mail. Follow this link to all your TCs in OASIS >>>>>> at: >>>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe from this mail list, you must leave the OASIS TC >>>>> that >>>>> generates this mail. Follow this link to all your TCs in OASIS >>>>> at: >>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC >>>> that >>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this mail list, you must leave the OASIS TC that >>> generates this mail. Follow this link to all your TCs in OASIS at: >>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/ >> my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]