Clarification of Relations

Classic Servoy
21

Harjo:

And as I’ve said before, a closed bug/feature request system is a waste of my time.

David, I think you are over-reacting…
I posted this morning a bug about controller.loadRecords(myPK) in conjunction with tableFilterParam and it was fixed 4 hours later!!
In Servoy 5.1 final, 6 out of 10 of my feature requests where implemented!

It’s true, the support-system can be much approved and Servoy stated somewhere else, that they are looking into it, but stating that it is a waste of time, is not right, IMHO.

To me, a system that sort of works compared to a system that is 10x’s better than sort of works equals sort of works is a waste of my time :)

Your example highlights one of my main issues with the current system. Namely, I-don’t-have-a-flipping-clue about the bug you just posted this morning. Nor do 400 other Servoy developers.

This means that I have wasted my time two days from now if I happen upon this bug and diligently report it. It’s even a bigger waste of my time if I am putting a production solution on to 5.1 and this bug adversely affects the solution and that’s how I find out about it. It’s an even bigger bigger waste of time if the same process is repeated by many developers.

As a result, the least waste of time for me is to wait for 5.1.1 – which all of us longtime Servoy developers can reasonably predict will be out in 2-4 weeks – and use it for our start to migrate up from 5.0.1.

As I developer, I fully expect my tools to have bugs in them. My gripe is that I only know about the bugs that I find. An example from the 5.1 fix list…we’ve known about this bug since the serialize plugin was introduced and the adBlocks guys showed us the benefit of multiple references to an object (which means circa 3.1 days):

[fix] 268188 The serialize plugin produces erroneous results when serializing/deserializing objects or arrays which contain two different references to the same object

It easily took us a number of hours to figure this out originally. It took us quite a few hours to figure out ways around it. How many other developers have done the same thing over the past 2-3 years because they didn’t know about this bug?

An example of how things should work: Patrick’s BrowserSuite. All known bugs are listed. And who would guess, but the very first thing our client did – absolute first thing – was try it out on a 64-bit system. To see this listed as a known bug is a powerful psychological difference from not knowing if we’re doing something wrong. And it saved us loads of time trying to confirm that indeed it was bug by doing all sorts of tests. As a result of Patrick’s open system, we were able to put the browser suite into production several versions ago (it’s still in beta) and he gets a ton of valuable feedback from us that is shared with other browser suite users. Like you :)

So I’m standing by my assertion that Servoy bug/feature system is a waste of my time. Any process that involves a lot of people and is not collaborative is bogus.

If you want us to be involved – and you know we will – don’t blatantly waste my time.

22

David,

I think you’re confusing “not optimal” with “not working”.
I can tell you the Servoy support system is working alright. Sure there are always things that can be better.
But by simply refusing to use it you only do yourself and the other Servoy users a de-service.
The forum is not the way to track any feature request nor bugs. It is however a way to discuss certain cases before (or after) someone files it in the support system. But you know that already.

So if you want more features in the support system I suggest you file it there and link it to a thread here on the forum where you call for votes in this feature.

23

David,

i’m still not convinced! ;-)
Ofcourse known bugs (limitations) are in the docs & wiki’s of Servoy also.
Where is Patrick’s (open?) bug system?

if I post/mail a bug for Patrick Browsersuite, where can you find it? or see it?

24

ROCLASI:
David,

I think you’re confusing “not optimal” with “not working”.
I can tell you the Servoy support system is working alright. Sure there are always things that can be better.
But by simply refusing to use it you only do yourself and the other Servoy users a de-service.
The forum is not the way to track any feature request nor bugs. It is however a way to discuss certain cases before (or after) someone files it in the support system. But you know that already.

So if you want more features in the support system I suggest you file it there and link it to a thread here on the forum where you call for votes in this feature.

Collaborative processes have been proven to be orders of magnitude more productive over non-collaborative processes. In my mind, it’s not a matter of it could be improved a little bit. If that were the case, I wouldn’t be making a big deal over it. But it really is way less effective than it should be considering Servoy wants us to be actively helping them out to find bugs.

If the process is open and collaborative, we are very active contributors. If the Servoy bug/feature system were open and collaborative, we would be glued to it like flies to a fly trap. It would literally be the best tool in our toolbox.

25

Harjo:
David,

i’m still not convinced! ;-)
Ofcourse known bugs (limitations) are in the docs & wiki’s of Servoy also.
Where is Patrick’s (open?) bug system?

if I post/mail a bug for Patrick Browsersuite, where can you find it? or see it?

Download packages:

  • the PDF FAQ please read carefully!
26

david:
Collaborative processes have been proven to be orders of magnitude more productive over non-collaborative processes. In my mind, it’s not a matter of it could be improved a little bit. If that were the case, I wouldn’t be making a big deal over it. But it really is way less effective than it should be considering Servoy wants us to be actively helping them out to find bugs.

So because it’s less effective you don’t want to use it at all…which is not effective at all. I don’t really get that logic.

david:
If the process is open and collaborative, we are very active contributors. If the Servoy bug/feature system were open and collaborative, we would be glued to it like flies to a fly trap. It would literally be the best tool in our toolbox.

Did you filled a feature request for this in the support system ? Ever?

27

david:

ROCLASI:
David,

I think you’re confusing “not optimal” with “not working”.
I can tell you the Servoy support system is working alright. Sure there are always things that can be better.
But by simply refusing to use it you only do yourself and the other Servoy users a de-service.
The forum is not the way to track any feature request nor bugs. It is however a way to discuss certain cases before (or after) someone files it in the support system. But you know that already.

So if you want more features in the support system I suggest you file it there and link it to a thread here on the forum where you call for votes in this feature.

Collaborative processes have been proven to be orders of magnitude more productive over non-collaborative processes. In my mind, it’s not a matter of it could be improved a little bit. If that were the case, I wouldn’t be making a big deal over it. But it really is way less effective than it should be considering Servoy wants us to be actively helping them out to find bugs.

If the process is open and collaborative, we are very active contributors. If the Servoy bug/feature system were open and collaborative, we would be glued to it like flies to a fly trap. It would literally be the best tool in our toolbox.

David, I have mentioned before that this is something we are working on, we read the forum and process feedback. Harjo and Robert are giving positive, usable feedback: this helps building a community. Just being negative does not add any value to the discussion.

28

ROCLASI:

david:
Collaborative processes have been proven to be orders of magnitude more productive over non-collaborative processes. In my mind, it’s not a matter of it could be improved a little bit. If that were the case, I wouldn’t be making a big deal over it. But it really is way less effective than it should be considering Servoy wants us to be actively helping them out to find bugs.

So because it’s less effective you don’t want to use it at all…which is not effective at all. I don’t really get that logic.

The logic is that it is way more time effective for us to lag behind official releases a couple of steps and let other people find the bugs than it is to stay current. And we’re hardly the only developers who have fallen into this pattern. I’d rather contribute in a way that is productive for everyone and still get my own work done.

ROCLASI:

david:
If the process is open and collaborative, we are very active contributors. If the Servoy bug/feature system were open and collaborative, we would be glued to it like flies to a fly trap. It would literally be the best tool in our toolbox.

Did you filled a feature request for this in the support system ? Ever?

If bringing this up behind the scenes for the past two years counts, then yes.

29

david:

ROCLASI:

david:
Collaborative processes have been proven to be orders of magnitude more productive over non-collaborative processes. In my mind, it’s not a matter of it could be improved a little bit. If that were the case, I wouldn’t be making a big deal over it. But it really is way less effective than it should be considering Servoy wants us to be actively helping them out to find bugs.

So because it’s less effective you don’t want to use it at all…which is not effective at all. I don’t really get that logic.

The logic is that it is way more time effective for us to lag behind official releases a couple of steps and let other people find the bugs than it is to stay current. And we’re hardly the only developers who have fallen into this pattern. I’d rather contribute in a way that is productive for everyone and still get my own work done.

But when you do find something or even want a feature request you refuse to use the support system. That’s what I call a de-service to the community. Hence me not getting your logic.

david:

ROCLASI:

david:
If the process is open and collaborative, we are very active contributors. If the Servoy bug/feature system were open and collaborative, we would be glued to it like flies to a fly trap. It would literally be the best tool in our toolbox.

Did you filled a feature request for this in the support system ? Ever?

If bringing this up behind the scenes for the past two years counts, then yes.

So the answer to my question is then No, you never filled it in the support system, ever.

30

Jan Aleman:
David, I have mentioned before that this is something we are working on, we read the forum and process feedback.

Specifics?

31

david:

Harjo:
David,

i’m still not convinced! ;-)
Ofcourse known bugs (limitations) are in the docs & wiki’s of Servoy also.
Where is Patrick’s (open?) bug system?

if I post/mail a bug for Patrick Browsersuite, where can you find it? or see it?

Download packages:

  • the PDF FAQ please read carefully!

I would simply add that I have opened google code sites for all the beans/plugins I have created (there is a link on the respective bean/plugin page on my site). I haven’t done so in the past because this stuff was little enough and worked alright, but now that I have to maintain different source codes for different releases of Servoy, I felt the need to do so.

I have also updated the busy-plugin google code site’s issue list with info about what I know of.

I invite anyone using my beans/plugins to use these sites to report any problem.

As for the browser suite, I haven’t figured out yet how to package the sources (with 4 interdependent projects and many dependencies on other projects and setup to be done in Eclipse) in one single google code repository but the browser-suite google site has been opened a while ago.

I did this because I wanted to use the already setup issue system that anyone can use to submit a bug, comment on existing bugs and see what is curently the state of the project. I need to find the time to put what is in the FAQ into the issue list, but I will, and I hope that people will use this to submit their reports too.

Know that I’m using Mylyn to connect to these issue lists, meaning that as soon as a bug is reported, it automatically creates a task in my Eclipse IDE, where I can report from also…

This is for open issue systems.
So I mostly agree with David with the fact that it is a must have for a developer tool and without it, we lose a lot of time, because we don’t really know what to expect before it hits us back coming from our clients…

The fact that historically Servoy has build his own custom issue system as a closed solution doesn’t mean that they should not open it at one point. Everyone, included Servoy, would see the benefit of it.
I guess that they understand that too, or so the rumour has it… :)

In the meantime, yes… Servoy is usually very quick on working on the issues submitted which is greatly appreciated!
But the visibility factor (what to expect with what version - should I upgrade/downgrade? what are the open issues? and what are the workarounds?, etc.) is badly missing and sometimes, especially when you hit one of these ‘unknown to you’ issue, it makes you think of how such a (seemingly) little change as an open issue tracking system would help you, or makes you mad at how not having this (seemingly) little change has made you lose so much time…

Finally: a note to the moderator. Please keep the core of this thread, edit if necessary, but I’d like to keep it as a bookmark/reference on how to understand relations and the 3 little checkbox. Each time I look at them, I scratch my head, I’m that dumb! :cry:

32

david,

first i am not against a more open bugsystem. but to say that users that really know what others doing and that they see the bug of others before posting them…
thats not really true…

I monitor and work with a lot of open bug systems (wicket,eclipse,maemo) and do you know how many people just enter a new bug without searching for it (or maybe it is sometimes difficult to search for…)
I think in the end, closed->duplicate is the resolution that is mostly used…

Even in this types of open forums. how many times the same question is asked before?

33

I can’t speak for how other people but I know what we do to stay current:

  • diligently monitor the forum
  • talk with other developers
  • understand every bug fix on new releases, often build test cases to verify
  • build demo files for all new features
  • test, test, test

We work very hard to know Servoy inside and out. And it’s not just the capabilities that we’re concerned about, it’s the shortcomings as well. Our knowledge of capabilities is why we get paid; our lack of knowledge of the shortcomings is what loses us money.

I can only say that with an open bug system added to the mix, we would be monitoring it like a hawk. Because there is a good possibility that what Harjo posted yesterday morning will save me time and effort today.

So maybe there is several different types of Servoy developers. I see your point about duplication, not searching before posting, etc but this doesn’t apply to those of us that make it our job to know everything there is about Servoy. We’re the people who find the most obscure bugs, know how to give you good debug information, and can add many testing hours to other developers submissions.

A case in point is the style sheets not caching bug which was a significant find to our credit. After spending 50+ man hours to figure that one out, to hear that you already had it on your list wasn’t all that pleasant. Knowing that this was an open issue could potentially have saved us a ton of time narrowing down the cause for this bug. Instead, we had to do it blindly through an exhaustive process of ruling out possibilities. It was brutal.

Interestingly enough, the very next Servoy release had a big marketing point about how the smart client was 2-3x’s faster than previous. If we hadn’t found that bug…

So I am fully committed to providing valuable information to you. In return, it would be highly valuable to me to see what others are submitting, compare notes and comment on other submissions, and basically link arms with other developers in a community way instead of each of us limited to our own separate sandbox of known bugs.

Add this leverage to the justly famous and appreciated response time by you and Servoy to fix things – I think it would produce very good results.

34

Hi Johan,

jcompagner:
I monitor and work with a lot of open bug systems (wicket,eclipse,maemo) and do you know how many people just enter a new bug without searching for it (or maybe it is sometimes difficult to search for…)

I don’t think that penalizing serious developers who care about knowing the platform in and out by not giving them the right tools to do so is the appropriate answer to the problem. Of course people sometimes misuse support, does this mean that providing support is bad?

jcompagner:
I think in the end, closed->duplicate is the resolution that is mostly used…

Even in this types of open forums. how many times the same question is asked before?

Exactly. Setting the status of an issue to closed->duplicate and point people to it would probably be less time consuming for you than having to answer to the same questions over and over again on this very forum, Johan.

35

david:
A case in point is the style sheets not caching bug which was a significant find to our credit. After spending 50+ man hours to figure that one out, to hear that you already had it on your list wasn’t all that pleasant. Knowing that this was an open issue could potentially have saved us a ton of time narrowing down the cause for this bug. Instead, we had to do it blindly through an exhaustive process of ruling out possibilities. It was brutal.

About this one David, I remember it well. I was one of the users who reported it to you.
And it was a major factor of decision which lead my company change his idea about buying your framework.

Would an open issue system have solved the problem? - probably not.
But it sure would have helped us all have better confidence, knowing the issues in advance, or even simply being pointed to it, than discovering it by ourselves the hard way.

36

ptalbot:

david:
A case in point is the style sheets not caching bug which was a significant find to our credit. After spending 50+ man hours to figure that one out, to hear that you already had it on your list wasn’t all that pleasant. Knowing that this was an open issue could potentially have saved us a ton of time narrowing down the cause for this bug. Instead, we had to do it blindly through an exhaustive process of ruling out possibilities. It was brutal.

About this one David, I remember it well. I was one of the users who reported it to you.
And it was a major factor of decision which lead my company change his idea about buying your framework.

Would an open issue system have solved the problem? - probably not.
But it sure would have helped us all have better confidence, knowing the issues in advance, or even simply being pointed to it, than discovering it by ourselves the hard way.

Totally agree. I don’t mind finding and solving bugs. What I really mind is finding and solving bugs already known and being found by other people.

The Sevoy 5.1 release is an example (AKA “The biggest bug fix in history”). On the one hand you can say, “Cool, look at all the stuff they’ve fixed!” But if you’re a sarcastic nut like me your first reaction is, “Damn, look at that list of bugs I didn’t know about.”

Not knowing about bugs until they’re fixed or you run into them personally (hopefully as many as possible in testing) is not a confidence booster if you have a bunch of large deployed systems that you are responsible for.

If I move to Servoy 5.1 today, what bugs are already on the list? What are the next enhancements planned? This is critical information when keeping deployed systems current. Knowing this as we made the transition to Servoy 5 these past several months would have made a significant difference in our frustration level. There were times where it felt like navigating a mine field without a map.

Thanks for the fixes Servoy…but just know that some of those bugs cost us a lot of time. Some of which were likely found by others before we did and some of which you already knew about when you released Servoy 5.0.

37

david:

ptalbot:

david:
A case in point is the style sheets not caching bug which was a significant find to our credit. After spending 50+ man hours to figure that one out, to hear that you already had it on your list wasn’t all that pleasant. Knowing that this was an open issue could potentially have saved us a ton of time narrowing down the cause for this bug. Instead, we had to do it blindly through an exhaustive process of ruling out possibilities. It was brutal.

About this one David, I remember it well. I was one of the users who reported it to you.
And it was a major factor of decision which lead my company change his idea about buying your framework.

Would an open issue system have solved the problem? - probably not.
But it sure would have helped us all have better confidence, knowing the issues in advance, or even simply being pointed to it, than discovering it by ourselves the hard way.

Totally agree. I don’t mind finding and solving bugs. What I really mind is finding and solving bugs already known and being found by other people.

The Sevoy 5.1 release is an example (AKA “The biggest bug fix in history”). On the one hand you can say, “Cool, look at all the stuff they’ve fixed!” But if you’re a sarcastic nut like me your first reaction is, “Damn, look at that list of bugs I didn’t know about.”

Not knowing about bugs until they’re fixed or you run into them personally (hopefully as many as possible in testing) is not a confidence booster if you have a bunch of large deployed systems that you are responsible for.

If I move to Servoy 5.1 today, what bugs are already on the list? What are the next enhancements planned? This is critical information when keeping deployed systems current. Knowing this as we made the transition to Servoy 5 these past several months would have made a significant difference in our frustration level. There were times where it felt like navigating a mine field without a map.

Thanks for the fixes Servoy…but just know that some of those bugs cost us a lot of time. Some of which were likely found by others before we did and some of which you already knew about when you released Servoy 5.0.

I agree with David.

A kind of knowledge base with cases fixed per date/version and cases under investigation would be very welcome !

Also the top 20 of voted feature requests would be great (and the possibilty to vote of course)

Regards and keep smiling :D

38

david:
A case in point is the style sheets not caching bug which was a significant find to our credit. After spending 50+ man hours to figure that one out, to hear that you already had it on your list wasn’t all that pleasant. Knowing that this was an open issue could potentially have saved us a ton of time narrowing down the cause for this bug. Instead, we had to do it blindly through an exhaustive process of ruling out possibilities. It was brutal.

Interestingly enough, the very next Servoy release had a big marketing point about how the smart client was 2-3x’s faster than previous. If we hadn’t found that bug…

for your point of view this is a very bad example…

That specific thing was not in a our bug system at all.
Also that fix was only a by product of the real feature we did market (compressing sockets)

Because i was developing the compressing sockets. i was monitoring all traffic that did pass through them (and really output every call and every number of bytes that a call resulted in, output and input)
and then i did notice that certain style sheets where constantly get from the server.
It was a big coincidence that almost at the same time you also reported it.

Still if we had something like “style sheet performance problem” in our bug list. Would you have figured it out that that was the thing that bugged you?
You first have to know what does bug you before you can search for it…

39

All,

Lets end the going back and forth here.

@David/Patrick/…: the point has been made, as it has been before and as we have mentioned before: it has our attention, we are looking into it.

@JT: is your question about relations answered now?

For the future: please keep threads on topic…

Paul

40

pbakker:
All,

Lets end the going back and forth here.

@David/Patrick/…: the point has been made, as it has been before and as we have mentioned before: it has our attention, we are looking into it.

@JT: is your question about relations answered now?

For the future: please keep threads on topic…

Paul

Hi Paul,
Thanks for your attention!
'Re: Clarifications of Relations": I thought this was related ;-)