Re: 1.4 updates

[John Sheehan Sun Microsystems Ireland <John Sheehan ireland sun com>]

Hi,

Definitely users should have a facility to give feedback to the 
developers.  

But bug-reports and product support can have a channel other than 
directly back to the developers.  As Gnome becomes ever more pervasive,
the developers will not wish to deal with every bug report.  That is 
the job of intervening support groups who typically address and filter 
out all but the most complex problems which they might send on to the 
developers

Gnome support channels are confusing.  Gnome generally uses Bug-Buddy 
which emails reports to submit bugs gnome org   Ditto for Evolution 
except the bugs should be emailed to submit bugs helixcode com  
Nautilus uses Mozilla.  Red Hat has its own Mozilla bug database.

If I look at Red Hat Linux 6.2, the Authors section of the Gnome 
Terminal User Guide omits the feedback/bug-reporting paragraphs, 
because to include them would invalidate Red Hat's business model.

Sun could equally change or omit sections of the Help Guides to meet 
Sun's needs and guidelines.  All our subsequent translations of our 
version of the Help, while available to the Gnome community, would
be of limited use to the community since they would derive from a 
similar yet different base document.  

Should Help only describe how the application works, and should it 
omit 'packaging' issues and 'status' e.g. "This applet has no known
bugs" ?

John


On Thu, Oct 05, 2000 at 4:00:36PM -0400, Alexander Kirillov wrote:

> 
> I have two comments. First, I'd like this thing - replacing
> feedback address by some common entity - to be discussed by developers
> - it is not to us to decide. E.g., maybe some developers want all
> feedback be sent ot them, not to Sun or HP, even by people who bought
> a copy of Gnome with Solaris. In particular, I'll not change the
> feedback address in gnome-terminal docs until I get OK from Miguel. 
> 
> Second: Dan, you got me lost with all these entity things. The only
> entites you can declare in sgml files are either "public" ones - the
> ones listed in catalog file - or those for which you provide  absolute
> path, no env. variables allowed. You can not declare an entity using
> $PREFIX.  Or at least so I thought. Can anyone clarify this?? 
> 
> The only solution I see is that you use $PREFIX in sgml file as it is
> in cvs, and during build time, 'make' replaces this by appropriate
> path. So in sgml files shipped with binary packages, there will be no
> $PREFIX. 
> 
> Sasha
> 
> 
> 
> 
> On Thu, Oct 05, 2000 at 10:39:40AM -0500, Dan Mueth wrote:
> > 
> > Michael has a good idea here.  We should do this by declaring system-wide
> > entities which fill in some of this boiler-plate text.  In his example, we
> > would need two entities, one for the doc comments/bugs and one for the app
> > comments/bugs.  Not only does this make it easy for Sun to have its
> > customers send bug reports to them if it likes (we will need to separately
> > discuss how to share bug databases), it also makes it easier for the GDP
> > to update all of its docs simulataneously.  We should similarly produce an
> > entity which we use in the license section at the end of each doc.
> > 
> > How should we do this?  We could use parameter entities in the DTD, but we
> > should very strongly avoid this IMO since it means we are no longer
> > strictly DocBook-compliant. So, unless I'm missing something, we have to
> > use external entities.  Two methods come to mind here.  One is to specify
> > an absolute path for the entity.  I don't think this is viable since we
> > can't maintain the same absolute path on all systems.  So, I think we have
> > to use symbolic links which are created at install time.  For example, we
> > may have an entity 'docbugsblurb.sgml' in $PREFIX/help/entities and then
> > make a symbolic link from every $PREFIX/<docname>/<languagename>/ to
> > it.  I don't like this a lot, but I don't see any better solutions.  If my
> > memory is correct, this is also how KDE does it.
> > 
> > These entities should be installed by gnome-core or gnome-libs, as with
> > the GFDL and GPL docs.  (I forget which package we decided on.)
> > 
> > Thoughts?
> > 
> > Dan
> > 
> > 
> > On Thu, 5 Oct 2000, Michael McElree - Sun Ireland - Tech Writer wrote:
> > 
> > > Hi All,
> > > 
> > > One suggestion I would like to see 
> > > implemented involves a (minor) change to the Authors section 
> > > of 
> > > online help. 
> > > 
> > > It is very important for Sun (and for other companies 
> > > distributing GNOME in the future) that users are given a link 
> > > to a 
> > > page listing the appropriate support channel. Thus, GNOME on 
> > > Solaris users who need further support or information  on any 
> > > of 
> > > the core software would be given a link to a Sun-specific 
> > > contact 
> > > information page. In this way, each distribution of GNOME 
> > > would 
> > > direct users to the appropriate channel to obtain further 
> > > support. Each distributor of GNOME would only have to insert 
> > > the 
> > > relevant information on one page, rather than trying to change 
> > > the help for every piece of software. 
> > > 
> > > To take the example of the Mini-Commander applet - the Authors 
> > > section would read:
> > > 
> > > Mini-Commander was written by Oliver Maruhn 
> > > (<oliver maruhn com>). Please send all comments and 
> > > suggestions 
> > > via the following channels <link to relevant support details 
> > > page>.
> > > 
> > > This manual was written by Oliver Maruhn (<oliver maruhn com>) 
> > > Minor modifications and updates were made by Dan Mueth 
> > > (<d-mueth chicago edu>). Please send all comments and 
> > > suggestions 
> > > via the following channels <link to relevant support details 
> > > page>.
> > > 
> > > The default link would be to a page containing the text in the 
> > > current form. Sun (and other distributors) would replace this 
> > > page with one listing their own support contact details.
> > > 
> > > Regards
> > > Michael
> > 
> > 
> > _______________________________________________
> > gnome-doc-list mailing list
> > gnome-doc-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-doc-list
> 
> _______________________________________________
> gnome-doc-list mailing list
> gnome-doc-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-doc-list