On Sun, Jan 16, 2011 at 1:02 AM, Thomas Hallgren <[email protected]> wrote:
> Hi,
>
> One thing I've always found very useful when discussing proposals like this
> is to use the issue tracking system early on. It's easy to cross reference
> even individual comments and also to obtain links to them when referencing
> from email. Aside from the ability to comment anonymously, it fits Nigel's
> bullets very well.

I think you're right, lets try using the ticket tracker. We can get
almost everything we need from it.

>
> I've been working a lot with the Eclipse community for some time. They make
> heavy use of their bugzilla. As soon as a discussion commences on a list
> that is likely to lead to something to be implemented, an issue (sometimes
> several) is started and the discussion moves.
>
> Personally, I don't care much about being able to comment anonymously and I
> don't think people in general feel that they are blocked out if they need to
> register in order to participate in the discussion.

We've had a bit of grief over this in the past with the ticketing
system, but I also think it's reasonable to require registration to be
involved.

>
> Regarding the proposal. One thing that I'm not able to extract is how to
> derive what a module will need in terms of data. If this is about separating
> the data from the actual use of the data, then there should be some
> meta-data describing it. Let's assume I want to create an IDE extension for
> editing the data for a specific module. How can I assist the user in
> entering this data and then validate that it is correct?

That's absolutely in the next stage, to either describe this data in
the metadata for the module, or to provide an API to interrogate the
module for parameters. We want IDE extensions, pre-commit hooks,
Dashboard, Foreman and other ENCs to be able to work out what
parameters are required remotely.

Validation is also going to be required. We could do something like a
::validate subclass where the author tests the parameters and invokes
a fail()-like function, but perhaps there's a better way we could
achieve this.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en.

Reply via email to