>From a look over that issue, it looks like the worst of waterfall methodology.
> Sorry to sound harsh, but it can be observed that the giant spec has NOT been
>implemented, and as seen in this thread it has actually scared off a potential
>implementer. That’s counter-productive.
I think what would make a lot more sense than implementing a giant spec, would
be implementing a MINIMAL spec, while allowing for eventual expansion with
backward compatibility.
For instance: for the first iteration, implement absolutely nothing but:
groups:
“somegroup”
policy => “present”;
Make the “policy” attribute required even though only the “present” value will
be allowed, just because that will allow the most flexibility for future
changes, while retaining backward compatibility. (E.g. maybe later that
attribute will become optional, but the behavior of having the attribute THERE
will not change.)
This should be really easy to code, then, and should be immune to bikeshedding.
It could go before or after users in normal ordering; I don’t think it really
matters. For the minimal implementation, “before users” makes more sense, but
later on “after” could be preferable; either way there are minor trade offs, so
flip a coin.
Best,
—Mike Weilgart
Vertical Sysadmin, Inc.
Sent from my iPod
> On May 13, 2019, at 12:26 PM, David Lee <[email protected]> wrote:
>
> Thanks, Nick. (I should have checked that issue tracker.)
>
> I see there are 50 comments on the ticket, with some interesting debate. It
> looks to be decidedly non-trivial, so I'll probably back away from my initial
> rush of enthusiasm.
>
> -- David
>
>
>> On Saturday, 11 May 2019 19:24:05 UTC+1, Nick Anderson wrote:
>> It is absent, unfortunately. There is a ticket here
>> https://tracker.mender.io/browse/CFE-2215
>>
>> I don't know of any surprises. And while it's quite annoying to be missing,
>> it just hasn't risen to a high enough priority for us to implement it
>> (though we would love to have it).
>>
>>
>>
>>> On Sat, May 11, 2019 at 7:37 AM David Lee <[email protected]> wrote:
>>> There is a 'users' promise-type:
>>>
>>> https://docs.cfengine.com/docs/3.12/reference-promise-types-users.html
>>>
>>> So it would seem natural for there to be an analogous 'groups'
>>> promise-type. Indeed, wouldn't a site wishing to use 'users' reasonably
>>> expect also to find 'groups'? But it seems to be absent. Is there any
>>> particular reason for this surprising absence?
>>>
>>> If I were to think about coding it, modelled after 'users', are there any
>>> "surprise points" that might have tripped up previous explorers of this
>>> terrain?
>>>
>>> -- David Lee
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "dev-cfengine" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to [email protected].
>>> To post to this group, send email to [email protected].
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/dev-cfengine/1803a04b-b38c-4c88-9c83-53c81a73ff93%40googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "dev-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dev-cfengine/352b6cbd-e847-41f9-a2ce-78743ae85118%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"dev-cfengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/dev-cfengine/49B30FA6-01E3-484E-B6EF-0575A060383A%40verticalsysadmin.com.
For more options, visit https://groups.google.com/d/optout.
