|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/05/2010 11:41 PM, SharkD wrote:
> On 6/4/2010 4:47 PM, Jim Holsenback wrote:
>> concur ... moved it into User:SharkD ... besides some of what you
>> requested is already implemented
>
> Which ones were implemented?
>
>
>
Hmmmm ... I thought I was fairly clear with the posting I left in your
user space on the Wiki. You haven't been test driving the beta's have
you? Off the top of my head ... there is now a #for loop, and #break now
allows you to bail out of loops. The former was a new addition, and the
later was the result of a bug that I found by accident (a typo). As for
the various unary/binary operators, I noted that some not all that you
mentioned have been around for quite a while now. I'd be the first to
admit that some portions of the documentation can be rather dry reading,
but if you do some digging there is some useful information to be found ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/05/2010 11:43 PM, SharkD wrote:
> On 6/5/2010 3:00 PM, Jim Holsenback wrote:
>> ...If discussion and
>> list building is what your aim is, how about
>> povray.pov4.discussion.general ... are we getting any closer ;-)
>
> Where they will get buried once again... There needs to be a place where
> the /result/ of the discussion can be recorded. A log or some such. One
> where other information like bug reports aren't mixed in.
>
>
clipka pointed out the attributes of the bugtracker so I won't go over
that again. I really don't think that the KB namespace on the Wiki is a
sound choice, and the link to your post in the Questions and Tips table
of contents wasn't that prudent of a choice either. That leaves your
user space ... list away if you must, but I think the bugtracker is the
best choice :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.06.2010 04:43, schrieb SharkD:
> On 6/5/2010 3:00 PM, Jim Holsenback wrote:
>> ...If discussion and
>> list building is what your aim is, how about
>> povray.pov4.discussion.general ... are we getting any closer ;-)
>
> Where they will get buried once again... There needs to be a place where
> the /result/ of the discussion can be recorded. A log or some such. One
> where other information like bug reports aren't mixed in.
Any feature request that does not wind up in the bugtracker /will/ get
buried.
And the problem with /discussions/ about feature requests is that they
tend to have /no/ clear-cut result whatsoever, as they tend do be free
brainstorming sessions - unless there's someone with the necessary will
and authority (e.g. because he has started the discussion in the first
place) "driving" the discussion to a proper conclusion (ideally by
summarizing the discussion and result in a proper place... like, say,
the bugtracker ;-))
(Yes, the feature request description is a good place to summarize
earlier discussions.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Again, I think it would be good to have a formal means of discussing and
tracking feature requests for non-devs, since bugtracker seems to be
"for devs only."
My reasoning is that feature requests are hidden once they are closed on
bugtracker, so there's no obvious way to view them. There's also no way
to discuss them further since discussions are closed once the request is
locked.
This is definitely not a method that is amenable to users.
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.06.2010 10:10, schrieb SharkD:
> Again, I think it would be good to have a formal means of discussing and
> tracking feature requests for non-devs, since bugtracker seems to be
> "for devs only."
>
> My reasoning is that feature requests are hidden once they are closed on
> bugtracker, so there's no obvious way to view them. There's also no way
> to discuss them further since discussions are closed once the request is
> locked.
>
> This is definitely not a method that is amenable to users.
Yes, I do agree that this practical attempt at what sounded good in
theory did show some serious caveats of that process.
I don't think the way things were handled was the right way to handle
them, but extrapolating from this experience, my idea of the process may
be less universal than I had imagined; and similar outcomes may have to
be expected in future, too.
My apologies for the inconvenience.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/20/2010 9:51 AM, clipka wrote:
> Am 20.06.2010 10:10, schrieb SharkD:
>> Again, I think it would be good to have a formal means of discussing and
>> tracking feature requests for non-devs, since bugtracker seems to be
>> "for devs only."
>>
>> My reasoning is that feature requests are hidden once they are closed on
>> bugtracker, so there's no obvious way to view them. There's also no way
>> to discuss them further since discussions are closed once the request is
>> locked.
>>
>> This is definitely not a method that is amenable to users.
>
> Yes, I do agree that this practical attempt at what sounded good in
> theory did show some serious caveats of that process.
>
> I don't think the way things were handled was the right way to handle
> them, but extrapolating from this experience, my idea of the process may
> be less universal than I had imagined; and similar outcomes may have to
> be expected in future, too.
>
> My apologies for the inconvenience.
Just going to drop a comment here. For POVRay, a "democratic" vote on
feature thing may sort of work. Linden Labs uses the same system for
their bug/feature tracker, and its gotten to be so much of a horrible
swamp that even finding "if" something has been suggested, so you can
vote, or comment, never mind do so before something gets closed,or
relocated, or incorrectly marked as fixed (this happens a bit too often
in some cases, sometimes due to a "we think we had a fix pending, only
it didn't work, but no one bothered to reopen the issue, when it
failed", or just lost in the mire. My opinion of such systems is, as a
result... rather jaded. lol Not sure, reading the posts on the subject,
over the last 24 hours, is impressing me with it here either. Seems like
we are seeing the same sort of issues, "I think my suggestion still
needs time to be commented on, but someone closed it.", sort of thing.
Don't make the same mistakes Linden has.
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Yes, I do agree that this practical attempt at what sounded good in
> theory did show some serious caveats of that process.
I think the basic idea is reasonable so if there are problems
with the process the way to go may be to simply tweak the process.
Here are my 2 cents on that:
1. The POV-Ray community is strong in the forum so I think
that would be the best place for discussing (not tracking)
new feature suggestions.
2. The bug tracker could be officially extended to also track
feature requests (although you can currently add them, this
is not described or commented on anywhere). A sensible rule
for opening a new feature request would then be that it must
be discussed in the newsgroups first, to weed out crackpot
ideas and to refine ideas by feedback from what users
actually need.
3. After discussion, the request should only be entered if a member of
the POV-Ray team deems the request reasonable (note that a request
should not be deemed unreasonable at this point just because it would
be too much effort to implement right now).
4. This process only works if each feature request in the newsgroups
actually gets read by member of the POV team, so it might be useful
to add a new group povray.feature-requests or similar.
5. The feature request entry should link back to the newsgroup thread
discussing the feature request, and a link to the new task should be
posted on the thread as a notification.
6. Once a feature request is added it must remain visible whatever
state it is set to. I have no experience with Flyspray but I'd
expect there to be some configuration/solution for this.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/20/2010 4:38 PM, Patrick Elliott wrote:
> Just going to drop a comment here. For POVRay, a "democratic" vote on
> feature thing may sort of work. Linden Labs uses the same system for
> their bug/feature tracker, and its gotten to be so much of a horrible
> swamp that even finding "if" something has been suggested, so you can
> vote, or comment, never mind do so before something gets closed,or
> relocated, or incorrectly marked as fixed (this happens a bit too often
> in some cases, sometimes due to a "we think we had a fix pending, only
> it didn't work, but no one bothered to reopen the issue, when it
> failed", or just lost in the mire. My opinion of such systems is, as a
> result... rather jaded. lol Not sure, reading the posts on the subject,
> over the last 24 hours, is impressing me with it here either. Seems like
> we are seeing the same sort of issues, "I think my suggestion still
> needs time to be commented on, but someone closed it.", sort of thing.
> Don't make the same mistakes Linden has.
>
I would just like to clarify that I'm not advocating a "democratic" way
of choosing which features should and should not be implemented, or
which are that most critical. I just want a way to track and discuss
ideas that isn't subject to being "blocked" or "locked" on some dev's whim.
--
http://isometricland.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21.06.10 01:04, Christian Froeschlin wrote:
> 3. After discussion, the request should only be entered if a member of
> the POV-Ray team deems the request reasonable (note that a request
> should not be deemed unreasonable at this point just because it would
> be too much effort to implement right now).
That was my understanding of what clipka has previously suggested in this
thread already:
>> And the problem with /discussions/ about feature requests is that they
>> tend to have /no/ clear-cut result whatsoever, as they tend do be free
>> brainstorming sessions - unless there's someone with the necessary will
>> and authority (e.g. because he has started the discussion in the first
>> place) "driving" the discussion to a proper conclusion (ideally by
>> summarizing the discussion and result in a proper place... like, say,
>> the bugtracker ;-))
>>
>> (Yes, the feature request description is a good place to summarize
>> earlier discussions.)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/21/2010 10:38 AM, SharkD wrote:
> I just want a way to track and discuss
> ideas that isn't subject to being "blocked" or "locked" on some dev's whim.
I'm going to jump in here for a moment ... starting something is not my
intention, but these kind of statements can sometimes escalate things,
when it's not necessary. To be clear "whim" is just an unfair
characterization. At last count (I'm unsure) there were only a handful
of people working on issue's (getting 3.7 release ready), so there is
only a finite number of things that can be done, given personal demands
on everyones time. Now PLEASE don't take this wrong, but some of the
things that you've put forth ... well face it, you haven't done your
homework ;-) ... other things have been spot on valid. Good solid and
well thought out ideas about how things should work or be is what we all
want ... right?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|