freebsd stable - Dec 2005 - Upgrading 5.3 > 6.0 buildworld failure now in libmagic

> 
> From: Peter Jeremy <PeterJeremy@optushome.com.au>
> Date: 2005/12/08 Thu AM 01:34:42 PST
> To: Vizion <vizion@vizion.occoxmail.com>
> CC: Doug Barton <dougb@freebsd.org>,  freebsd-stable@freebsd.org
> Subject: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
> 
> On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote:
> >Well having run many very large scale projects myself I  find it
difficult to
> >accept either implication of this perspective.
> 
> There's a massive difference between running a large commercial project
> and running a large open source project using volunteers.  
Not really I have done both and found that shared values and community
collaboration work the same.
>On a commercial
> project, you can direct someone to do something and they have a choice of
> either doing it or finding another job.  
Well that kind of development environment (rule by dictat) does not work very
well. Developers are people who are engaged in a collaborative process. If you
encourage them to think like prima donas then they will behave like prima donas
rather than as part of an integrated team.
>On a volunteer project, there's
> a limit to how far you can push someone to do something they don't
enjoy
> before they just leave.
Push has it limitations everywhere.. goals and communal rewards are better in
both volunteer and commercial projects.
> 
> > The first implication is that 
> >we should be complacent about it and not seek to find a method to
improve the
> >process.
> 
> I don't think anyone is suggesting this.  In my experience, the FreeBSD
> project is always open to process improvements - this is especially
> obvious in the documentation and release engineering areas.
> 
 The question is about the degree of committment to process change not whwther
it is absent or present. The critique is there is tooo little comitment to
process change and too much resistance to greater concentration on the quality
of user docuimentation and the significance of that work in the developmenmt
cycle.

> >>Most of our really top 
> >>notch developers are actually very bad at documenting their work (I
don't
> >>mean bad at being timely with it, I mean that they are bad at DOING
it), and
> >>frankly their time is better spent elsewhere. 
> >
> >That is a judgment call - franky my experience has been that developers
who
> >are bad at ensuring their work is well documentated are second rate
rather
> >than top rate developers.
> 
> Software developers are notoriously poor at writing documentation for
> non-technical people.  There are probably very few developers who
> enjoy writing end-user documentation (and can write).  In my
> experience, especially on large projects, it's rare for developers to
> write the end-user documentation.  
NOTE I said"
 F:ranky my experience has been that developers who are bad at
ENSURING 
their work is well documentated are second rate rather than top rate developers.
The work of the technical writer needs to influence development at the design
stage! It does not matter whether the developer does or does not write the the
documentation but it does matter whether the developer is  COMIITED to both
ensuring that there is proper documentation AND that the documentation process
is an integral part of the development process that influences its outcome.
>They may write a rough outline but
> it's the technical writers who actually do the documentation.  
The outline for  user documentation needs to be structured  BEFORE development
begins NOT  as an afterthought. In a well structured development environment
documentation is part of DESIGN not post design implementation . That is because
thinking about end user at the design stage is necessary if the outcome of the
process is going to be user centric. 
>The
> problem is finding people with technical writing skills who are
> interested in helping with FreeBSD.
>
Freebsd needs to reorganize the way it develops if it is going to interest techn
ical writers. No technical writer wants to be associated with writing documnets
for developments that have been poorly designed for the end user. Clearing up
someone else's mess is no fun. If you treat technical writers as people who
come along afterwards and pick up yopur trash OF COURSE you will not get them
involved. You need to ask WHY it is difficult to get them.  It is because
freebsd does not produce software with a focus on end user satisfaction. This is
a chicken and egg problem that  can only be solved by a fu8ndamental shift both
the focus of development objectives and the development
process.
> 
> It's also worth noting that a number of FreeBSD developers are not
native
> English speakers.  It's probably unreasonable to expect them to write
> polished English documentation.
> 
> >What I have found works in development is to create team relationships
that
> >cover design, development and documentation.
> 
> I agree that this is a good approach.  It's similar to the
'surgical
> team' approach that Brooks recommends in "The Mythical
Man-Month".  I
> think that this does happen to some extent in FreeBSD but agree it
> could be more widespread.  (Though it is probably harder to put it into
> practice in a distributed, volunteer project than when the team share
> a cubicle).
> 
I do not agree -- it mkay be harder for some people to accept that they cannot
be part of a freebsd development team if they are not committed to playing their
part in ensuring high quality  documentaion  and the need for integrating
documentation into the development process. there can be no place for prima
donas in a communal development project.
> >My view would be that the freebsd project might do well to consider 
> >implementing a "no release without quality documentation
assurance" policy.
> ...
> >development is so good. It deserves better and more professional
attention to
> >the role of end user documentation.
> 
> Are you volunteering?
I would if I saw signs of  change but I am pretty despairfull about how illing
the core group are to revising the way in which the process happens. The way
things have been throughout freebsd history does not give me much confidence of
its capacity to make the philosophical and structural changes that are needed to
make user documentation a key part of the devlopmental cycle with an ability for
user friendliness and user needs to influence the what, why, how, when and (and
even the where) of devlopment.

I think there may be greater hope in creating a project that can place an
interface layer that runs on top of freebsd to ensure that freebsd is relevant
in ten years. That is a project I am currently thinking about and wondering
whether I have the time and energy available to kick start such an
endeavor.
>

> 
> From: "Matthew D. Fuller" <fullermd@over-yonder.net>
> Date: 2005/12/08 Thu AM 08:01:47 PST
> To: Peter Jeremy <PeterJeremy@optushome.com.au>
> CC: Doug Barton <dougb@freebsd.org>,  freebsd-stable@freebsd.org, 
> 	Vizion <vizion@vizion.occoxmail.com>
> Subject: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
> 
> On Thu, Dec 08, 2005 at 08:34:42PM +1100 I heard the voice of
> Peter Jeremy, and lo! it spake thus:
> > On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote:
> > >development is so good. It deserves better and more professional
> > >attention to the role of end user documentation.
> > 
> > Are you volunteering?
> 
> It should be noted that this sort of response often comes across
> rather sneering and snarky, but (most of the time, anyway) it's really
> not meant to.  It often DOES translate pretty directly to "Yes, that
> would be nice, and it would be really great if somebody who was
> interested and capable were to grab the reins and do it."
> 
> 
Do you mean the response sounds like freebsd documentation <chuckles>

See my last email for a response to that one !

ATM I am struggling on a win machine because my local server once more refused
to upgrade to 6.0 and this time has bombed outcompletely - looks nlike a
complete rebuild
david
> -- 
> Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
> Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
>            On the Internet, nobody can hear you scream.
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
>

On Thursday 08 December 2005 08:57, vizion@vizion.occoxmail.com
wrote:
> > From: Peter Jeremy <PeterJeremy@optushome.com.au>
> > Date: 2005/12/08 Thu AM 01:34:42 PST
> > To: Vizion <vizion@vizion.occoxmail.com>
> > CC: Doug Barton <dougb@freebsd.org>,  freebsd-stable@freebsd.org
> > Subject: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
> >
> > On Wed, 2005-Dec-07 13:34:53 -0800, Vizion wrote:
> > >Well having run many very large scale projects myself I  find it
> > > difficult to accept either implication of this perspective.
> >
> > There's a massive difference between running a large commercial
project
> > and running a large open source project using volunteers.
>
> Not really I have done both and found that shared values and community
> collaboration work the same.
>
> >On a commercial
> > project, you can direct someone to do something and they have a choice
of
> > either doing it or finding another job.
>
> Well that kind of development environment (rule by dictat) does not work
> very well. Developers are people who are engaged in a collaborative
> process. If you encourage them to think like prima donas then they will
> behave like prima donas rather than as part of an integrated team.
>
> >On a volunteer project, there's
> > a limit to how far you can push someone to do something they don't
enjoy
> > before they just leave.
>
> Push has it limitations everywhere.. goals and communal rewards are better
> in both volunteer and commercial projects.
>
> > > The first implication is that
> > >we should be complacent about it and not seek to find a method to
> > > improve the process.
> >
> > I don't think anyone is suggesting this.  In my experience, the
FreeBSD
> > project is always open to process improvements - this is especially
> > obvious in the documentation and release engineering areas.
>
>  The question is about the degree of committment to process change not
> whwther it is absent or present. The critique is there is tooo little
> comitment to process change and too much resistance to greater
> concentration on the quality of user docuimentation and the significance of
> that work in the developmenmt cycle.
>
> > >>Most of our really top
> > >>notch developers are actually very bad at documenting their
work (I
> > >> don't mean bad at being timely with it, I mean that they
are bad at
> > >> DOING it), and frankly their time is better spent elsewhere.
> > >
> > >That is a judgment call - franky my experience has been that
developers
> > > who are bad at ensuring their work is well documentated are
second rate
> > > rather than top rate developers.
> >
> > Software developers are notoriously poor at writing documentation for
> > non-technical people.  There are probably very few developers who
> > enjoy writing end-user documentation (and can write).  In my
> > experience, especially on large projects, it's rare for developers
to
> > write the end-user documentation.
>
> NOTE I said"
>  F:ranky my experience has been that developers who are bad at
> ENSURING
> their work is well documentated are second rate rather than top rate
> developers. The work of the technical writer needs to influence development
> at the design stage! It does not matter whether the developer does or does
> not write the the documentation but it does matter whether the developer is
>  COMIITED to both ensuring that there is proper documentation AND that the
> documentation process is an integral part of the development process that
> influences its outcome.
>
> >They may write a rough outline but
> > it's the technical writers who actually do the documentation.
>
> The outline for  user documentation needs to be structured  BEFORE
> development begins NOT  as an afterthought. In a well structured
> development environment documentation is part of DESIGN not post design
> implementation . That is because thinking about end user at the design
> stage is necessary if the outcome of the process is going to be user
> centric.
>
> >The
> > problem is finding people with technical writing skills who are
> > interested in helping with FreeBSD.
>
> Freebsd needs to reorganize the way it develops if it is going to interest
> techn ical writers. No technical writer wants to be associated with writing
> documnets for developments that have been poorly designed for the end user.
> Clearing up someone else's mess is no fun. If you treat technical
writers
> as people who come along afterwards and pick up yopur trash OF COURSE you
> will not get them involved. You need to ask WHY it is difficult to get
> them.  It is because freebsd does not produce software with a focus on end
> user satisfaction. This is a chicken and egg problem that  can only be
> solved by a fu8ndamental shift both the focus of development objectives and
> the development process.
>
> > It's also worth noting that a number of FreeBSD developers are not
native
> > English speakers.  It's probably unreasonable to expect them to
write
> > polished English documentation.
> >
> > >What I have found works in development is to create team
relationships
> > > that cover design, development and documentation.
> >
> > I agree that this is a good approach.  It's similar to the
'surgical
> > team' approach that Brooks recommends in "The Mythical
Man-Month".  I
> > think that this does happen to some extent in FreeBSD but agree it
> > could be more widespread.  (Though it is probably harder to put it
into
> > practice in a distributed, volunteer project than when the team share
> > a cubicle).
>
> I do not agree -- it mkay be harder for some people to accept that they
> cannot be part of a freebsd development team if they are not committed to
> playing their part in ensuring high quality  documentaion  and the need for
> integrating documentation into the development process. there can be no
> place for prima donas in a communal development project.
>
> > >My view would be that the freebsd project might do well to
consider
> > >implementing a "no release without quality documentation
assurance"
> > > policy.
> >
> > ...
> >
> > >development is so good. It deserves better and more professional
> > > attention to the role of end user documentation.
> >
> > Are you volunteering?
>
> I would if I saw signs of  change but I am pretty despairfull about how
> illing the core group are to revising the way in which the process happens.
> The way things have been throughout freebsd history does not give me much
> confidence of its capacity to make the philosophical and structural changes
> that are needed to make user documentation a key part of the devlopmental
> cycle with an ability for user friendliness and user needs to influence the
> what, why, how, when and (and even the where) of devlopment.
>
> I think there may be greater hope in creating a project that can place an
> interface layer that runs on top of freebsd to ensure that freebsd is
> relevant in ten years. That is a project I am currently thinking about and
> wondering whether I have the time and energy available to kick start such
> an endeavor.
>
Vison, you are much better at writting florid prose on how and why FreeBSD is 
such an awful OS run by a team of Techies who care nothing about end users 
needs than you are at reading and comprehending simple instructions.

 What you write is almost believable, your writing skill is very good and 
convincing, only in this particualr case I know you are completely wrong and 
your failure to follow the simplest advice is why your machine is now non 
operational.  Quit crying about non relevent issues and concentrate on 
solving your real problem - getting that darn machine to boot up.

One last thought, name one OS that has better documentation than FreeBSD
please, comercial or otherwise.  Maybe there is such a beast, if so I am very 
curious to know what it is called.

-Mike

> -----Original Message-----
> From: Michael C. Shultz [mailto:ringworm01@gmail.com]
> Sent: Friday, December 09, 2005 10:32 AM
> To: vizion
> Cc: 'Peter Jeremy'; 'Doug Barton'
> Subject: Re: Upgrading 5.3 > 6.0 buildworld failure now in libmagic
> 
> On Friday 09 December 2005 09:39, vizion wrote:
> > > Vison, you are much better at writting florid prose on how and
why
> > > FreeBSD is
> > > such an awful OS run by a team of Techies who care nothing about
end
> > > users needs than you are at reading and comprehending simple
> > > instructions.
> > >
> > >  What you write is almost believable, your writing skill is very
good
> and
> > > convincing, only in this particualr case I know you are
completely
> wrong
> > > and
> > > your failure to follow the simplest advice is why your machine is
now
> non
> > > operational.  Quit crying about non relevent issues and
concentrate on
> > > solving your real problem - getting that darn machine to boot up.
> > >
> > > One last thought, name one OS that has better documentation than
> FreeBSD
> > > please, comercial or otherwise.  Maybe there is such a beast, if
so I
> am
> > > very
> > > curious to know what it is called.
> >
> > Mike
> >
> > Rather than replying to the list I am emailing you direct and cc onl;y
> the
> > individuals to whom you cc'd your original.
> >
> > Frankly I never ceased to be amazed at diversionary personalized
attacks
> > that seem to be a regular occurrence on freebsd lists whenever someone
> > makes friendly but critical observations about freebsd.  There is a
> > touchyness there which is a big deterrent to the engagement of others
> and a
> > tendency to paternalize which, on rare occasions, is an unspeakably
ugly
> > aspect of some freebsd interactions.
> >
> > I do not know the root cause of such over-defensiveness I am
constantly
> > amazed when old timers do not recognize it. It is time to grow up and
I
> > hope something will happen to discourage people from arguing ad
> personam.
> >
> > Your remarks seem to have been written with the deliberate intention
of
> > attacking the messenger rather than discussing the message. You did
not
> > even aspire to achieving accuracy.
> >
> > The fact the my system did upgrade successfully from 5.3 to 5.4 by
> > following your advice does not give you the right to make false
> assumptions
> > about a failed upgrade from 5.4 to 6.0 that is due to a combination of
> > events that have nothing whatsoever to do with the topic under
> discussion,
> > advice that has been given or even freebsd or its documentation. It
> turns
> > out that a motherboard hardware failure was the casue of the upgrade
> > failure.. hence I have to do a total rebuild because the motherboard
is
> no
> > longer available.
> 
> 
> And this is your excuse for attacking the FreeBSD organization?  
No  and I have nott attacked "the organization".  The c ritic of the
way in
which documentation is  not integrated ionto the freebsd development cycle
was made long before there was any motherboard failure.  I do wish you would
stick to the facts. 



I'm sure
> everyone feels bad for you that you have to get a new motherboard.   I am
> confused as to how better coordination between developers and technical
> writers could have prevented it from failing though.

I have not made that suggestion - only you have put forward that notion --
come on laugh a bit - you are really being a bit wild and cranky over this
<chuckles>. The motherboard failure occurred after the discussion on
documentation not before <GRINZ> you really are missing the point
here.
> >
> > As for the use of  perjorative terminology (florid prose) and false
> > accusations - I am really personally very disappointed in your
> reactions.
> >
> > What you seemed to be saying was that you were unable to counter my
> > suggestions which were so unwelcome to you that you chose to attack me
> > personally.
> 
> Your suggestions were irrelevent to the problem at hand. 
My suggestions are very relevant to the documentary errors, omissions and
lack of documentary integration that waste much of the time of many end
users. 
 

My suggestions were, it is true, were off the original topic and came about
as a response to someone else who complained about freebsd documentation and
I responded to him. 

He was strongly critical because the  documentation stated that direct
upgrade from 5.3 to 6.00 was possible when, as you pointed out, it was not. 

I suggest you reread the whole thread with care and look at the sequence of
events instead of massaging a false interpretation events to satisfy a
desire to argue add personam..
> tecnical
> help that is one thing, if you want to improve documentaion that is
> another
> topic with it's own mail list.
I see this as more diversionary BS you could have said:
"Hey david -- sorry I should not have jumped to conclusions"
> >
> > I am disappointed that you react that way to me and even more
concerned
> > that those who have been around far less years than I will be
> intimidated
> > by this kind of BS
> >
> > Please grow up
> >
> > david
> 
> One last point, either remove me from the reply to list or place the
> maillist
> back on it, thank you.
I think you owe me an apology - but I doubt I will get it.


OK I will send this to the list
> 
> -Mike