FreeBSD9 and the sheer number of problem reports

[H]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Linimon wrote:
> On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote:
>> it is release engineering who could establish a little bit more
>> time between code-freeze and RELEASE
> 
> As you will see from the (very) long discussion that you are about
> to read, there has to be a compromise.  As it was, the release
> process was too long, not too short.
> 
> Yes, we would like to get more testers pre-release, but that seems
> to be more easily said than done.  Ideas appreciated.
> 
> You will also see in the thread that:
> 
> - it is not possible to release bug-free code, and in fact
> 
> - it is not possible to release code with no regressions
> whatsoever
> 
> if you are to ever release anything at all.
> 
> To summarize: yes, we do care: and yes, these are classical
> software engineering problems that can only be dealt with, not
> solved completely.
> 


well said, of course a dead-line is necessary, as well as pursuing
perfection is dangerous matter :)

anyway, this thread brought little suggestion or possible solutions
but lots of declaration of facts and personal interest on the table

IMO such a discussion should be strictly FreeBSD oriented and so I see
a or the missing point, a declaration of FreeBSD, what is it, for whom
is it and what does it, this statement is nonexistent, or not clear
enough. This miss affect not only users opinion but also developers work.

furthermore, plans or schedules may be perfect within it's own
restrictions, but only as good as the outcome

so the outcome must be controlled

How? ... setting the goal

are you interested in bumping the version number up or do you want to
come up with something better than the former version? If yes, what is
it? Without goal nobody can deliver predictable and defined results

steeling a good comparison from that thread you mentioned, I would
say, with the right goal you _CAN_ herd cats, instead of pied pipers
put some mice on the street :)

again IMO the version number race is suspicious and could(should) be
changed into a goal-race, then, when the goal is achieved, the the
version number may go up

with goal the outcome can be controlled, without it is loose end

it should exist a dead-line, but goal-oriented and so should be
extendable in case of failure

Resuming, I would do

 - [re]define FreeBSD
 - setting the next release goal
 - scheduling
 - go

then accompanying the ongoing work (control), assuring that the
sub-projects are within the limits, new ideas only can go into the
next schedule, a no-matter-what position of engineering is important

of course we deal with FreeBSD source, ports is a different matter and
can not be merged


tester? I would say it could be easier to have more of them, eventual
they are already there, but they are unknown,  quiet for certain
reasons, language, skills, etc

when a problem appears, point of sight is often missing, the user who
pops up has a problem, he has no interest in blaming somebody or
whatever, he like to solve the problem, so giving advices as RTFM or
similar does not help a bit, neither how to use, how to write, how to
spell or whatever other personal issue are arising. Most do not come
back after RTFM or do not even post because they heard it already once

so I would say, it does not matter how wired the PR arrives, it should
be handled by same criteria as above. What is the goal? Finding
problems in the FreeBSD code. So it does not matter which language the
guy talks, if he knows C+/- or whatever bothers you, be smart and find
out what the problem is

there are several related issues, I would start by splitting the
mailing list page on FreeBSD. Confusing for a user, he wouldn't know
which list. Directing people on first sight to a general mailing list,
perhaps no developers in it, or who has people-skills only and drain
the  results you want ... under any cost of selfishness

before the bullets fly, I am not criticizing anybody, the
tech-syndrome is natural, techs and users do not speak the same
language, techs always will classify users as stupid and users always
will classify techs as arrogant, or at least friction is natural. That
is a global unchangeable fact and we have to live with it. So mix it
up or separate it in prole of better results. It is very easy, with
machines we do it already, we write drivers ...

As above, what do you want? More PRs? ok, then again it is answered by
the goal you set. Well treated a lot of testers will appear.


- -- 
H

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iEYEARECAAYFAk9LTgoACgkQvKVfg5xjCDw8tgCfSU/IsV7S22d5AaNKiLYYwh7Z
W40An1OKxF2T275x3pMwZBXTFpGYzuBQ
=2ucy
-----END PGP SIGNATURE-----