Another option, particularly where an idea is to be explored, is to
create a branch and do some initial work within that. It's easy for
other to see what's really required and is then easy to merge into the
trunk when ready.
In fact, any code that changes the API, particularly in Core should
consider this approach, so that others working from the trunk are not
continually disrupted while small changes trick through - this allows
for one update that requires changes.
Regards
Rob
On 17/10/10 19:30, Dan Haywood wrote:
On 16/10/2010 21:26, Kevin Meyer - KMZ wrote:
Going forward - where is the best forum to discuss, for example, that
is seems that "Optional" is only available as an annotation - but I'd
like
to discuss adding it as a runtime method (like disabledXXX) so that I
can set a parameter as optional at runtime?
As I indicated in my other reply on this thread, this mailing list is
the correct place for discussions and if necessary votes. But I can
imagine that there might be additional material you might want to
reference, eg to show how the idea would look in code.
I suggested on the other mail that a wiki page with that detail might
be best think to reference, but it occurs to me that you could also
create a new ticket in JIRA.
My view is that if no-one has any objections to the post (and give
people a day or two to notice it) then it's safe enough to go ahead
and implement. For more wide-ranging stuff that impacts the
programming model (as this one does), I'd suggest leaving more time
rather than less. We might also decide that anything that impacts the
programming model ought to be formally voted on. Again, interested in
mentors' thoughts?
Likewise, to resume the discussion about service contributed actions
and service disabledXXXX?
So, this is a different idea, so a different JIRA ticket and a
different thread on the mailing list. This one also impacts the
programming list, so maybe a vote is in order also.
Cheers
Dan
