Re: Opensource development.

Hi student,

You will excuse me to jump in discussion, but it seems necessary.

You wrote:
Enough said. You don't like "top replies" so here it is.

It is not who likes what, but what is more appropriate for the purpose.

Bottom posting allows multiple answers with quotes sorted as they were
created. It is easy to read. If timeline is not important it is irrelevant
what posting style is used, top, bottom, with or without quotes.

Here in technical newsgroup it is rare occasion to see one answer as a
solution to question, so we rather use bottom posting to make discussion
easy to read.

BTW, I don't like top posting too, if it is not productive.

<snip>
Obviously
you also don't read many release notes where it states what
was corrected & what the "known issues" are; known issues
are what still need to be done. Some developers also state
just state that there are still things that need to be fixed
or added.

You seems to miss how that information found way in release notes.
Some issues developers found themselves, others somebody told them about.
Believe me, they didn't hunt them around. They do read some mail lists,
forums and newsgroups, but for sure not all. It is impossible.

If a "developer" only is concerned with OFFICIAL problems,
then that developer isn't worth it if that person ignores
known problems because it wasn't OFFICIAL even if that
developer also experienced the same problem.

I don't know how to explain your words, but with lack of experience with
open source. Most of developers work on projects in their free time, which
is limited. They are proud if that works properly, and if they are aware of
an issue it will be solved, but there is a catch in "if they are aware".

Take for example KDE (GNOME, kernel, OpenOffice).
It is used in hundreds of distributions. Each of them has mail lists,
forums, newsgroups and each of them has tens of posts every day. That
mounts to few thousads posts every day and most of them are not KDE
related.

On the other side, within KDE you have hundreds of projects, and guy that
develops KNode wants to see KNode related bugs, where he can be helpful,
not Kopete and hundred others, where he is not familiar with development.

How much time he/she would have to spend online to catch all the bugs that
are reported in unofficial media instead of official KDE Bugzilla. My
guesstimate is few days to read only one day of communication in forums.

That is the reason that we have to report bugs on central place for the
project (you call that "official"), and let developers solve them, not
waste their time hunting them around.

<snip not related>

On 2007-08-11, houghi <houghi@xxxxxxxxxxxxxxxxxx> wrote:
student wrote:
_YOU_ are the tester who is following M$ or not. So what is the
bugnumber for this? Beta 10.3 is out, so I hope it isn't too late for
changes.

That said, I do not see the problem. I do not want to say that there
isn't one, I just do not understand what the problem is. I can
re-partition anything I desire at any moment.

houghi

EVERYONE is a tester.

That is what I am saying. And I use the meaning 'tester' very loose.

The early linux distributions that aren't into
the "nice" install procedure do allow partitioning as the installer
wishes.

Get off your high-horse. From what I've seen frequently, you so-called
experts imply that anything wrong is the users' fault; problems are
ignored or considered inconsequential.

Not me. It can be anybodies fault. It is just that IF you find a fault,
the best thing is to report it. Wether this is a design fault or a
programming fault is irrelevant.

If *YOU* only consider OFFICIAL notification is valid, then YOU are
following m$ policy; even then some bug reports are ignored, considered
user error or "wait until the next version" when you buy it.

Yep, I only consider things that the designers are aware of relevant.
The best way to tell them is to go to bugzilla and report it.

Guess you're one of those who got theirs working & the hell with other
people.

Guess you are one of those people who believe that developers are
clearvoyant.

An example. I use makeSUSEdvd and I notice that when I run it, it gives
an error when ran from within ash on a portable with 512M of memory.
I see this in version 0.1 up to version 25.7.

I can now say that the maker of that program is an idiot, or I can tell
him that I noticed it, so he can repair it.

And yes, sometimes people will read bugreports and then decide it is not
a security issue, so it will get only into the next version. Perhaps
they think it is a bad idea and will not apply it (Back letters on a
black background is not a good idea and will be ignored) or will have
such a low priority that it will be dealth with if enough people are
available.

That said, only bugs that get reported will be looked at and filtered
out.
If it isn't reported, it isn't dealth with.

If you have a way to solve issues without people knowing they are there,
please come forward, because everybody would love that solution.
Unfortunately, nobody knows that, unless you tell everybody how it works.
Bit of a catch 22. ;-)

houghi

--
Regards,
Rajko.
.

Relevant Pages

  • Re: Authentication failed suddenly
    ... >> off on such a platform, ... the developers don't consider it a fundamental part of the distribution. ... >The bugs are platform compatibility bugs. ... bugs and report them - rather than rambling in public fora ...
    (comp.security.ssh)
  • Linux community software-update-anarchy polemic (Re:)
    ... distributing knowledge of bugs is not satisfactory and should be ... which report no bugs in the "Bugs" section, ... The environment itself is a parameter to the test. ... the database holds a list of all bugs known to the developers. ...
    (comp.os.linux.misc)
  • Re: BDNradio delphi channel
    ... > for "helping" fixing errors in software they themselves have bought. ... > allows developers during their work hours work for free "helping" ... I know they contribute to the open source community and report any ... I rely on customers reporting bugs. ...
    (borland.public.delphi.non-technical)
  • Re: "Am I still working okay?" asked the micro controller...
    ... > Have one programmer insert N bugs in another programmer's code, ... The programmer who finds all of the inserted bugs and no ... I use a similar technique to keep the developers and validators ... The validators occasionally report ...
    (comp.arch.embedded)
  • Re: challenge: end of life for 6.2 is premature with buggy 6.3
    ... I reacted in anger because I felt the OP was being savagely attacked rather than being responded to with professionalism. ... Later in the thread some folks got around to asking which PRs he was referring to, but that was after attacking him for having the temerity to suggest that perhaps 6.2 shouldn't be EOL. ... When asked to provide details of the bugs or references ... I expect the FreeBSD developers to continue to produce the highest quality OS on the market. ...
    (freebsd-stable)