Re: [Cooker] 9.0 and next

[Warly]

Ben Reser [EMAIL PROTECTED] writes:


[...]


 * improved bugzilla to have a easy mail interaction system, and a more
 friendly interface. And to have a last known problems page.


[...]


 Problems:
 a) Various places have inconsistent reporting instructions and
 requirements.  Some people/sites tell people to post to mandrake expert,
 others to bugzilla or even the cooker mailing list.  There abounds 
 confusion as to where to report and what to include in your report.

Yes, I would like to have only one advertised bug reporting method
for 9.1, bugzilla. However to face too many or not meaningful bug reports,
they will default in UNCONFIRMED states and will need 2, or more if needed
confirmation before becoming new. 

I would like to forward them to cooker and make cooker guy able to answer
to them via mail and confirm them, invalid them and maybe even close them.

 b) The mailing list is not easily searchable for people who aren't
 maintaining their own archives.  Before everyone starts pointing me off
 to the web archives at theaimsgroup hear me out here.  I often have
 difficulty finding messages there that I know were posted.  Frankly the
 search on that site is not all that effective.  But even considering
 that, Mandrake doesn't even link to it anywhere that I know of.  No
 mention of online archives are made on the cookerdevel.php3 page.  You
 can find an archive listing on the Lists page but that only goes to
 Mandrake's archive that isn't searchable.  We criticize posters for
 reposting the same bugs time and time again yet we don't provide them
 easy access to find out if their bug has been reported and even possibly
 fixed.  Thierry even states repeated bug reports are a source of
 irritation for him and I'm sure he isn't alone.

Gael, Ben is right on this point our archives are less usable than the
one at http://marc.theaimsgroup.com/?l=mandrake-cooker. Maybe could we
link to them on the cooker page?

Regarding the search, I fix the quick search on the bugzilla main page, and
it would be nice, as Pixel suggested, to have a ligther complex search page, so
that anyone prefer searching for bugs instead of posting new ones.

[...]

 Strengths:
 a) The list is wonderful at back and forth interactions.
 b) We've developed methods of dealing with large amounts of email and
 work around that. 
 c) Bad reports are easy to get rid of.  You just hit the delete key.
 d) It's a push system rather than pull.  Meaning the reports come to us
 rather than requiring us to go get them.

 Solutions:


[...]

 Now that I've covered the general arguments regarding bugzilla, let's
 cover how it solves the problems...

 (a) Just make it the only place to post.
 (b) bugzilla provides us with good searching.  Duplicates can be closed
 by volunteers and linked to the open bug report, freeing developers to
 pay attention to the real bug reports.  
 (c) KDE reduced bad bug reports
 by asking lots of questions and trying to walk a person through a search
 of the bug database before posting.  Simply requiring users to enter
 relevant package versions, hardware information etc... would decrease
 developer's having to go back and ask for more information constantly.
 Poor bug reports could be moderated, closed, etc by volunteers, leaving
 developers with more time to deal with the issues that filter up to
 them.  Plus, if bugzilla is setup to route bugs only to the maintainer
 of the package, we decrease the number of bad bugs developers have to go
 through.  Bugzilla, however, does still allow for interactive question
 and response via email... Developer posts a response.  The reporter and
 people who are interested in the issue get an email.  Someone replies to
 the email and their response goes back in bugzilla.  Everyone else gets
 a copy of it in their email box.  Basically the same as the mailing
 list, except it's stored in a database and only truly interested parties
 get it (though there could be a list with *ALL* the traffic for
 masochists).  
 (d) This would be solved too.  The list would become a discussion area
 for just developers.  Users wouldn't feel the need to come here much.
 The list would be easier to read and more relevant.  Specifics to
 certain packages would stay on bugzilla.  The few bug reports that
 showed up on the list could be told to report it on bugzilla.  
 (e) Followup is built into the process.  Reporters would get emailed as
 to the status of their bug(s) and all comments or changes made to it.  
 (f) Not an issue.  The list is less important.  Users get instant
 feedback via email showing their bug report id(s) and URL(s) to look at
 their report.  They can see their report in the searches.  
 (g) It's easy to get a report of overall bug count.  Even with bad bug
 reports we'll eventually get an idea of how many bugs we should get down
 to before we think things are looking stable.

Yes, this is sensible. Create a [EMAIL PROTECTED] mailing list, where
bugs are sent and volunteers 

Re: [Cooker] 9.0 and next

[Gael Duval]

Warly wrote:
b) The mailing list is not easily searchable for people who aren't
maintaining their own archives.  Before everyone starts pointing me off
to the web archives at theaimsgroup hear me out here.  I often have
difficulty finding messages there that I know were posted.  Frankly the
search on that site is not all that effective.  But even considering
that, Mandrake doesn't even link to it anywhere that I know of.  No
mention of online archives are made on the cookerdevel.php3 page.  You
can find an archive listing on the Lists page but that only goes to
Mandrake's archive that isn't searchable.  We criticize posters for
reposting the same bugs time and time again yet we don't provide them
easy access to find out if their bug has been reported and even possibly
fixed.  Thierry even states repeated bug reports are a source of
irritation for him and I'm sure he isn't alone.

 
 Gael, Ben is right on this point our archives are less usable than the
 one at http://marc.theaimsgroup.com/?l=mandrake-cooker. Maybe could we
 link to them on the cooker page?
 
 Regarding the search, I fix the quick search on the bugzilla main page, and
 it would be nice, as Pixel suggested, to have a ligther complex search page, so
 that anyone prefer searching for bugs instead of posting new ones.

It would be more coherent to add a search tool to our mailling-lists archives. 
We'll see if we can add one, and if not, we will link to the archives above.

Gaël.

-- 
 Founder Mandrake Linux   
  http://mandrake.com 
 Co-Founder Mandrakesoft  
  http://mandrakesoft.com 

Re: [Cooker] 9.0 and next

[Thierry Vignaud]

Reinout van Schouwen [EMAIL PROTECTED] writes:

 From a translator perspective, I'd like to comment that the
 continuing string changes in the Mandrake tools sometimes are
 driving me up the wall. Up until this weekend there have been string
 changes without the translators even being notified in any way (I
 wonder how many developers know about the cooker-i18n list?). This
 is making the Mandrake experience a less pleasant to non-English
 users because they get confronted with mixed english/own language
 interfaces.

 To make a long story short: next time I would like to see a string
 freeze that can only be broken in special cases and with
 notification of translators in due time. The way the Gnome
 Translation Project works, can be used as a model.

well, the latest 2 weeks were extremely freezed and during the last
week, gc and me posts which strings were changed on cooker-i18n

Re: [Cooker] 9.0 and next

[Reinout van Schouwen]

On Tue, 1 Oct 2002, Thierry Vignaud wrote:

  notification of translators in due time. The way the Gnome
  Translation Project works, can be used as a model.

 well, the latest 2 weeks were extremely freezed and during the last
 week, gc and me posts which strings were changed on cooker-i18n

Well, then there's something wrong with the cooker-i18n distribution
because I haven't received those mails. Now that you mention it I do see
more traffic in the cooker-18n archives than I've actually read. If only
I'd known. :)

-- 

Reinout van SchouwenArtificial Intelligence student
email: [EMAIL PROTECTED] mobile phone: +31-6-44360778
GPG public key http://www.cs.vu.nl/~reinout/reinout.asc

Re: [Cooker] 9.0 and next

[Guillaume Cottenceau]

Ben Reser [EMAIL PROTECTED] writes:

  * improve the cooker cooker FAQ pages, about cooker etiquette and 
  everything when reporting a bug 
  (http://www.mandrakelinux.com/en/cookerfaq.php3)
 
 Agreed 100%.

What percentage of ppl respect the guidelines of the current
version? It's useless to write such things.

-- 
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/

Re: [Cooker] 9.0 and next

[Ben Reser]

On Tue, Oct 01, 2002 at 06:56:05PM +0200, Guillaume Cottenceau wrote:
 What percentage of ppl respect the guidelines of the current
 version? It's useless to write such things.

This is a rather specious argument.  It's like saying.  Why don't we
just not ship or update man pages.  What percentage of users actually
bother to read them?

Nobody can read them and follow them if you don't update and publish
them.  

The current FAQ says that it is published to the list monthly.  I don't
remember the last time that was done.

The current FAQ tells you to CC maintainers.  Yet some Mandrake
employees don't like that.

Most of the FAQ has nothing to do with reporting bugs.  It doesn't even
ask people to report the version of the package they are reporting.  And
to get people to CC the right maintainer you're asking them to download
and install rpmmon.  Putting up a small webscript to get this
information (as I've already done) would make it easier for people.

The harder you make it for people to do it the right way the far less
likely people are to do it the right way.

You are very unlikely to get 100% compliance with anything you put up.
But every person that you do get to do it right will ease your
workload and make for a more relaxed environment on this list.

Doesn't that make it worth the few minutes to fix the FAQ.  Heck Leon 
Brooks actually wrote one that I'm sure you can borrow some of it from.

To improve on the FAQ I'd do the following:

a) Get rid of the information on how to submit packages.  Put a small
mention of it and point people to the RPM howto.  Then make sure the
rpm howto has the correct information on submitting them in it.  Most
users don't submit RPMs so the information is useless to them.

b) Expand the explanation of how to make a good bug report.  Explain how
to find out the version of the package that someone is running.  Explain
not to reply to existing threads to start new ones.  Explain how and
where to search for duplicate bugs.  

c) Actually post it on the list and link to it from everywhere.  Hell
put it in the installer to give newbies something to read why they
install.  

-- 
Ben Reser [EMAIL PROTECTED]
http://ben.reser.org

Never take no as an answer from someone who isn't authorized to say yes.

Re: [Cooker] 9.0 and next

[Guillaume Cottenceau]

Ben Reser [EMAIL PROTECTED] writes:

 On Tue, Oct 01, 2002 at 06:56:05PM +0200, Guillaume Cottenceau wrote:
  What percentage of ppl respect the guidelines of the current
  version? It's useless to write such things.
 
 This is a rather specious argument.  It's like saying.  Why don't we
 just not ship or update man pages.  What percentage of users actually
 bother to read them?

I think, far more than the cooker faq.
 
 Nobody can read them and follow them if you don't update and publish
 them.  

Agreed. But I don't feel it was better at the time I co-wrote it
with Geoff.
 
 The current FAQ says that it is published to the list monthly.  I don't
 remember the last time that was done.

I'm not sure, regarding this issue, but I think it was asked and
maybe admin forgot to do it, or didn't agree, or other ppl didn't
agree. But I don't think it's a key point.
 
 The current FAQ tells you to CC maintainers.  Yet some Mandrake
 employees don't like that.

That's another problem.
 
 Most of the FAQ has nothing to do with reporting bugs.  It doesn't even
 ask people to report the version of the package they are reporting.  And
 to get people to CC the right maintainer you're asking them to download
 and install rpmmon.  Putting up a small webscript to get this
 information (as I've already done) would make it easier for people.

I don't agree. There are some people who don't have a permanent
net connection.
 
 The harder you make it for people to do it the right way the far less
 likely people are to do it the right way.

Agreed.
 
 You are very unlikely to get 100% compliance with anything you put up.
 But every person that you do get to do it right will ease your
 workload and make for a more relaxed environment on this list.

Yep, the problem being when the percentage is very close to 0. I
think that the few persons who are willing to respect the rules
already know them because after all they are just plain logical
rules.
 
 Doesn't that make it worth the few minutes to fix the FAQ.  Heck Leon 
 Brooks actually wrote one that I'm sure you can borrow some of it from.
 
 To improve on the FAQ I'd do the following:
 
 a) Get rid of the information on how to submit packages.  Put a small
 mention of it and point people to the RPM howto.  Then make sure the
 rpm howto has the correct information on submitting them in it.  Most
 users don't submit RPMs so the information is useless to them.
 
 b) Expand the explanation of how to make a good bug report.  Explain how
 to find out the version of the package that someone is running.  Explain
 not to reply to existing threads to start new ones.  Explain how and
 where to search for duplicate bugs.  
 
 c) Actually post it on the list and link to it from everywhere.  Hell
 put it in the installer to give newbies something to read why they
 install.  

I'll study your suggestions if/when I have time (of course, other
mandrake employees are welcome to fix it but I'm unsure they want
to do it).

-- 
Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/

Re: [Cooker] 9.0 and next

[Ben Reser]

On Tue, Oct 01, 2002 at 09:38:23PM +0200, Guillaume Cottenceau wrote:
 I don't agree. There are some people who don't have a permanent
 net connection.

Huh?  What does a permanent net connection have to do with it?  If you
mean people submitting bug reports when not online... those people can
use rpmmon.  But the vast majority of these people are going to be far
to lazy to download and install an application just to find out who the
maintainer is.  rpmmon isn't even included in the distro because you
consider it to be limited usefulness for most people...  It would be a
different story if it was included in cooker and was installed by
default.

Putting the webscript up is not mutually exclusive of rpmmon.

 Yep, the problem being when the percentage is very close to 0. I
 think that the few persons who are willing to respect the rules
 already know them because after all they are just plain logical
 rules.

Well you are far more a pessimist than I am.

-- 
Ben Reser [EMAIL PROTECTED]
http://ben.reser.org

Never take no as an answer from someone who isn't authorized to say yes.

Re: [Cooker] 9.0 and next

[Ben Reser]

On Wed, Sep 25, 2002 at 07:35:24PM +0200, Warly wrote:
 Thanks to you all for your precious help.

And thank you to all of the Mandrake employees for their hard work in
producing 9.0.

 During last 6 months period, and especially in the last beta period, 
 some of you give some advice/critic/flame regarding Mandrakesoft
 development process.

I'll admit I'm one of those advisors, critics and flamers.  Before I go
into what I think will be my analysis of the development process I
want to make it clear this isn't personal.  I really do appreciate the
hard work that the Mandrake crew puts in.

My criticism is aimed at an imperfect process which I think could be
improved.  And the improvements really should help the developers,
Mandrake as a company, contributors and IMHO end product quality.
However, I don't think that there is a perfect process.  Only a possibly
better process. :)

 * send a mail to the changelog disk when packages are removed with
 the reason

This is an excellent suggestion. I couldn't agree more.

 * improve the cooker cooker FAQ pages, about cooker etiquette and 
 everything when reporting a bug 
 (http://www.mandrakelinux.com/en/cookerfaq.php3)

Agreed 100%.

 * improved bugzilla to have a easy mail interaction system, and a more
 friendly interface. And to have a last known problems page.

This demands some flushing out.  While the above issues I think pretty
much everyone will agree with, people seem to be on various sides of
the fence on this and it seems (at least from your comments in the past)
that Mandrake's employees are dead set against this.

So to flush it out in what will likely be a very long response - A
response which I hope will lay out the problems with the current
situation, the strengths with the current situation and perhaps a way to
get the best of both worlds.

I want to start with looking at the status quo before I go into how to
solve the problem (an obvious starting place, but nonetheless lots of
people seem to be spewing solutions without considering the problems).

Problems:
a) Various places have inconsistent reporting instructions and
requirements.  Some people/sites tell people to post to mandrake expert,
others to bugzilla or even the cooker mailing list.  There abounds 
confusion as to where to report and what to include in your report.

b) The mailing list is not easily searchable for people who aren't
maintaining their own archives.  Before everyone starts pointing me off
to the web archives at theaimsgroup hear me out here.  I often have
difficulty finding messages there that I know were posted.  Frankly the
search on that site is not all that effective.  But even considering
that, Mandrake doesn't even link to it anywhere that I know of.  No
mention of online archives are made on the cookerdevel.php3 page.  You
can find an archive listing on the Lists page but that only goes to
Mandrake's archive that isn't searchable.  We criticize posters for
reposting the same bugs time and time again yet we don't provide them
easy access to find out if their bug has been reported and even possibly
fixed.  Thierry even states repeated bug reports are a source of
irritation for him and I'm sure he isn't alone.

c) Bug reports are consistently bad.  This usually means one thing.
That the report didn't contain enough information to do anything about.
Bug reports come in about X11 not working right without listing the
video card.  Users report problems with packages without reporting the
versions they are using.  Users report an error message is displayed
without telling what the error message is.  Random crashes get reported
without any details regarding what was going on at the time.  I would
imagine that a considerable amount of developer time is spent writing
emails requesting further details that probably should have been
included in the original email.

d) The mailing list has too many posts to it.  Some people think the
list has too much unnecessary chatter and discussion of things that
don't matter.  I'm not sure I agree.  But I'm listing it here for
completeness.  However, I can certainly see that reporting a bug by a
newbie seems rather overwhelming when they are told to report it here.
Most of these people do not have time to read the list for replies to
their issues.  Nor do they have sophisticated email filtering that
allows them to pull out what is important.  Nor should they necessarily
have to.

e) There is not enough followup.  Many users, myself included, feel
there is not enough follow up on bug reports.  While I understand a lot
of them are poor, even good reports with fixes get neglected at times.
This is bound to happen when developers receive, as Thierry put it,
thousands of messages a day, especially when many of them are
irrelevant to what they work on.  Some are bound to be lost in the
hustle.  As it stands, the only way to be sure your bug got fixed is to
test again or possibly see it on the changelog list.  However, most
novice reporters 

Re: [Cooker] 9.0 and next

[Guillaume Rousse]

Le Jeudi 26 Septembre 2002 22:04, Todd Lyons a écrit :
 Gary Lawrence Murphy wrote on Thu, Sep 26, 2002 at 01:15:00AM -0400 :
  Maybe we need a Cooker FAQ...

 http://www.mandrakelinux.com/en/cookerfaq.php3
The FAQ from Leon Brooks deserve a link also
http://leon.brooks.fdns.net/Mandrake/bugFAQ.html
-- 
Guillaume Rousse [EMAIL PROTECTED]
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

Re: [Cooker] 9.0 and next

[Guillaume Rousse]

Le Jeudi 26 Septembre 2002 07:23, Vincent Danen a écrit :
 Except that Bugzilla's written in perl and the last time I looked at
 it, was very very messy code.

 Anthill, on the other hand, is written in PHP.
You're forgotting the shameful self-ad tags here, Vincent :-)
-- 
Guillaume Rousse [EMAIL PROTECTED]
GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

Re: [Cooker] 9.0 and next

[Vincent Danen]

On Saturday, September 28, 2002, at 02:48 AM, Guillaume Rousse wrote:

 Except that Bugzilla's written in perl and the last time I looked at
 it, was very very messy code.

 Anthill, on the other hand, is written in PHP.
 You're forgotting the shameful self-ad tags here, Vincent :-)

well, I didn't want anyone to think I was blowing my own horn...  my 
name isn't *that* prominent in Anthill... =)

--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx - source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}




PGP.sig
Description: PGP signature

Re: [Cooker] 9.0 and next

[Frederic Crozat]

Le Thu, 26 Sep 2002 23:04:51 +, Steve Fox a ecrit :

 On Thu, 2002-09-26 at 04:46, Frederic Crozat wrote:
 
 I'm not sure having assigned people per package is really a good idea =
 it will require a lot of people.. But your idea is somehow a variation
 on the same theme as my idea :)
 
 Very true, but then again having just you to manage ALL of GNOME is
 tremendous pressure on you. Would you benefit from having lieutenants to
 assist you with packaging? I think having groups of reliable volunteers to
 assist (and help keep Mandrake's costs low) would be very beneficial. I am
 officially volunteering to help with GNOME packaging if you are receptive
 to this idea.

Well, I already have one unofficial lieutenant for some GNOME packages :
Götz Waschk (thanks Götz) :))

I'll be happy if other people want to help me (or other maintainers), both
for package maintainance or bug triagging/fixing..

I tend to more focus on core GNOME package (ie the desktop platform)
than extra packages (ie applications).. If you (or others) want to help,
that is great..

Maybe we should try to add a pending queue on contrib compilation system
which would send a mail to package maintainer when a package from main
is contributed by cooker folks. Lenny, Warly, WDYT ?

-- 
Frédéric Crozat
MandrakeSoft

Re: [Cooker] 9.0 and next

[Leon Brooks]

On Thu, 26 Sep 2002 03:13, Reinout van Schouwen wrote:
 To make a long story short: next time I would like to see a string freeze
 that can only be broken in special cases and with notification of
 translators in due time. The way the Gnome Translation Project works, can
 be used as a model.

Would a regular (nightly + cumulative weekly?) automated global string diff 
posted to the i18n list help?

Cheers; Leon

Re: [Cooker] 9.0 and next

[Frederic Crozat]

Le Wed, 25 Sep 2002 22:40:36 +, Levi Ramsey a écrit :

 On Wed Sep 25 19:20 -0700, Quel Qun wrote:
 I think the mailing list has reached its limit. It was very frustrating
 to send problem reports and see them vanish in cyberspace because the
 list suddenly collapsed. We complain about incomplete reports, but it
 takes time to write a detailed message, cutting and pasting standard out
 and co. I cannot afford keeping several terminals per problem open for
 hours.
 
 Was it hardware overload that took the lists down?  Or software overload
 at lists with too much traffic?

It was a DNS resolving issue on our mail server, which was affecting 
not only cooker mailing list but all mandrakesoft emails :((
I think it is murphy's law in release team... Usually we had problem
with our compilation cluster.. This time, it was the mailing list :)

 Perhaps it might make sense to segment the cooker list.  Have cooker-kde,
 cooker-gnome, and cooker-apache in addition to a general cooker list. 
 Users who have no interest in running Apache can decide not to subscribe
 to cooker-apache but instead get a daily digest, and so forth.  Fred
 Crozat could then spend most of his time on the cooker-gnome list and
 ignore the KDE list.  Developers who only work on Apache can stick to that
 list.

This is not needed.. I don't read mails which are about KDE or Install
(well, I read them but very quickly).. If only people were using real
topics and split their mails, it would be easier to track :)

-- 
Frédéric Crozat
MandrakeSoft

Re: [Cooker] 9.0 and next: list server

[Leon Brooks]

On Thu, 26 Sep 2002 10:40, Levi Ramsey wrote:
 Perhaps it might make sense to segment the cooker list.  Have
 cooker-kde, cooker-gnome, and cooker-apache in addition
 to a general cooker list.

Don't like that very much. Some problems can strike across boundaries (e.g. X 
bug gets both KDE and Gnome). AFAICT, the existing list manager (yavin and/or 
moseisley.mandrax.org) is just plain wonky and needs taking out and shooting.

 * My own copies of Sympa just don't do that; and

 * I've never had PostFix do anything bizarre or even unexpected
   (contrast that with MS-Exchange), which lets out the software on
   Yavin; and

 * AFAICT no non-list Mandrake mail goes walkies, which lets out
   smtp.mandrakesoft.com unless it's dedicated to Cooker traffic; and

 * this leaves one of:

   * bandwidth; or

   * hardware (I'm inclined to discount this since most messages seem
 to get through eventually); or

   * the software on Moseisley (neither Moseisley nor Smtp admit to
 being PostFix, nor do they generate PostFix-looking message queue
 IDs).

The only other oddity I can see in the headers is that some clocks are 
evidently off by a few minutes (mail arriving at the next hop before it's 
sent, that kind of thing).

Cheers; Leon

Re: [Cooker] 9.0 and next

[Reinout van Schouwen]

Hi Leon,

On Thu, 26 Sep 2002, Leon Brooks wrote:

 Would a regular (nightly + cumulative weekly?) automated global string diff
 posted to the i18n list help?

I don't think string diffs are very relevant; but posting to the list
which packages (are expected to) have string changes and making sure that
each translator is subscribed to that list would help already.

And like I said; observe a complete string freeze a certain period before
final release so that translators have enough time to catch up. Such a
string freeze may only be broken after explicit permission from the
translations coordinator.

my 2 eurocents,

-- 

Reinout van SchouwenArtificial Intelligence student
email: [EMAIL PROTECTED] mobile phone: +31-6-44360778
GPG public key http://www.cs.vu.nl/~reinout/reinout.asc

Re: [Cooker] 9.0 and next

[Thierry Vignaud]

Gary Lawrence Murphy [EMAIL PROTECTED] writes:

 - A 'gripe' button that will compose a message to send
 to cooker-bugs while also capturing essential system
 information (kind of like the old windows dr watson.

drakbug let you post a bug report to bugzilla

Re: [Cooker] 9.0 and next

[Thierry Vignaud]

Gerard Patel [EMAIL PROTECTED] writes:

 I got the impression that some developers were reluctant to use the
 mailing list; for example, I posted a message about net_monitor, got
 invited to post code, did it, got absolutely no answer, reposted in
 case the code had been lost, in vain, gave up, then noticed that the
 code had been indeed added to net_monitor.

you have to understand that we receive lots of mails (i mean several
thousands per day).
we use scorring and the like to reduce the text volume to read but it
still takes time.
so when an adknowledgment (such as ok, thanks, won't do it,
we'll do that after the release, ...) would be fine, we sometimes
don't do it.

i understand this can be frustating but we cannot yet clone ourselves
to work 72h a day :-(

if we get something just right, we just commit it :-)
or we just package it :-) (and then it get reported in changelog ml)
you can see that a confiance evidence in your posts or reliability
proof into our reports

we've an internal ml called install that get spammed with cvs
commits.
maybe should we make publically availlable a cooker-cvs ml.

you must understand that releasing time is very stressing time for us.

on the other hand, we're humans like everybody and we're not perfect.

what's more sometimes we can be in mad mood because of multiples
identical reports or support requests disguised as reports, invalid
bug reports, ...

these 3 items may explain why sometimes people can think we don't care
about them or their reports: this is just because we're not perfect.
this was not planned.

anyway we're sorry if you (the communauty) can get annoyed by feeling
we don't care about you (ie by not get enough feedback from your
feedback, ideas, ...).

we can do better and will try to do better :-)

we'll still try to give you the better we can do :-)

Re: [Cooker] 9.0 and next

[Frederic Crozat]

Le Thu, 26 Sep 2002 00:17:02 +0200, Buchan Milne a écrit :

 On Wed, 25 Sep 2002, Ralph F De Witt wrote:
 
 First of I would like to say that all at Mandarke and volunteers and
 developers did very well with 9.0. It is going to be a great release. I
 am pleased that the beta cycle was a little longer than 8.2. This has
 certainly helped to eleminate most bugs.
 I have no comments as to the building and testing phases. But I have
 comments on the reporting phase. I liked that there were three ways to
 report bugs, but I think that needs to be limited to one way. I really
 got mad when reporting 3 or 4 bugs during the RC3 portion via
 MandrakeExpert when I was told to get a Bugzilla account and report them
 myself, as the expert told me he ws told not to do any more bug reports
 because they were all usless. This really angered me. I agree that there
 are a lot of bad bug reports with a open beta like we do. I have probbly
 done a few my self. But I liked the MandrakeExpert way of doing it
 because I had someone more knowledgeable than me to look at it and say,
 hey how about doing this and this and sending the info. Or send the
 contains of such and such file. This allowed me to turn a bad bug report
 into a useful one, and one that was taken away from me I got very angry.
 I think bug reporting should have only one way to report, and that it
 should be a two step process. One submitte a report, get feed back as to
 other things that are need, when useful, it is submitted. I think that
 some sort of feed back needs to be given to the person reporting the bug
 when it is actioned and completed.
 Any way just my $.02, I hope it helps make the next beta testing go
 round smoother.
 
 I would agree with this sentiment.
 
 In the end, what needs to be accomplished for the next beta cycle is to
 increase the number of bug reports dealt with successfully, while reducing
 the time developers/packages spend doing so.
 
 One aspect is ensuring that all bugs are reported in some way. I have done
 a bit of mining other sites (MandrakeForum and PCLinuxonline) to try and
 get bugs that were compained about there reported (and I think I got at
 least one bug report to cooker).

Thanks for that.. But usually, bugs reported on forums are very bad
quality bug reports or hardware specific bugs.. It means we need direct
contact with the reporter (eitheir with email or bugzilla..)

 Also, accurate summaries of the number of unresolved bugs etc need to be
 available (watch the errata for some bugs that were known but not resolved
 that could have been ...).
 
 Other projects (OO.o, Mozilla, RH) seem to be able to use Bugzilla
 effectively, so I don't think Bugzilla is the problem.

It is not part of the problem, it is part of the solution..

A well maintained bugzilla can be a very useful tool : Let's share my work
with GNOME 2.
During GNOME 2.0 development, one bugmaster (Louie Villa, who is a Ximian
employee but who was paid by Sun for this task) was triaging bugs all day
long (even during night :)) Thanks to Louie, GNOME 2.0 has not slipped too
much and GNOME release team had a way to monitor project status..

We currently have NO bugmaster here at MandrakeSoft (our QA team has
already too much work with hardware testing and other things)... This is
why we didn't open fully our bugzilla like before (we did that with 8.0
IIRC and it was a mess, mainly because of bad quality of bug reports..)

MandrakeExpert bug forwarding was an experiment for 9.0 but I 
(this is a personal opinion) think it has failed somehow, because not
of quality of bug reports and often missing email to ask for details..

I suggested to Warly why we should try plug bugzilla to cooker
mailing-list, ie when a new bug is created on bugzilla, an email is be
send to cooker for review by Cooker community (either triagged as
duplicate, or more info added by other folks having the same problem..).
Replies on this email would be archived on bugzilla. 
This is not a easy thing to do since registration on bugzilla is needed to
be able to add comments on bug but Warly told me he will investigate after
9.0 is out.. 

WDYT of this proposal ?

 The other issues is that there is a substantial amount of free labour
 available, and this should be taken advantage of.
 
 And, there also need to be people who use the software in question daily.
 As an example (not to dis Fred), I don't think Fred Crozat uses Mozilla
 mail, but he is the packager. I do use mozilla-mail daily (and have about
 30 people, increasing daily, using it on windows atm).

Agreed.. One of the strengh of Debian is the high number of packagers :
usually, packager uses their software.. But I package Evolution,
Mozilla and Galeon and I can only use one mailer and one web browser :(( 

 I am quite sure that between the non-Mandrakesoft employees on this list,
 and the MandrakeExperts, that there could be approx 1 volunteer per major
 package.
 
 So, I think it would be feasible (depeding on how easily 

Re: [Cooker] 9.0 and next

[tarvid]

On Wednesday 25 September 2002 01:35 pm, Warly wrote:
 9.0 is (likely to be) finished.

...
 Please comment on what you liked, disliked in the 9.0 building, testing
 and problem reporting process.

The best part of the process was accessibility - I felt I was part of the 
team. When one approach stalled there were always a few others to try. 

I'd like to see a cooker web site run on cooker snapshots. I realize there 
will be sometimes when cooker is so broken that running on the latest cooker 
is impossible but running on frequent snapshots would help set real 
priorities, mainitain focus and set realilstic expectations.

Next I'd like to see explicit priorities. Not so much a management view but a 
developer view of where resources are likely to applied. We would all like to 
have everything but knowing that is impossible, I would settle for a sense of 
direction.

I would also like to see hardware compatibility split from software 
functionality. I can solve hardware compatibility issues at finite cost, some 
software issues can not be solved by any amount of money.

Many projects have test suites. Many users have test applications. Many of us 
have limited coding capability but we could all volunteer to test a few 
packages promptly and carefully. It would be reassuring to know that some 
people could get some functionality out of a package.

Linux is the best game on the planet and Mandrake is the best team.

Thanks,

Jim Tarvid

Re: [Cooker] 9.0 and next

[Thierry Vignaud]

Buchan Milne [EMAIL PROTECTED] writes:

 And, there also need to be people who use the software in question
 daily.  As an example (not to dis Fred), I don't think Fred Crozat
 uses Mozilla mail, but he is the packager. I do use mozilla-mail
 daily (and have about 30 people, increasing daily, using it on
 windows atm).

 I am quite sure that between the non-Mandrakesoft employees on this
 list, and the MandrakeExperts, that there could be approx 1
 volunteer per major package.

 So, I think it would be feasible (depeding on how easily Bugzilla
 can be hacked to do this) to have at least one non-mandrakesoft
 bug-triager per package, who would be able to answer the easy
 questions (fixed in -Xmdk, known bug in original package, fix in
 progress etc), thus removing a lot of the noise from the list.

that's quite an nice idea

Re: [Cooker] 9.0 and next

[Leon Brooks]

On Thu, 26 Sep 2002 17:39, Thierry Vignaud wrote:
 Gerard Patel [EMAIL PROTECTED] writes:
 I got the impression that some developers were reluctant to use the
 mailing list; for example, I posted a message about net_monitor, got
 invited to post code, did it, got absolutely no answer, reposted in
 case the code had been lost, in vain, gave up, then noticed that the
 code had been indeed added to net_monitor.

 you have to understand that we receive lots of mails (i mean several
 thousands per day).
 we use scorring and the like to reduce the text volume to read but it
 still takes time.
 so when an adknowledgment (such as ok, thanks, won't do it,
 we'll do that after the release, ...) would be fine, we sometimes
 don't do it.

Would an adaptation to KMail (or whatever y'all use) to do boilerplate replies 
help? I'm talking about something like a toolbar:

  +-+ +---+ +-+ +---+ +---+ +---+ +---+
  | | |   | | | | After | | Need  | | Fixed | | Wash  |
  | Yes | | Sorry | | No! | | this  | | more  | | in| | mouth |  ...
  | | |   | | | | relse | | input | | curnt | | out   |
  +-+ +---+ +-+ +---+ +---+ +---+ +---+

It wouldn't be too hard to rig KMail for this. That way it takes under a 
second to do a standard response like `Has anyone else seen this?' or `Bug 
referred upstream'.

Cheers; Leon

Re: [Cooker] 9.0 and next

[Alastair Scott]

On Thu, 26 Sep 2002 11:39:36 +0200 Thierry Vignaud
[EMAIL PROTECTED] wrote:

 what's more sometimes we can be in mad mood because of multiples
 identical reports or support requests disguised as reports, invalid
 bug reports, ...
 
 these 3 items may explain why sometimes people can think we don't care
 about them or their reports: this is just because we're not perfect.
 this was not planned.
 
 anyway we're sorry if you (the communauty) can get annoyed by feeling
 we don't care about you (ie by not get enough feedback from your
 feedback, ideas, ...).

Personally, I expected no explicit feedback at all (having come across this
problem many times before - if developers spent much of their time saying
done less would be done) and the best feedback was to see something I'd
reported fixed. There's considerable good faith involved which was duly
repaid; for example, I felt the problems I had with RC3, USB and solid state
devices were obvious enough and had been reported sufficiently clearly, I
knew that things were happening to the kernel and was sure those problems
would be fixed by kernel changes for 9.0 final: they were!

I understand there's a problem with this implicit contract, though, when
people feel they're being ignored. In quite a number of cases the resolution
was from someone not from Mandrakesoft to take the problem on and solve it
on the list, but I'm struggling to come up with a general solution; my
initial suggestion was for an obvious tag (eg REPOST) in an email header
but, if that were done, everyone would use it to try to flag their own
favourite problem and real problems would be drowned out in the shouting.

The problem with bad-quality bug reports is also very difficult to tackle.
Granted, you need people who are expert in the internal workings of Linux,
but you also need people like me who tackle softer issues (eg glitches with
the Gnome UI). Given this diversity there are always going to be
inappropriate reports made; the problem with making bug reporting difficult
is that bugs will be missed. (I would prefer too many reports, with
redundancy and irrelevancy, rather than too few, with incomplete coverage).

Also, as someone who has developed with Unix (Solaris, AIX) extensively in
the past and who is uncovering a brave new world in the handling of
hardware, I believe it would be very useful if the type of output considered
helpful for various types of bug was listed. For example, I wouldn't have
known of lspcidrake -v had I not subscribed to this list.

Alastair

PS The idea that people sign up to looking after certain packages is
excellent.

Re: [Cooker] 9.0 and next

[Leon Brooks]

On Thu, 26 Sep 2002 17:56, Thierry Vignaud wrote:
 Buchan Milne [EMAIL PROTECTED] writes:
 So, I think it would be feasible (depeding on how easily Bugzilla
 can be hacked to do this) to have at least one non-mandrakesoft
 bug-triager per package, who would be able to answer the easy
 questions (fixed in -Xmdk, known bug in original package, fix in
 progress etc), thus removing a lot of the noise from the list.

 that's quite an nice idea

Mandrake Valued Professionals? (-:

Or just Rueben's Angels? As in the `I have hired thee with my son's mandrakes' 
occasion in Genesis chapter 30. (-:

Each package would have two owners, the Mandrake employee and their lay 
adoptee. Would it be feasible to tuck that away in the RPMs somewhere so it 
could be found by Cooker denizens but not widely advertised (e.g. doesn't pop 
out in rpm -qi) for the Mandrake-using public at large?

Cheers; Leon

Re: [Cooker] 9.0 and next

[James]

On Thu, 2002-09-26 at 03:35, Warly wrote:

 Please comment on what you liked, disliked in the 9.0 building, testing 
 and problem reporting process.

I think there were far too many posts to the cooker list about issues
that were user problems. Now, these are important certainly because if
there's too many user problems then the software isn't simple enough.
However, I really think there needs to be a way to separate these from
real issues. I mentioned two ways in a post I made a little while ago.
I'll make them again, but briefer this time.

1. a testing system, kinda like debian. Basically just a cooker mirror
of packages that haven't changed in a week or so and are thus in some
sense stable.

2. a trust metric system for bug reporters.

(1) would allow these people who just became frustrated with cooker to
still make useful contributions about the usability of the system (this
should have a separate mailing list)

(2) would be useful because it would give a fast indication of where the
problems lie (I'm thinking of tying this into drakbug or something), and
automatically filter out noise

Just a thought.

James.

Re: [Cooker] 9.0 and next

[Guy.Bormann]

[snip]
 2. a trust metric system for bug reporters.

 (2) would be useful because it would give a fast indication of where the
 problems lie (I'm thinking of tying this into drakbug or something), and
 automatically filter out noise
How would you handle aging of the trust metric? When there is aging, it
relieves the problem of quality posters turning crappy due to lack of
time, lost interest, ... On the other hand, it punishes quality posters
that irregularly send consistently good reports.

Guy

Re: [Cooker] 9.0 and next

[James]

On Thu, 2002-09-26 at 23:40, Guy.Bormann wrote:
 [snip]
  2. a trust metric system for bug reporters.
 
  (2) would be useful because it would give a fast indication of where the
  problems lie (I'm thinking of tying this into drakbug or something), and
  automatically filter out noise
 How would you handle aging of the trust metric? When there is aging, it
 relieves the problem of quality posters turning crappy due to lack of
 time, lost interest, ... On the other hand, it punishes quality posters
 that irregularly send consistently good reports.

Ahhh, now this is where it would be helpful if I knew a bit more about
AI and statistics. The points you raise are indeed valid.

I don't know that it will be a huge problem. I don't think that
frequency of posting should be considered. I mean, if someone doesn't
have time, they won't post :) - that doesn't mean that their competence
with mandrake somehow decreases over that time.

I think you are talking about a system where there is a theoretically
infinite level of goodness. That's not what I had in mind. Something
more like a number between 0 and 1 - say (good posts) / (total posts)

How do other systems handle this?

James.

Re: [Cooker] 9.0 and next

[Curtis H]

On Thu, 2002-09-26 at 04:17, Leon Brooks wrote:
 On Thu, 26 Sep 2002 17:56, Thierry Vignaud wrote:
  Buchan Milne [EMAIL PROTECTED] writes:
  So, I think it would be feasible (depeding on how easily Bugzilla
  can be hacked to do this) to have at least one non-mandrakesoft
  bug-triager per package, who would be able to answer the easy
  questions (fixed in -Xmdk, known bug in original package, fix in
  progress etc), thus removing a lot of the noise from the list.
 
  that's quite an nice idea
 
 Mandrake Valued Professionals? (-:
 
 Or just Rueben's Angels? As in the `I have hired thee with my son's mandrakes' 
 occasion in Genesis chapter 30. (-:
 
 Each package would have two owners, the Mandrake employee and their lay 
 adoptee. Would it be feasible to tuck that away in the RPMs somewhere so it 
 could be found by Cooker denizens but not widely advertised (e.g. doesn't pop 
 out in rpm -qi) for the Mandrake-using public at large?
 
 Cheers; Leon
 
 
I would think that modifying rpmmon is what your thinking of.  Running
'rpmmon.pl -p package could show the mandrakesoft maintainer and bug
triager

-- 
/curtis  

  Mandrake Linux 9.0 (cooker)
  Kernel Version 2.4.18-22w4l
Uptime 18 days 0 hours 5 minutes

Re: [Cooker] 9.0 and next

[Todd Lyons]

Leon Brooks wrote on Thu, Sep 26, 2002 at 05:55:43PM +0800 :
 
 Would an adaptation to KMail (or whatever y'all use) to do boilerplate
 replies help? I'm talking about something like a toolbar:

Wow, you're suggesting that a developer use something other than emacs
to read mail.  Do you realize that could be considered sacriligious by
some? :)  Not me, but most...

Blue skies...   Todd
-- 
   MandrakeSoft USA   http://www.mandrakesoft.com
Mandrake: An amalgam of good ideas from RedHat, Debian, and MandrakeSoft.
All in all, IMHO, an unbeatable combination.   --Levi Ramsey on Cooker ML
   Cooker Version mandrake-release-9.0-0.3mdk Kernel 2.4.19-16mdk



msg77073/pgp0.pgp
Description: PGP signature

Re: [Cooker] 9.0 and next

[Todd Lyons]

Gary Lawrence Murphy wrote on Thu, Sep 26, 2002 at 01:15:00AM -0400 :
 
 Maybe we need a Cooker FAQ...

http://www.mandrakelinux.com/en/cookerfaq.php3

Blue skies...   Todd
-- 
   MandrakeSoft USA   http://www.mandrakesoft.com
   Easy things should be easy, and hard things should be possible.
--Larry Wall
   Cooker Version mandrake-release-9.0-0.3mdk Kernel 2.4.19-16mdk



msg77075/pgp0.pgp
Description: PGP signature

Re: [Cooker] 9.0 and next

[Brad Felmey]

On Wed, 2002-09-25 at 12:35, Warly wrote:

 During last 6 months period, and especially in the last beta period, some
 of you give some advice/critic/flame regarding Mandrakesoft development
 process.
 
 It is now the right time to debrief all this.

 * improve the cooker cooker FAQ pages, about cooker etiquette and everything
 when reporting a bug (http://www.mandrakelinux.com/en/cookerfaq.php3)

GOD yes, this thing is horrendously out-of-date. 

 * improved bugzilla to have a easy mail interaction system, and a more
 friendly interface. And to have a last known problems page.

Good. Two more:

1) A reliable listserver.

2 a) The volunteer triage idea is excellent. I volunteer!
  b) Acknowledgement, acknowledgement, acknowledgement.
-- 
Brad Felmey

Re: [Cooker] 9.0 and next

[Ben Reser]

On Thu, Sep 26, 2002 at 10:34:31AM -0700, Curtis H wrote:
 I would think that modifying rpmmon is what your thinking of.  Running
 'rpmmon.pl -p package could show the mandrakesoft maintainer and bug
 triager

Wouldn't be too hard.  Would take a change in the maints file format
though...

-- 
Ben Reser [EMAIL PROTECTED]
http://ben.reser.org

Never take no as an answer from someone who isn't authorized to say yes.

Re: [Cooker] 9.0 and next

[Ben Reser]

On Thu, Sep 26, 2002 at 01:07:33PM -0700, Todd Lyons wrote:
 Wow, you're suggesting that a developer use something other than emacs
 to read mail.  Do you realize that could be considered sacriligious by
 some? :)  Not me, but most...

Emacs?  What are you talking about a real email client is mutt. :P

-- 
Ben Reser [EMAIL PROTECTED]
http://ben.reser.org

Never take no as an answer from someone who isn't authorized to say yes.

Re: [Cooker] 9.0 and next: list server

[Ben Reser]

On Thu, Sep 26, 2002 at 04:34:21PM +0800, Leon Brooks wrote:
  * this leaves one of:
 
* bandwidth; or
 
* hardware (I'm inclined to discount this since most messages seem
  to get through eventually); or
 
* the software on Moseisley (neither Moseisley nor Smtp admit to
  being PostFix, nor do they generate PostFix-looking message queue
  IDs).

4th possible option:
* Poor configuration or system administration.

-- 
Ben Reser [EMAIL PROTECTED]
http://ben.reser.org

Never take no as an answer from someone who isn't authorized to say yes.

Re: [Cooker] 9.0 and next

[Gerard Patel]

At 11:39 AM 9/26/02 +0200, you wrote:

you have to understand that we receive lots of mails (i mean several
thousands per day).
we use scorring and the like to reduce the text volume to read but it
still takes time.

First thanks for the answer.

All right, I understand it's a big load... how
about making it lighter ?

I decided to subscribe to cooker after reading on
MandrakeForum that it was a possible way to report
problems. After reading it for a few weeks, I think that
it is a bad idea.

Cooker should be a list for developers only. That is,
it should be possible to report a bug on it *only if 
one has a fix* (a real one, a patch, or a significant
work around, not just saying 'it works in Windows or
with RedHat or Mandrake version N')

Do this a firm and explicit policy for everyone and
cooker will be much easier to read.

Warn infringers, including people responding to
non-developer posts. If it does not work, cast
them out of the mailing list.

An indirect advantage is that newcomers will be much
less frequent, so you could then ask firmly
for well formatted mails (no html, no top-posting,
correct quoting - snipping the irrelevant parts),
giving more readable posts.
Also warn and take action against chatters.
As per the Netiquette, personnal or irrelevant
discussions should be done by private email.
There is way too much noise on this list.

If you have a strict policy on Cooker, bugzilla
*has* to work - non-developers can also have
interesting input. If possible a community
moderation could be useful to cut the time
wasted by Mandrake developers on bugzilla.
With a vote system (Apache like), an
uninteresting bug report could be deleted by
negatives votes from 2 different people, for
example. The moderators would be selected by
Mandrake of course.
If no decision occurs in a specified time,
the bug is automatically escalated to a higher
level to be seen by Mandrake people.
Anyway, Mandrake _has_ to have a _good_ bugmaster,
whose *primary* responsibility is to handle
bugzilla, move problems to cooker when
appropriate, and move workarounds and fixes posted
on cooker to bugzilla bugs.

To sum up the argument :
- Cooker should be the place where contributors
bring _solutions_ to Mandrake.
- Bugzilla should be the place where people
bring _problems_ to Mandrake.

Finally, congrats and take some good time now,
you all deserved it. RC3 works much better
for me than 8.2 (and I was happy with 8.2).
Next time expert mode in drakconnect will work
I'm sure :-)

Gerard

Re: [Cooker] 9.0 and next

[Levi Ramsey]

On Thu Sep 26 15:11 -0700, Ben Reser wrote:
 On Thu, Sep 26, 2002 at 01:07:33PM -0700, Todd Lyons wrote:
  Wow, you're suggesting that a developer use something other than emacs
  to read mail.  Do you realize that could be considered sacriligious by
  some? :)  Not me, but most...
 
 Emacs?  What are you talking about a real email client is mutt. :P

Especially since mutt defaults to using vim as its editor :o)

-- 
Levi Ramsey
[EMAIL PROTECTED]   [EMAIL PROTECTED]

Love lies in pools of questions.

GPG Key Fingerprint: 354C 7A02 77C5 9EE7 8538  4E8D DCD9 B4B0 DC35 67CD
Currently playing:  19990522 - Breadfan.ogg
Linux 2.4.19-9mdk
  7:30pm  up 1 day,  2:34,  6 users,  load average: 0.91, 0.89, 0.64

Re: [Cooker] 9.0 and next

[kim marshall]

Warly wrote:

Please comment on what you liked, disliked in the 9.0 building, testing 
and problem reporting process.
  

This is my first time to participate in the beta cycle so I cannot 
compare this with the past.  But to me things generally seemed to go 
well.  I was impressed at the very quick response time and with the 
generally helpful attitude found here on the Cooker e-mail list.  I 
would agree with the comment that it would be good to get at least an 
automated response to our bug reports and problems from the Mandrake 
team.  In this way we know we have been herd even if what we had to say 
is then being summarily ignored.  Hey there must be priorities and 
everyone knows that deep down.  We cold also be told that this has 
already been addressed or that more information is needed.  

There is one thing that I would like most to to see added.  This is a 
sort of daily or at least weekly progress report.  The old Cooker 
newsletter reborn I guess.  This letter would give those of us 
participating as guinea pigs, ah beta testers, some understanding of our 
role and perhaps even some focus so that we could be even more helpful 
with certain key issues.  And if for some reason a particular problem is 
being ignored for the moment due to Mandrake priorities we could be 
notified and we would not then keep banging our heads against the 
proverbial wall by reporting the same bug over and over again.  For me 
at least, this sort of news would be very helpful.  It would let me know 
what bugs have already been found and fixed, it would tell me how the 
things I am doing fall with in the scheme of things.  It would provide 
me with a place to catch up when I join the effort midstream or when I 
have been out of touch for several days.  In my opinion, it would make 
the overall effort much more organized.  We, all of us, would feel more 
like a team if we were thus informed.

Just my two cents,

Kim  

-- 
---
Registered Linux user #264340
Mandrake Linux 9.0 (Dolphin) - Kernel 2.4.19-16mdk
XFree86 4.2.1 - KDE 3.0.3 and Gnome 2.0

Re: [Cooker] 9.0 and next

[Han Boetes]

Levi Ramsey ([EMAIL PROTECTED]) wrote:
 On Thu Sep 26 15:11 -0700, Ben Reser wrote:
  On Thu, Sep 26, 2002 at 01:07:33PM -0700, Todd Lyons wrote:
 
   Wow, you're suggesting that a developer use something  other  than
   emacs to read mail.  Do  you  realize  that  could  be  considered
   sacriligious by some? :) Not me, but most...
 
  Emacs? What are you talking about a real email client is mutt. :P

 Especially since mutt defaults to using vim as its editor :o)

export EDITOR=emacs

put that in your profile and be amazed. :)



Groetjes, Han.
-- 
http://www.xs4all.nl/~hanb/software

Re: [Cooker] 9.0 and next

[Olivier Thauvin]

Le Jeudi 26 Septembre 2002 20:04, Todd Lyons a écrit :
 Gary Lawrence Murphy wrote on Thu, Sep 26, 2002 at 01:15:00AM -0400 :
  Maybe we need a Cooker FAQ...

 http://www.mandrakelinux.com/en/cookerfaq.php3

 Blue skies... Todd

All email link are broken:
send your email to Lenny - the link is 
http://www.mandrakelinux.com/en/lennyREMOVEatmandrakesoft.com

I notice on lot of page...

Maybe to have on this page the state of cooker:
Something like:

Cooker is open
Last release Dolphin, Sept 2002
Next on Mar 2003

If someone only want purpose a nex package.

Another things, maybe add link to Voluntaries Club, and having a way for lenny 
to ask to contributors if someone is interrest to make/fix/upload a package 
submit by ftp.


-- 
Linux pour Mac !? Enfin le moyen de transformer
une pomme en véritable ordinateur. - JL.
Olivier Thauvin - http://nanardon.homelinux.org/

Re: [Cooker] 9.0 and next

[Steve Fox]

On Thu, 2002-09-26 at 04:46, Frederic Crozat wrote:
 
 I'm not sure having assigned people per package is really a good idea =
 it will require a lot of people.. But your idea is somehow a variation on
 the same theme as my idea :)

Very true, but then again having just you to manage ALL of GNOME is
tremendous pressure on you. Would you benefit from having lieutenants to
assist you with packaging? I think having groups of reliable volunteers
to assist (and help keep Mandrake's costs low) would be very beneficial.
I am officially volunteering to help with GNOME packaging if you are
receptive to this idea.
 
-- 

Steve Fox
http://k-lug.org

[Cooker] 9.0 and next

[Warly]

9.0 is (likely to be) finished.

Thanks to you all for your precious help.

During last 6 months period, and especially in the last beta period, some
of you give some advice/critic/flame regarding Mandrakesoft development
process.

It is now the right time to debrief all this.

Please comment on what you liked, disliked in the 9.0 building, testing 
and problem reporting process.

I already collect on various mandrake IRC channels:

* send a mail to the changelog disk when packages are removed with the reason

* improve the cooker cooker FAQ pages, about cooker etiquette and everything
when reporting a bug (http://www.mandrakelinux.com/en/cookerfaq.php3)

* improved bugzilla to have a easy mail interaction system, and a more
friendly interface. And to have a last known problems page.

-- 
Warly

Re: [Cooker] 9.0 and next

[aacton]

Here's an idea you might like.
A lot of inexperienced users throw some pretty crappy bug reports onto the
cooker list.  We don't have enough info to figure it out, and Mandrake people
probably don't have enough time to answer them all.  If none of us (volunteers)
try to help these people out, they just get ignored.  I see a LOT of I got
ignored or this is the third time I've reported this bug posts.  Maybe you
(Mandrake people) could make up a form-letter type response, and make a policy
that all bugreports get answered, even if the answer is just a form-letter
saying something like:
-we got your report
-we want your report
-we can't figure out what is happening to you
-please read the cooker faq
-please send us a more detailed report (hardware, example case, logs... etc)
That way, newbies to the list won't feel ignored and they can learn.  Then they
can join us.  Then we will be indestructable and we will take over the world...
Austin

Re: [Cooker] 9.0 and next

[Leon Brooks]

On Thu, 26 Sep 2002 01:55, [EMAIL PROTECTED] wrote:
 I see a LOT of I got ignored or this is the third time I've
 reported this bug posts.

Amen! (-:

...and having everyone prefix their second try with REPOST: probably wouldn't 
be helpful, either. (-:

 Maybe you (Mandrake people) could make up a form-letter type
 response, and make a policy that all bugreports get answered, even if the
 answer is just a form-letter saying something like:
 -we got your report
 -we want your report
 -we can't figure out what is happening to you
 -please read the cooker faq
 -please send us a more detailed report (hardware, example case, logs...
 etc)

Very much agree. And nominate someone(s) who must triage and respond.

And an email template and/or simple web form for reporting bugs with would be 
good. `Please attach/upload the following, if available, else send what you 
have', exact version number with directions for discovering it, list of RPMs 
(with versions) you suspect of being involved, with exact versions number, 
instructions for discovering same, etc etc.

 That way, newbies to the list won't feel ignored and they can learn. 
 Then they can join us.  Then we will be indestructable and we will take
 over the world...

As per the original plan. (-:

Cheers; Leon

Re: [Cooker] 9.0 and next

[Alastair Scott]

On Wed, 25 Sep 2002 19:35:24 +0200 Warly [EMAIL PROTECTED] wrote:

 
 9.0 is (likely to be) finished.
 
 Thanks to you all for your precious help.
 
 During last 6 months period, and especially in the last beta period, some
 of you give some advice/critic/flame regarding Mandrakesoft development
 process.
 
 It is now the right time to debrief all this.
 
 Please comment on what you liked, disliked in the 9.0 building, testing 
 and problem reporting process.
 
 I already collect on various mandrake IRC channels:
 
 * send a mail to the changelog disk when packages are removed with the
 reason
 
 * improve the cooker cooker FAQ pages, about cooker etiquette and
 everything when reporting a bug
 (http://www.mandrakelinux.com/en/cookerfaq.php3)
 
 * improved bugzilla to have a easy mail interaction system, and a more
 friendly interface. And to have a last known problems page.

First of all, congratulations to everyone at Mandrakesoft. A phenomenal,
unbelievable effort ... and I feel I and many others made a difference too.
Seeing something you reported being fixed brings you very close to the
software, something you very rarely get with commercial software.

I don't have anything to say on the building and testing process, but
problem reporting is quite the opposite :)

The problem reporting is very difficult to get right. My opinion is that
there should be only one method of communication between beta testers and
developers ... this mailing list, or possibly a dedicated newsgroup. The
developers can cut and paste the valid bugs raised there into their own
_internal_ database and have a read-only view of that made visible to the
outside world (which would solve the 'last known problems' issue); the one
exception to read-only would be the ability for the beta testers to add
comments.  After all:

- the flexibility of a mailing list or newsgroup is unparalleled as posters
can attach files, respond to other posts, be asked for and provide
information, and get feedback on the spot;

- I hate Web-based interfaces (and suspect I'm far from alone) as they're
too slow and awkward: they also tend to be hostile to those with special
needs (as someone with severe osteoarthritis who likes his keyboard I think
I write with some authority ;)

I really think bugzilla should be scrapped, for external use at least. The
process whereby bug reports were pasted by Alan into this mailing list was
dreadfully disjointed; in my estimation 80-90 per cent of those bug reports
were worthless as the reporter was reporting 'cold' (with a mailing list
there is a lot of precedent, in the form of previous postings, on how and
what to post and what the current issues are) and, if there was any feedback
from list members, it was difficult to get it back to the original bugzilla
contributor. 

Doubtless doing all this will have, as a response, a howl that beta testers
will be bombarded with emails. Such is life; I would prefer a small group of
committed people who can cope with such things and keep going from beginning
to end rather than 'occasional testers'.

Alastair

Re: [Cooker] 9.0 and next

[rcc]

On Wed, 25 Sep 2002 13:55:06 -0400
[EMAIL PROTECTED] wrote:

 I see a LOT of I got ignored or this is the third time
 I've reported this bug posts.  Maybe you(Mandrake people) could make
 up a form-letter type response, and make a policy that all bugreports
 get answered, even if the answer is just a form-letter saying
 something like:-we got your report
 -we want your report
 -we can't figure out what is happening to you
 -please read the cooker faq
 -please send us a more detailed report (hardware, example case,
 logs... etc) That way, newbies to the list won't feel ignored and they
 can learn.  Then they can join us.  Then we will be indestructable and
 we will take over the world... Austin

good idea, but how to tell bugreports apart from other things

like Guido posted a problem with gcc3.2 and didn't get much attention.
He was mighty pissed about the problem (not the attention ;) and will
probably exclude at least mdk's gcc from his list of valid compilers for
his projects. He's not bashing mandrake as he still doesn't know where
the fault originated but a mail along we'll look into that, need more
info, etc would certainly have eased his mind.

Anyway, cooker drowns in support questions and useless policy
discussions like for proprietary drivers. Though, admittedly, one cannot
be sure whether a prob qualifies as bug or support-problem, see my
problem with Mach64 cards.

my personal experience with the few small probs I've found was
excellent, everything was fixed pretty fast. 

- Mark

 

Re: [Cooker] 9.0 and next

[Reinout van Schouwen]

Hi Alastair,

On Wed, 25 Sep 2002, Alastair Scott wrote:

 Seeing something you reported being fixed brings you very close to the
 software, something you very rarely get with commercial software.

That is true; however I have my doubts with the decision to let the deep
freeze prevale above fixing a bug which causes a complete system freeze;
which involves nothing more than using a different sound driver.
(https://qa.mandrakesoft.com/show_bug.cgi?id=236)

 I really think bugzilla should be scrapped, for external use at least. The

There's already a system in place where not everyone may submit reports in
bugzilla.

regards,

-- 

Reinout van SchouwenArtificial Intelligence student
email: [EMAIL PROTECTED] mobile phone: +31-6-44360778
GPG public key http://www.cs.vu.nl/~reinout/reinout.asc

Re: [Cooker] 9.0 and next

[Alan Hughes]

I think one positive point is that the Beta/RC cycle was much longer this
time round, giving people a lot more time to find problems and report them.
With 8.2 the Beta/RC cycle was very quick, so a lot of problems made it
through to the final release that franckly should not have been there.
Hopefully the greater care that was taken this time around should be
reflected in a better quality release - watch this space for further
comments.

I've already seem some of the responses, can I add my voice to those saying
that having multiple error reporting routes is not helpful. Personally I
think the Cooker list is the best place for this sort of thing, particularly
since many of the people who post here will also continue to play a role
in-between releases. Continuity and continuous testing is the theme I'm
trying to get at here.

Another issue is feedback. If someone has gone to the trouble of reporting a
bug then a simple acknowledgement can go a long way to keeping them
motivated. In addition acknowledging help in the change logs would also be a
good thing - I noticed Pixel doing this, but I can't remember anyone else
doing so.

Whether BugZilla should continue to be used I don't know - used properly it
could be a powerful problem reporting and monitoring tool, but I don't think
its been used properly by anyone (and that goes for the user community as
well as Mandrake people). What is needed is discipline - the user community
needs to be more careful reporting bugs, and Mandrake needs to use BugZilla
to provide feedback w.r.t. problem status and solution. Can we get that sort
of discipline? I don't know.

Finally can I say that the impressions I've had of 9.0 indicate that
Mandrake has done a tremendous job. As a software professional I am more
than aware of the problems you can get on handling a project of that scale,
the fact that you have achieved so much speaks very highly of everyone
concerned. Early this year I was actually thinking of switching to another
distro (due to the problems with 8.2), but you have gone a long way to
renewing my confidence in Mandrake.

Well done, now get some rest (and a large drink).

Alan

- Original Message -
From: Warly [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 25, 2002 6:35 PM
Subject: [Cooker] 9.0 and next



 9.0 is (likely to be) finished.

 Thanks to you all for your precious help.

 During last 6 months period, and especially in the last beta period, some
 of you give some advice/critic/flame regarding Mandrakesoft development
 process.

 It is now the right time to debrief all this.

 Please comment on what you liked, disliked in the 9.0 building, testing
 and problem reporting process.

 I already collect on various mandrake IRC channels:

 * send a mail to the changelog disk when packages are removed with the
reason

 * improve the cooker cooker FAQ pages, about cooker etiquette and
everything
 when reporting a bug (http://www.mandrakelinux.com/en/cookerfaq.php3)

 * improved bugzilla to have a easy mail interaction system, and a more
 friendly interface. And to have a last known problems page.

 --
 Warly

Re: [Cooker] 9.0 and next

[Reinout van Schouwen]

Hi Warly,

On Wed, 25 Sep 2002, Warly wrote:

 Please comment on what you liked, disliked in the 9.0 building, testing
 and problem reporting process.

From a translator perspective, I'd like to comment that the continuing
string changes in the Mandrake tools sometimes are driving me up the
wall. Up until this weekend there have been string changes without the
translators even being notified in any way (I wonder how many developers
know about the cooker-i18n list?). This is making the Mandrake
experience a less pleasant to non-English users because they get
confronted with mixed english/own language interfaces.

To make a long story short: next time I would like to see a string freeze
that can only be broken in special cases and with notification of
translators in due time. The way the Gnome Translation Project works, can
be used as a model.

regards,

-- 

Reinout van SchouwenArtificial Intelligence student
email: [EMAIL PROTECTED] mobile phone: +31-6-44360778
GPG public key http://www.cs.vu.nl/~reinout/reinout.asc

Re: [Cooker] 9.0 and next

[Michael Reinsch]

Hi!

On Wed, 25 Sep 2002 19:39:34 +0100
Alan Hughes [EMAIL PROTECTED] wrote:

 Whether BugZilla should continue to be used I don't know - used
 properly it could be a powerful problem reporting and monitoring tool,
 but I don't think its been used properly by anyone (and that goes for
 the user community as well as Mandrake people). What is needed is
 discipline - the user community needs to be more careful reporting
 bugs, and Mandrake needs to use BugZilla to provide feedback w.r.t.
 problem status and solution. Can we get that sort of discipline? I
 don't know.

Well, I guess it would be used instead of the cooker mailing list if it
would have advantages for the reporters. 

The one big disadvantage of a mailing list: You don't see all reports
for a package. So you have to search (not always easy) or remember the
one mail for the problem you currently have found.

This can by already done with bugzilla, but it currenlty takes much to
many steps to get to that point and even more the then create a new
problem report - so searching the mailing list is currently easier.

If bugzilla would be enhanced in a way that you only have to paste the
package name (+version) in it and then see all open problem reports and
could create a new problem report for it with one more click, it would
be probably used...

-- 
  Michael Reinsch [EMAIL PROTECTED]   http://mr.uue.org

Re: [Cooker] 9.0 and next

[J. Greenlees]

why not, as Alan suggests, only one route for reporting bugs, use 
bugzilla or something similiar and this list used more for communication 
between steady testers. with a public report from the bugzilla system 
being made available for those on this list?
but not solely a public bugzilla, one for registered cooker members, 
reguardless of thier participation on this list.
that way all bugs are reported on, and in, the same forum, with the list 
acting as a tool to facilitate communication between the testers when 
needed.
the reasons for using a bug reporting system are simple, a specified 
format for the bug report, and with verification, avoiding duplication 
of bugs being reported / worked on through this list.

newsgroups, while they work, are even more open than the list, allowing 
more not very usefull postings than happen here.


Alan Hughes wrote:

I think one positive point is that the Beta/RC cycle was much longer this
time round, giving people a lot more time to find problems and report them.
With 8.2 the Beta/RC cycle was very quick, so a lot of problems made it
through to the final release that franckly should not have been there.
Hopefully the greater care that was taken this time around should be
reflected in a better quality release - watch this space for further
comments.

I've already seem some of the responses, can I add my voice to those saying
that having multiple error reporting routes is not helpful. Personally I
think the Cooker list is the best place for this sort of thing, particularly
since many of the people who post here will also continue to play a role
in-between releases. Continuity and continuous testing is the theme I'm
trying to get at here.

Another issue is feedback. If someone has gone to the trouble of reporting a
bug then a simple acknowledgement can go a long way to keeping them
motivated. In addition acknowledging help in the change logs would also be a
good thing - I noticed Pixel doing this, but I can't remember anyone else
doing so.

Whether BugZilla should continue to be used I don't know - used properly it
could be a powerful problem reporting and monitoring tool, but I don't think
its been used properly by anyone (and that goes for the user community as
well as Mandrake people). What is needed is discipline - the user community
needs to be more careful reporting bugs, and Mandrake needs to use BugZilla
to provide feedback w.r.t. problem status and solution. Can we get that sort
of discipline? I don't know.

Finally can I say that the impressions I've had of 9.0 indicate that
Mandrake has done a tremendous job. As a software professional I am more
than aware of the problems you can get on handling a project of that scale,
the fact that you have achieved so much speaks very highly of everyone
concerned. Early this year I was actually thinking of switching to another
distro (due to the problems with 8.2), but you have gone a long way to
renewing my confidence in Mandrake.

Well done, now get some rest (and a large drink).

Alan

- Original Message -
From: Warly [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, September 25, 2002 6:35 PM
Subject: [Cooker] 9.0 and next


9.0 is (likely to be) finished.

Thanks to you all for your precious help.

During last 6 months period, and especially in the last beta period, some
of you give some advice/critic/flame regarding Mandrakesoft development
process.

It is now the right time to debrief all this.

Please comment on what you liked, disliked in the 9.0 building, testing
and problem reporting process.

I already collect on various mandrake IRC channels:

* send a mail to the changelog disk when packages are removed with the

reason

* improve the cooker cooker FAQ pages, about cooker etiquette and

everything

when reporting a bug (http://www.mandrakelinux.com/en/cookerfaq.php3)

* improved bugzilla to have a easy mail interaction system, and a more
friendly interface. And to have a last known problems page.

--
Warly

Re: [Cooker] 9.0 and next

[David Walser]

Sounds like something more useful for Shoemaker to do.

--- [EMAIL PROTECTED] wrote:
 Here's an idea you might like.
 A lot of inexperienced users throw some pretty
 crappy bug reports onto the
 cooker list.  We don't have enough info to figure it
 out, and Mandrake people
 probably don't have enough time to answer them all. 
 If none of us (volunteers)
 try to help these people out, they just get ignored.
  I see a LOT of I got
 ignored or this is the third time I've reported
 this bug posts.  Maybe you
 (Mandrake people) could make up a form-letter type
 response, and make a policy
 that all bugreports get answered, even if the answer
 is just a form-letter
 saying something like:
 -we got your report
 -we want your report
 -we can't figure out what is happening to you
 -please read the cooker faq
 -please send us a more detailed report (hardware,
 example case, logs... etc)
 That way, newbies to the list won't feel ignored and
 they can learn.  Then they
 can join us.  Then we will be indestructable and we
 will take over the world...
 Austin
 

__
Do you Yahoo!?
New DSL Internet Access from SBC  Yahoo!
http://sbc.yahoo.com

Re: [Cooker] 9.0 and next

[Gerard Patel]

At 07:35 PM 9/25/02 +0200, you wrote:

snip

Please comment on what you liked, disliked in the 9.0 building, testing 
and problem reporting process.

I have followed cooker since beta3 and I have been badly
surprised by the lack of reliability of the mailing list.
Maybe replace it by a private news server as suggested
by another poster would be a good idea.

I got the impression that some developers were reluctant
to use the mailing list; for example, I posted a message
about net_monitor, got invited to post code, did it,
got absolutely no answer, reposted in case the code had 
been lost, in vain, gave up, then noticed that the code had
been indeed added to net_monitor.

No discussion, no question, no one but myself and (I hope)
the Mandrake developer had the occasion to test my code.
Very strange. Bad communication is usual in open source
but I have never seen something like that until cooker.

Gerard

Re: [Cooker] 9.0 and next

[Robert Fox]

On Wed, 2002-09-25 at 19:55, [EMAIL PROTECTED] wrote:
 Here's an idea you might like.
 A lot of inexperienced users throw some pretty crappy bug reports onto the
 cooker list.  We don't have enough info to figure it out, and Mandrake people
 probably don't have enough time to answer them all.  If none of us (volunteers)
 try to help these people out, they just get ignored.  I see a LOT of I got
 ignored or this is the third time I've reported this bug posts.  Maybe you
 (Mandrake people) could make up a form-letter type response, and make a policy
 that all bugreports get answered, even if the answer is just a form-letter
 saying something like:
 -we got your report
 -we want your report
 -we can't figure out what is happening to you
 -please read the cooker faq
 -please send us a more detailed report (hardware, example case, logs... etc)
 That way, newbies to the list won't feel ignored and they can learn.  Then they
 can join us.  Then we will be indestructable and we will take over the world...
 Austin
 

First of all - Kudos and congratulations to the hard working Mandrake
staff - the 9.0 release is truly a milestone!  

I agree wholeheartedly with the above post.  As a frequent contributer
to this list, I found myself at times getting frustrated because of lack
of feedback on some of my posts.  I never took it personally, but it
would have been nice to at least acknowledge the receipt of the
information.  The suggestions above are enough to keep frequent
contributers and newcomers coming back for more . . .

Sometimes I questioned the value of posting a problem or bug because
it felt like it was falling on deaf ears . . .  I think every post
should at least be acknowledged (even if it's an automated response).
Even better when the problem is quickly resolved!

Keep up the fantastic work, and many thanks for an exceptional product!

R.Fox

Re: [Cooker] 9.0 and next

[Ralph F De Witt]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wednesday 25 September 2002 12:13 pm, Reinout van Schouwen wrote:
 Hi Warly,

 On Wed, 25 Sep 2002, Warly wrote:
  Please comment on what you liked, disliked in the 9.0 building, testing
  and problem reporting process.

 From a translator perspective, I'd like to comment that the continuing
 string changes in the Mandrake tools sometimes are driving me up the
 wall. Up until this weekend there have been string changes without the
 translators even being notified in any way (I wonder how many developers
 know about the cooker-i18n list?). This is making the Mandrake
 experience a less pleasant to non-English users because they get
 confronted with mixed english/own language interfaces.

 To make a long story short: next time I would like to see a string freeze
 that can only be broken in special cases and with notification of
 translators in due time. The way the Gnome Translation Project works, can
 be used as a model.

 regards,
Hi all:
First of I would like to say that all at Mandarke and volunteers and 
developers did very well with 9.0. It is going to be a great release. I am 
pleased that the beta cycle was a little longer than 8.2. This has certainly 
helped to eleminate most bugs.
I have no comments as to the building and testing phases.
But I have comments on the reporting phase. I liked that there were three ways 
to report bugs, but I think that needs to be limited to one way. I really got 
mad when reporting 3 or 4 bugs during the RC3 portion via MandrakeExpert when 
I was told to get a Bugzilla account and report them myself, as the expert 
told me he ws told not to do any more bug reports because they were all 
usless. This really angered me. I agree that there are a lot of bad bug 
reports with a open beta like we do. I have probbly done a few my self. But I 
liked the MandrakeExpert way of doing it because I had someone more 
knowledgeable than me to look at it and say, hey how about doing this and 
this and sending the info. Or send the contains of such and such file. This 
allowed me to turn a bad bug report into a useful one, and one that was taken 
away from me I got very angry.
I think bug reporting should have only one way to report, and that it should 
be a two step process. One submitte a report, get feed back as to other 
things that are need, when useful, it is submitted. I think that some sort of 
feed back needs to be given to the person reporting the bug when it is 
actioned and completed.
Any way just my $.02, I hope it helps make the next beta testing go round 
smoother.
- -- 
Yours,
Ralph.
It said Use Windows XP or better, so I installed MandrakeLinux 8.2 
Register Linux User 168814 ICQ #49993234 AIM ralphdewitt jabber.org 
ralphdewitt
GPG Public Key available at http://www.keyserver.net
Key fingerprint = 6426 1CFF 0987 9D51 76D6  06BC F22A CFF4 559A 03E7
Kernel version 2.4.18-6mdk
Current Linux uptime: 2:45, days user hours  minutes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9kiBi8irP9FWaA+cRAqf6AJ4w/j5hEsLN3HguwK1DH2nWac+WvwCgrcDY
i7Cuqr3WZIuuKuTr1AThB5A=
=LX8b
-END PGP SIGNATURE-

Re: [Cooker] 9.0 and next

[Tom Brinkman]

On Wednesday September 25 2002 12:35 PM, Warly wrote:
 9.0 is (likely to be) finished.

 Thanks to you all for your precious help.

 During last 6 months period, and especially in the last beta period,
 some of you give some advice/critic/flame regarding Mandrakesoft
 development process.

 It is now the right time to debrief all this.

 Please comment on what you liked, disliked in the 9.0 building,
 testing and problem reporting process.

 I've been runnin 8.3/9.0 since June (previous cooker before that), 
the only 9.0 bug I reported was fixed before my post showed up ;) 
Mostly I'm a lurker.

 I already collect on various mandrake IRC channels:

   http://www.mandrakeforum.org/article.php?sid=2284lang=en
If you want help, use MandrakeExpert or the mailing lists or the 
alt.os.linux.mandrake newsgroup, the various #mandrake IRC channels 
etc.

Actually there's even cooker bug reports posted to various other 
linux newsgroups. Y'all might note that 'mailing lists' in the above 
quote is a link to all the Mdk lists, newbie, expert, cooker, etc. I 
don't think this should change, nor do I believe it ever will. Most 
users are more intimidated by the cooker list than tryin to run cooker. 
Many don't want to subscribe or even be bothered to check the cooker ML 
archive. Most are discouraged if they don't get acknowledged.

Still they don't have any hesitation to discuss cooker problems or 
bugs on the other lists or newsgroups. There they do often get 
acknowledged, even helped. So, seems to me, those of us that do run and 
subscribe to the cooker list, and other lists, could help a lot by 
coaxing these reports from 'other sources' into a usable form and 
report them to the cooker list ourselves. It would entail an effort by 
some cooker volunteers (my hand is up).

OTOH, a policy of discouraging bug reports to this list only, other 
sources as inappropriate, not only would mostly fall on deaf ears, but 
also foster the 'useless' or obsolete (ie, already fixed in current 
cooker) reports many of y'all have been complaining about. (Maybe those 
persons should volunteer also ;)

-- 
Tom Brinkman  Corpus Christi, Texas

Re: [Cooker] 9.0 and next

[Richard Tango-Lowy]

I enjoyed the beta process -- it works amazingly well. The first
improvement I can think of is better integration between the bug tracker
and the cooker list. It would be nice if bugzilla reports relevant to
the betas where automatically forwarded to the list or such.

Rich

On Wed, 2002-09-25 at 13:35, Warly wrote:

Please comment on what you liked, disliked in the 9.0 building, testing 
and problem reporting process.

-- 
ars Cognita   Richard Tango-Lowy
  -
  President
  [EMAIL PROTECTED]
  603 424-0713



signature.asc
Description: This is a digitally signed message part

Re: [Cooker] 9.0 and next

[Buchan Milne]

On Wed, 25 Sep 2002, Ralph F De Witt wrote:

 First of I would like to say that all at Mandarke and volunteers and
 developers did very well with 9.0. It is going to be a great release. I am
 pleased that the beta cycle was a little longer than 8.2. This has certainly
 helped to eleminate most bugs.
 I have no comments as to the building and testing phases.
 But I have comments on the reporting phase. I liked that there were three ways
 to report bugs, but I think that needs to be limited to one way. I really got
 mad when reporting 3 or 4 bugs during the RC3 portion via MandrakeExpert when
 I was told to get a Bugzilla account and report them myself, as the expert
 told me he ws told not to do any more bug reports because they were all
 usless. This really angered me. I agree that there are a lot of bad bug
 reports with a open beta like we do. I have probbly done a few my self. But I
 liked the MandrakeExpert way of doing it because I had someone more
 knowledgeable than me to look at it and say, hey how about doing this and
 this and sending the info. Or send the contains of such and such file. This
 allowed me to turn a bad bug report into a useful one, and one that was taken
 away from me I got very angry.
 I think bug reporting should have only one way to report, and that it should
 be a two step process. One submitte a report, get feed back as to other
 things that are need, when useful, it is submitted. I think that some sort of
 feed back needs to be given to the person reporting the bug when it is
 actioned and completed.
 Any way just my $.02, I hope it helps make the next beta testing go round
 smoother.

I would agree with this sentiment.

In the end, what needs to be accomplished for the next beta cycle is to
increase the number of bug reports dealt with successfully, while reducing
the time developers/packages spend doing so.

One aspect is ensuring that all bugs are reported in some way. I have done
a bit of mining other sites (MandrakeForum and PCLinuxonline) to try and
get bugs that were compained about there reported (and I think I got at
least one bug report to cooker).

Also, accurate summaries of the number of unresolved bugs etc need to be
available (watch the errata for some bugs that were known but not resolved
that could have been ...).

Other projects (OO.o, Mozilla, RH) seem to be able to use Bugzilla
effectively, so I don't think Bugzilla is the problem.

The other issues is that there is a substantial amount of free labour
available, and this should be taken advantage of.

And, there also need to be people who use the software in question daily.
As an example (not to dis Fred), I don't think Fred Crozat uses Mozilla
mail, but he is the packager. I do use mozilla-mail daily (and have about
30 people, increasing daily, using it on windows atm).

I am quite sure that between the non-Mandrakesoft employees on this list,
and the MandrakeExperts, that there could be approx 1 volunteer per major
package.

So, I think it would be feasible (depeding on how easily Bugzilla can be
hacked to do this) to have at least one non-mandrakesoft bug-triager per
package, who would be able to answer the easy questions (fixed in -Xmdk,
known bug in original package, fix in progress etc), thus removing a lot
of the noise from the list.

Since some of these volunteers may be experts at Mandrakeexpert, it may
be convenient to be able to turn a bugzilla bug report into a support
question. Similarly, a support question may need to be turned into a bug
report.

Then, all confirmed bug reports would go to the cooker list (since this is
probably one of the quickest ways of dealing with real bugs).
Unfortunately, that means people will have to make 'value judgements'.

Now, we have a problem of who may thus write to Bugzilla, since we don't
want to overrun the volunteers either.

I would propose that users be given a rating, based on the quality of
their bug reports, and the number of bug reports they could post would be
dependant on that rating. Thus, if they have a number of bugs they want to
report, they would have to ensure that the first bug reports are of high
enough quality to warrant them posting more bugs. Customers (boxed set
buyers or MandrakeClub members) may be given more bug reports for the same
rating (50% more?), since this would give (for example) a corporate Club
member significant influence on bugfixing to make membership more
worthwhile.

Then, we need to make sure that we have sufficiently motivated volunteers.
Mandrakeexpert seems(ed?) to work well (although I haven't really
'experted' there for 6 months or more), but maybe volunteers would get
twice the score for a resolved bug (based on the reporters rating and the
developers rating maybe) at Mandrakeexpert (since resolved bugs in a
beta/RC cycle must be worth more than explaining how to fix that same bug
later).

Since by now we have almost integrated Mandrakeexpert and bugzilla and
MandrakeClub, I also see no reason why all the 

Re: [Cooker] 9.0 and next

[Gary Lawrence Murphy]

I second the idea to acknowledge bug reports posted to the cooker list,
or how about this:  We open a new public-postable mailing list called
cooker-bugs where you get an acknowledgement of the submission, but
you're told not to expect a response; this lets us keep a record of
every novice contribution that may become valuable when we later 
discover more information through other sources -- sometimes the
addition info submitted by a novice can shed critical light.

If I were in the development/QA crew, I wouldn't want the bug tracker
filled up with bad reports, I'd want to control what gets tracked
by assigning someone to sift cooker-bugs for repeated reports that
can perhaps be put together into a proper bug report worth tracking.
Then, like Mozilla, we put the names of the original submitters on
the ticket so they are informed of the progress on their bug.

it's extra work, but I think it would pay off in the long run.

Further to this, it would be nice if the cooker had two new
cooker-only utilities:

- A 'gripe' button that will compose a message
  to send to cooker-bugs while also capturing
  essential system information (kind of like the
  old windows dr watson.

- A MandrakeUpdate-like ability to incrementally
  or selectively upgrade a cooker installation
  so you can first ensure you are using the very
  latest software before you submit the bug.

More or less I'd like to open up Cooker QA testing to include more
people; the size and complexity of the Mandrake distro is
ever-increasing and it's becoming difficult for the core workers to
test every possible combination.  It's /nice/ to get bug reports from
experienced developers, but sometimes by knowing too much, I think
developers can forgive a bug that was too easy to fix only because
they were actively monitoring the lists, irc and all, or just because
they have a lot of mandrake experience.  More novice users, but those
still willing to take a chance on the cooker, could be useful, but
I think they might get a little discouraged if the process is too
complex (like the Universe, it should be simple, but not too simple ;)

-- 
Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications
 - blog: http://www.auracom.com/~teledyn - biz: http://teledyn.com/ -
  Computers are useless. They can only give you answers. (Picasso)

Re: [Cooker] 9.0 and next

[marcos colome]

I have run several beta testing during this present years including Microsoft.net, but
Manadrake has improved a lot in only four or 5 years, I remembered the first Mandrake that I purchased that really gave a hard time to install and configure but
Mandrake 9.0 is very good even so that It is not final version and it is incomplete
without the commercial packages, I do not know If Mandrake will be using Star Office 6.0, but I have not seen the great improvement from 5.2 to 6.0, I prefer to
use KDE office, it run much better than 6.0, maybe I am mistaken but that is my
impression using Mandrake 8.2 and Suse 8.0, even so Suse is not using SO 6.0
on its 8.1 version. The Mandrake 9.0 has very nice color, and it is very friendly to
be used, I had some difficulties with the new video cards, and it did not want to install on the new AMD chipset for dual processors, I had to install it on a single
processor motherboard, many home users are building dual processor computers
as file servers, and many home offices are using servers and powerfull workstations
even gamers are using dual processors motherboards, when I installed the printers
I had a couple of errors but it was able to fix them, besides all that the 9.0 is a very
good operating systems, let see what will happen , because many good Linux are
coming out on October thru December, even better than Microsoft.net that I have
tested both the Standard and the Enterprise. The connection for updating was improved on this version, because I had many difficulties with 8.2. I would like to
congratulate Mandrake developers for the job that they have done and I think that in
the future we will see Linux dominating the desktop market because it is getting bigger and bigger everyday

Tom Brinkman <[EMAIL PROTECTED]>wrote:
On Wednesday September 25 2002 12:35 PM, Warly wrote: 9.0 is (likely to be) finished. Thanks to you all for your precious help. During last 6 months period, and especially in the last beta period, some of you give some advice/critic/flame regarding Mandrakesoft development process. It is now the right time to debrief all this. Please comment on what you liked, disliked in the 9.0 building, testing and problem reporting process.I've been runnin 8.3/9.0 since June (previous cooker before that), the only 9.0 bug I reported was fixed before my post showed up ;) Mostly I'm a lurker. I already collect on various mandrake IRC channels:http://www.mandrakeforum.org/article.php?sid=2284lang=en"If you want help, use MandrakeExpert or the mailing lists or the alt.os.linux.mandrake newsgroup, the various #mandrake IRC channels etc."Actually there's even cooker bug reports posted to various other linux newsgroups. Y'all might note that 'mailing lists' in the above quote is a link to all the Mdk lists, newbie, expert, cooker, etc. I don't think this should change, nor do I believe it ever will. Most users are more intimidated by the cooker list than tryin to run cooker. Many don't want to subscribe or even be bothered to check the cooker ML archive. Most are discouraged if they don't get acknowledged.Still they don't have any hesitation to discuss cooker problems or bugs on the other lists or newsgroups. There they do often get acknowledged, even helped. So, seems to me, those of us that do run and subscribe to the cooker list, and other lists, could help a lot by coaxing these reports from 'other sources' into a usable form and report them to the cooker list ourselve!
s. It would entail an effort by some cooker volunteers (my hand is up).OTOH, a policy of discouraging bug reports to this list only, other sources as inappropriate, not only would mostly fall on deaf ears, but also foster the 'useless' or obsolete (ie, already fixed in current cooker) reports many of y'all have been complaining about. (Maybe those persons should volunteer also ;)-- Tom Brinkman Corpus Christi, TexasDo you Yahoo!?
New DSL Internet Access from SBC & Yahoo!

Re: [Cooker] 9.0 and next

[allen]

On Wednesday 25 September 2002 12:35 pm, Warly wrote:
 Please comment on what you liked, disliked in the 9.0 building, testing
 and problem reporting process.

1.  I feel like I contributed at least a little bit, that's good.

2.  I feel like mysterious people in a basement somewhere did all the work
and I never got to know what they were about to do before they did it.

Not fun, no meatware interactivity in this category.

Therefore, the whole thing feels like it was shoot from the hip
meanwhile what happened to all the strategery points behind 
all that was actually done ?

3.  I somehow feel like little or no effort was made to explain choices
that were made in foundational elements like particular kernel version,
c, c++ compiler, libc, glibc, etc., and also what the known consequences
are... and therefore the strategies are...  and all packages must conform
to x.y.z standards...

Feels like shoot from the hip... to completion whether or not that's
the deal, that's what it feels like.


This kind of feedback ?

THX
-AEF

Re: [Cooker] 9.0 and next

[J. Greenlees]

If bugzilla would be enhanced in a way that you only have to paste the
package name (+version) in it and then see all open problem reports and
could create a new problem report for it with one more click, it would
be probably used...


not so hard, I think I have a phpscript that would do this. ( from a 
book on php/mysql apps )
actually coded as a bug reporting app.

Re: [Cooker] 9.0 and next

[Ben Reser]

On Wed, Sep 25, 2002 at 07:29:55PM -0400, Gary Lawrence Murphy wrote:
 - A MandrakeUpdate-like ability to incrementally
   or selectively upgrade a cooker installation
   so you can first ensure you are using the very
   latest software before you submit the bug.

It already exists.  urpmi --auto-select.  How do you think we update our
boxes?

-- 
Ben Reser [EMAIL PROTECTED]
http://ben.reser.org

Never take no as an answer from someone who isn't authorized to say yes.

Re: [Cooker] 9.0 and next

[Quel Qun]

First of all, congratulations for this new release.

One thing I really appreciated was the smooth roll in of Gnome2. Really
impressive!
 
 * improved bugzilla to have a easy mail interaction system, and a more
 friendly interface. And to have a last known problems page.
 
I think the mailing list has reached its limit. It was very frustrating
to send problem reports and see them vanish in cyberspace because the
list suddenly collapsed. We complain about incomplete reports, but it
takes time to write a detailed message, cutting and pasting standard out
and co. I cannot afford keeping several terminals per problem open for
hours.

When it was working, however, the mandrake page was nearly showing the
message in real time and that was really nice. Now, what about making
these page searchable with advanced search engine allowing complex
queries (contain this and not that, no older than, etc)?

On the other hand, I don't know if you can afford contempt, but this is
exactly how it looks when a question is asked or a fix is provided and
they receive no echo whatsoever. It would be nice if at least the
package maintainer could acknowledge, even by a message saying:
'Irrelevant' or 'postponed'. A Bugzilla-like system would certainly be
better for that.

Finally, some messages have been posted in Spanish or French. Although I
can understand why the list should be limited to one language only, it
would be nice to provide some help to those who really don't know it.
Maybe a link to babelfish on the cooker page would be a start?

Once again, congrats to all Mandrake people for releasing a good looking
Dolphin in the wild.

=o=
kk1





signature.asc
Description: This is a digitally signed message part

Re: [Cooker] 9.0 and next

[Levi Ramsey]

On Wed Sep 25 19:20 -0700, Quel Qun wrote:
 I think the mailing list has reached its limit. It was very frustrating
 to send problem reports and see them vanish in cyberspace because the
 list suddenly collapsed. We complain about incomplete reports, but it
 takes time to write a detailed message, cutting and pasting standard out
 and co. I cannot afford keeping several terminals per problem open for
 hours.

Was it hardware overload that took the lists down?  Or software overload
at lists with too much traffic?

Perhaps it might make sense to segment the cooker list.  Have
cooker-kde, cooker-gnome, and cooker-apache in addition
to a general cooker list.  Users who have no interest in running Apache
can decide not to subscribe to cooker-apache but instead get a daily
digest, and so forth.  Fred Crozat could then spend most of his time on
the cooker-gnome list and ignore the KDE list.  Developers who only work
on Apache can stick to that list.

-- 
Levi Ramsey
[EMAIL PROTECTED]   [EMAIL PROTECTED]

Love lies in pools of questions.

GPG Key Fingerprint: 354C 7A02 77C5 9EE7 8538  4E8D DCD9 B4B0 DC35 67CD
Currently playing:  Monster Magnet - Tractor
Linux 2.4.19-9mdk
 10:34pm  up  5:39,  4 users,  load average: 0.19, 0.25, 0.18

Re: [Cooker] 9.0 and next

[Jonathan Drews]

On Wednesday 25 September 2002 12:35, Warly wrote:
 9.0 is (likely to be) finished.

 During last 6 months period, and especially in the last beta period,
 some of you give some advice/critic/flame regarding Mandrakesoft
 development process.

 It is now the right time to debrief all this.

 Please comment on what you liked, disliked in the 9.0 building,
 testing and problem reporting process.


 Hello Warly and others:

  I think bug reports should contain, at a minimum, the rpm package and 
the ISO version of mandrake (beta 3, RC1, etc.). That is in the upper 
left hand corner of the e-mail it should give the output of rpm -q 
package or rpm -qf  /path/to/package. 

 Also it may be a good Idea to have a sign up sheet, poll or to do 
list where people can designate which apps they will test. That way no 
packages are left untested and redundant bug reports are not filed from 
over tested packages.  Something like the polling schemes, in Mandrake  
Club,  on a web page:


Package No. of testers already
Nautilus18
Open office   11
Kword  3

 and so on

 That is people click on the apps they intend to test and a poll is then 
generated showing how many folks intend to test that app.

 


-- 
Cheers,
Jonathan



Easy things should be easy, and hard things should be possible.
--Larry Wall

Re: [Cooker] 9.0 and next

[allen]

Excellent.

That's what I meant to suggest with all my rambling, exactly.

Good one.

-AEF

On Wednesday 25 September 2002 10:08 pm, Jonathan Drews wrote:
 On Wednesday 25 September 2002 12:35, Warly wrote:
  9.0 is (likely to be) finished.

   I think bug reports should contain, at a minimum, the rpm package and
 the ISO version of mandrake (beta 3, RC1, etc.). That is in the upper
 left hand corner of the e-mail it should give the output of rpm -q
 package or rpm -qf  /path/to/package.

 Package No. of testers already
 Nautilus18
 Open office   11
 Kword  3

Re: [Cooker] 9.0 and next

[Gary Lawrence Murphy]

 B == Ben Reser [EMAIL PROTECTED] writes:

 - A MandrakeUpdate-like ability to incrementally or selectively
 upgrade a cooker installation

B It already exists.  urpmi --auto-select.  How do you think we
B update our boxes?

You learn something new every day! 

Thanks for the tip.

Maybe we need a Cooker FAQ...

-- 
Gary Lawrence Murphy - [EMAIL PROTECTED] - TeleDynamics Communications
 - blog: http://www.auracom.com/~teledyn - biz: http://teledyn.com/ -
  Computers are useless. They can only give you answers. (Picasso)

Re: [Cooker] 9.0 and next

[Vincent Danen]

On Wednesday, September 25, 2002, at 01:25 PM, J. Greenlees wrote:

 If bugzilla would be enhanced in a way that you only have to paste the
 package name (+version) in it and then see all open problem reports 
 and
 could create a new problem report for it with one more click, it would
 be probably used...


 not so hard, I think I have a phpscript that would do this. ( from a 
 book on php/mysql apps )
 actually coded as a bug reporting app.

Except that Bugzilla's written in perl and the last time I looked at 
it, was very very messy code.

Anthill, on the other hand, is written in PHP.

--
MandrakeSoft Security; http://www.mandrakesecure.net/
lynx - source http://linsec.ca/vdanen.asc | gpg --import
{FE6F2AFD: 88D8 0D23 8D4B 3407 5BD7 66F9 2043 D0E5 FE6F 2AFD}




PGP.sig
Description: PGP signature