[gentoo-dev] A wishlist

[gentoo-dev] A wishlist

[Karl Trygve Kalleberg]

Hi gang.

Lukewarm on the heels of my last post about things that should be in place
before 1.0, I now come with a non-triaged wishlist that are mostly my own
wishes. If there's anything smart in what follows, that's probably due to
pekdon and/or Azarah :)

(If you think the formatting looks like shit, it's because it is. I've
written this as a Gentoo Guide, since I plan on maintaining it as web
document on our site. We do not currently seem to have an XSL that
transforms our guides to pure text [and the html converter also leaves a
lot to be desired]).

Anyway, here follows:



Gentoo Linux Wishlist

  Karl Trygve Kalleberg


This document maintains a prioritized list of features which Gentoo
Linux will have (and not have) in the near and middle future. The list
is posted semi-regularily to the developers' list, where new items are
proposed, prioritized or rejected. 


1.0
2001-10-13


The unsorted items


 Gentool.Configure
 
 Currently, Gentool is (not being) maintained by karltk. Its goal
 is to act as an entry point into portage proper for fancy things that
 we want to have in our package management system.
 I suggest we rename Gentool into Gentools and rather make it into
 a collection of scripts with common syntax/semantics. It could then 
 easily evolve into the Gentoo configuration toolset that handled
 user management, daemon management, hardware managment, etc,
 without being imposed on each user.
 Currently, I suggest the following tools:
 gentool.daemonlist: Lists running and runnable daemons.
 gentool.driverlist: Lists the running subsystems. For some
 machines, most notably portables, it is desirable to turn off
 subsystems that are not in use to conserve battery power. irda, cdrom,
 usb, sound, network/cardbus are examples of this.
 gentool.depends: Lists packages depending on a particular 
 package.
 I realise that this is currently more a collection of inspection
 tools than configuration tools, but I find myself lacking information
 about the packages far too often, ie which package do I have to
 install to get Java ?, which package contains xsltproc ?,
 etc. Sometimes, a simple grep through the ebuilds suffice, other
 times a complex search with google is the only way. 
 



 Subterfuge functionality in Portage
 
 Subterfugue is a low-level system administration tool that can bar
 write access to directories, restrict download speed, inspect and act
 upon operating system level triggers, such as opening of files,
 creation of directories, consumption of memory and similar.
 It would be very beneficial to the Gentoo developers if Portage
 used some of the features of Subterfuge to create a sandbox for
 creating ebuilds
 Most specifically, Subterfuge could be used to ensure that no
 ebuild writes outside its image-directory.
 In addition, for people with slow links, it would be preferrable to
 specify a maximum bandwidth amount that Portage could use for
 downloading large tarballs. Although Subterfuge has the ability to 
 dynamically change the allocated bandwidth, a simple entry in
 /etc/make.conf should suffice.
 



 Sensible default configuations
 
 Only a miniscule subset of our daemons run straight out of the
 box. For many daemons, sensible (paranoid) defaults are fairly easy
 to set by the ebuild.
 Alternatively, we could start thinking about configuration
 profiles that can be applied to a set of applications. While we (and
 our users) really want to configure/tweak most aspects of all
 configurations files ourselves at some point, having a paranoid
 setting in the interim would be better than force the user to 
 hastily put together a configuration that's full of holes.
 



 Ebuild review upon commit
 
 Many of our ebuilds contain small oversights and suffers from not
 being tested enough. We should accept that fact that to err is human,
 and figure out a way to minimize the number of errors
 To that end, I propose we at some point institute a two-level
 checkin mechanism, even for developers. For any package to be
 unmasked (and thus readily available to end-users), at least one
 other developer must look through it and vouch for its
 stability. 
 The proposal is not about assigning blame. It is about
 minimizing the number of errors. I personally try to have a few of
 the denizens on #gentoo test my ebuilds before committing and
 unmasking.
 




The prioritized items



The rejected items

Re: [gentoo-dev] A wishlist

[Martin Schlemmer]

On Sun, 2001-10-14 at 18:41, Karl Trygve Kalleberg wrote:
> 
> Hi gang.
> 
> Lukewarm on the heels of my last post about things that should be in place
> before 1.0, I now come with a non-triaged wishlist that are mostly my own
> wishes. If there's anything smart in what follows, that's probably due to
> pekdon and/or Azarah :)
> 
> (If you think the formatting looks like shit, it's because it is. I've
> written this as a Gentoo Guide, since I plan on maintaining it as web
> document on our site. We do not currently seem to have an XSL that
> transforms our guides to pure text [and the html converter also leaves a
> lot to be desired]).
> 
> Anyway, here follows:
> 
> 
> 
> Gentoo Linux Wishlist
> 
>   Karl Trygve Kalleberg
> 
> 
> This document maintains a prioritized list of features which Gentoo
> Linux will have (and not have) in the near and middle future. The list
> is posted semi-regularily to the developers' list, where new items are
> proposed, prioritized or rejected. 
> 
> 
> 1.0
> 2001-10-13
> 
> 
> The unsorted items
> 
> 
>  Gentool.Configure
>  
>  Currently, Gentool is (not being) maintained by karltk. Its goal
>  is to act as an entry point into portage proper for fancy things that
>  we want to have in our package management system.
>  I suggest we rename Gentool into Gentools and rather make it into
>  a collection of scripts with common syntax/semantics. It could then 
>  easily evolve into the Gentoo configuration toolset that handled
>  user management, daemon management, hardware managment, etc,
>  without being imposed on each user.
>  Currently, I suggest the following tools:
>  gentool.daemonlist: Lists running and runnable daemons.
>  gentool.driverlist: Lists the running subsystems. For some
>  machines, most notably portables, it is desirable to turn off
>  subsystems that are not in use to conserve battery power. irda, cdrom,
>  usb, sound, network/cardbus are examples of this.
>  gentool.depends: Lists packages depending on a particular 
>  package.
>  I realise that this is currently more a collection of inspection
>  tools than configuration tools, but I find myself lacking information
>  about the packages far too often, ie which package do I have to
>  install to get Java ?, which package contains xsltproc ?,
>  etc. Sometimes, a simple grep through the ebuilds suffice, other
>  times a complex search with google is the only way. 
>  
>

Gui/scripts that control the whole system, or just show info will be
nice, but I think some docs on the whole init system and maybe a 
long checkup/fixup/reimplementation to it will be nice.

Look at /etc/modules.autoload (or whatever).  From what I have heard,
it is supposed to replace /etc/modules for autoloading of modules.
Thing just is, I cant find it being parsed anywhere (/etc/init.d/modules
parse /etc/modules and /etc/modules.d).

Yes, these tools will be nice, but I think we need to checkup on the
basesystem first, fix it up, add features, and MOST IMPORTANTLY, 
DOCUMENT IT!  Only then will these tools be of use, otherwise it 
will have to be modified whenever problems with the initsystem is
descoverd and changed.
 
> 
> 
>  Subterfuge functionality in Portage
>  
>  Subterfugue is a low-level system administration tool that can bar
>  write access to directories, restrict download speed, inspect and act
>  upon operating system level triggers, such as opening of files,
>  creation of directories, consumption of memory and similar.
>  It would be very beneficial to the Gentoo developers if Portage
>  used some of the features of Subterfuge to create a sandbox for
>  creating ebuilds
>  Most specifically, Subterfuge could be used to ensure that no
>  ebuild writes outside its image-directory.
>  In addition, for people with slow links, it would be preferrable to
>  specify a maximum bandwidth amount that Portage could use for
>  downloading large tarballs. Although Subterfuge has the ability to 
>  dynamically change the allocated bandwidth, a simple entry in
>  /etc/make.conf should suffice.
>  
> 

YES!  I am _very_ in favour of this.  With all the different ways to
./configure and install source out there, it is very difficult to
ensure that all files is installed in ${D}, and even after reading
the Makefile's install: section, you can still miss something.
A feature that will monitor file/directory creation during 
src_install() will be a major improvement.  On a file that gets
installed outside ${D}, portage should quit, and give an error with
the offending file/directory.

> 
> 
>  Sensible default configuations
>  
>  Only a miniscule subset of our daemons run straight out of the
>  box. For many daemons, sensible (paranoid) defaults are fairly easy
>  to set by the ebuild.
>  Alternatively, we could start thinking about configuration
>  profiles that can be applied to a set of applications. While we (and
>  our users) really want to configure/tweak most aspects of all
>  configurations files ourselves at some point, having a paranoid
>  setting in the interim would be better than force the user to 
>  hastily put together a configuration that's full of holes.
>  
> 

I am not one that installs many services, and usually just the basic
config file with commented options is sufficient for me.  However,
we should relise that not only developers will use Gentoo Linux,
especially when version 1.0 is released.  Then we will have to deal
with end users, and like Karl said, rather a safe, secure config,
then the wide open ones some other distro's have (wont mention names ;p)


> 
> 
>  Ebuild review upon commit
>  
>  Many of our ebuilds contain small oversights and suffers from not
>  being tested enough. We should accept that fact that to err is human,
>  and figure out a way to minimize the number of errors
>  To that end, I propose we at some point institute a two-level
>  checkin mechanism, even for developers. For any package to be
>  unmasked (and thus readily available to end-users), at least one
>  other developer must look through it and vouch for its
>  stability. 
>  The proposal is not about assigning blame. It is about
>  minimizing the number of errors. I personally try to have a few of
>  the denizens on #gentoo test my ebuilds before committing and
>  unmasking.
>  
>

Maybe create a Ebuild Team, who take over Dan's job of filtering ebuilds
to incoming.  Also developers should mail updates/changes to
gentoo-ebuild, and these people test it first before it gest unmasked.
Guess this team dont have to be big, 1 or 2 people should sufficient for
now.  Maybe just people with high speed connections (I know how long it
takes me to download on 56k ... usually way longer than creating the
ebuild).


And yes, it is not assigning blame, but what works on your system,
could be broken on another system.
 
> 
> 
> 
> The prioritized items
> 
> 
> 
> The rejected items
> 
> 

My own wishlist:  Layout for a .ebuild

Especially with the gnome move to /usr, I had to modify a LOT of
ebuilds.  And usually not two's form was the same (even with the
same author).  

Main points this form should touch (my opinion of course ;-):

1) Lay out the musts and must nots for a ebuild.  The ${A} issue
etc.

2) Explain some of the hidden features that I have to find out
by hacking lots of other ebuilds.

3) Have a Changelog ... things that worked one way, now a different way.
Not nice to have used something, then next time find out it changed.

4) Neatness.  Go into how the form of NEAT ebuild should be.  You
must remember that with every ebuild, you are creating a building
block that others will build apon ....

5) Upgradebility.  Any Ebuild should be able to just be copied to the
new version, and then work out of the box (excluding compile errors).
I think the mplayer ebuild is a nice example of this, it will work for
release and pre versions.  The VIM ebuild is another example.

6) Everything else i forgot.



I am no doc writer, so excuse if not too clear.


Greetings

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop Team Developer
Cape Town, South Africa
Town, South Africa

Re: [gentoo-dev] A wishlist

[Mikael Hallendal]

[-- Attachment #1: Type: text/plain, Size: 4701 bytes --]

sön 2001-10-14 klockan 19.41 skrev Martin Schlemmer:
> On Sun, 2001-10-14 at 18:41, Karl Trygve Kalleberg wrote:
>
> >  Subterfuge functionality in Portage
> >  
> >  Subterfugue is a low-level system administration tool that can bar
> >  write access to directories, restrict download speed, inspect and act
> >  upon operating system level triggers, such as opening of files,
> >  creation of directories, consumption of memory and similar.
> >  It would be very beneficial to the Gentoo developers if Portage
> >  used some of the features of Subterfuge to create a sandbox for
> >  creating ebuilds
> >  Most specifically, Subterfuge could be used to ensure that no
> >  ebuild writes outside its image-directory.
> >  In addition, for people with slow links, it would be preferrable to
> >  specify a maximum bandwidth amount that Portage could use for
> >  downloading large tarballs. Although Subterfuge has the ability to 
> >  dynamically change the allocated bandwidth, a simple entry in
> >  /etc/make.conf should suffice.

Yes, this would be great!
 
> > 
> > 
> >  Sensible default configuations
> >  
> >  Only a miniscule subset of our daemons run straight out of the
> >  box. For many daemons, sensible (paranoid) defaults are fairly easy
> >  to set by the ebuild.
> >  Alternatively, we could start thinking about configuration
> >  profiles that can be applied to a set of applications. While we (and
> >  our users) really want to configure/tweak most aspects of all
> >  configurations files ourselves at some point, having a paranoid
> >  setting in the interim would be better than force the user to 
> >  hastily put together a configuration that's full of holes.
> >  
> > 
> 
> I am not one that installs many services, and usually just the basic
> config file with commented options is sufficient for me.  However,
> we should relise that not only developers will use Gentoo Linux,
> especially when version 1.0 is released.  Then we will have to deal
> with end users, and like Karl said, rather a safe, secure config,
> then the wide open ones some other distro's have (wont mention names ;p)

Disable everything not needed during installation. Close all ports and
make the defaultinstallation unaccessable from net.

> >  Ebuild review upon commit
> >  
> >  Many of our ebuilds contain small oversights and suffers from not
> >  being tested enough. We should accept that fact that to err is human,
> >  and figure out a way to minimize the number of errors
> >  To that end, I propose we at some point institute a two-level
> >  checkin mechanism, even for developers. For any package to be
> >  unmasked (and thus readily available to end-users), at least one
> >  other developer must look through it and vouch for its
> >  stability. 
> >  The proposal is not about assigning blame. It is about
> >  minimizing the number of errors. I personally try to have a few of
> >  the denizens on #gentoo test my ebuilds before committing and
> >  unmasking.
> >  
> >
> 
> Maybe create a Ebuild Team, who take over Dan's job of filtering ebuilds
> to incoming.  Also developers should mail updates/changes to
> gentoo-ebuild, and these people test it first before it gest unmasked.
> Guess this team dont have to be big, 1 or 2 people should sufficient for
> now.  Maybe just people with high speed connections (I know how long it
> takes me to download on 56k ... usually way longer than creating the
> ebuild).

Hmm, while this might be needed in the future I don't think we have the
capacity for this currently. We are about 10 active developers and the
Gentoo development would more or less stop if this had to be done. Just
look at how good we are at handling gentoo-ebuild now, if all developers
has to mail there aswell nothing would go in.

Regards,
  Mikael Hallendal

> My own wishlist:  Layout for a .ebuild

Yes, we need a standard for layout on ebuilds. This is exactly as
codingstandards in coding-projects. It's very important for
maintainability.

We need to write a document describing this and all developers has to
follow this even if they might not like the syntax.

I try to make all my ebuilds look the same and probably others try that
aswell. One problem now is that no one knows who is responsible for
which ebuilds.

If we can't decide on a syntax for our ebuilds we have to make a list of
who maintains which packages and after that people shouldn't commit on
each others ebuilds. (I prefer the first way).

Regards,
  Mikael Hallendal

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] A wishlist

[Joshua Pierre]

> > My own wishlist:  Layout for a .ebuild
> 
> Yes, we need a standard for layout on ebuilds. This is exactly as
> codingstandards in coding-projects. It's very important for
> maintainability.
> 
> We need to write a document describing this and all developers has to
> follow this even if they might not like the syntax.
> 
> I try to make all my ebuilds look the same and probably others try that
> aswell. One problem now is that no one knows who is responsible for
> which ebuilds.
> 
> If we can't decide on a syntax for our ebuilds we have to make a list of
> who maintains which packages and after that people shouldn't commit on
> 

Yes! Definately need this for ebuild's. However, the current documentation is
unfinished so perhaps we can set some standards and finalise the whole lot.

I will volunteer to help write documentation and possibly form the original 
standards with a team of several Gentoo developers.

Just let me know if you want some help with this as I will be more than willing
to help write some documentation.

Regards,

Joshua Pierre
-- 
You can do it, you can do it all night long

[gentoo-dev] rc6 "bash:mc"

[Mark King]

I was installing rc6-r10

and noticed this error occuring repeatedly during
bootstrap and all other emerges I preformed. make.conf
is default make.conf with default USE uncommented and
section for PIII/ ATHLON uncommented. Is this a normal
"error" or something I should probe deeper?

bash: mc: line 2: unexpected EOF while looking for
matching "'
bash: mc: line 4:unexpected end of file
bash: error: importing function definition for 'mc'

Thanks in advance
Mark


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: [gentoo-dev] rc6 "bash:mc"

[Daniel Robbins]

On Sat, Oct 20, 2001 at 10:21:50AM -0700, Mark King wrote:
> I was installing rc6-r10
> 
> and noticed this error occuring repeatedly during
> bootstrap and all other emerges I preformed. make.conf
> is default make.conf with default USE uncommented and
> section for PIII/ ATHLON uncommented. Is this a normal
> "error" or something I should probe deeper?
> 
> bash: mc: line 2: unexpected EOF while looking for
> matching "'
> bash: mc: line 4:unexpected end of file
> bash: error: importing function definition for 'mc'
> 
> Thanks in advance
> Mark

I think you have a syntax error in your make.conf.  Make sure
that your USE variable does not have embedded #comments in it.

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] rc6 "bash:mc"

[Mark King]

--- Daniel Robbins <drobbins@gentoo.org> wrote:
> On Sat, Oct 20, 2001 at 10:21:50AM -0700, Mark King
> wrote:
> > I was installing rc6-r10
> > 
> > and noticed this error occuring repeatedly during
> > bootstrap and all other emerges I preformed.
> make.conf
> > is default make.conf with default USE uncommented
> and
> > section for PIII/ ATHLON uncommented. Is this a
> normal
> > "error" or something I should probe deeper?
> > 
> > bash: mc: line 2: unexpected EOF while looking for
> > matching "'
> > bash: mc: line 4:unexpected end of file
> > bash: error: importing function definition for
> 'mc'
> > 
> > Thanks in advance
> > Mark
> 
> I think you have a syntax error in your make.conf. 
> Make sure
> that your USE variable does not have embedded
> #comments in it.
> 
> -- 
> Daniel Robbins				

------begin make.conf------------
# Copyright 2000 Daniel Robbins, Gentoo Technologies,
Inc.
# Contains system settings for Portage system

# Recommended USE variables
# -------------------------
#
USE="slang readline gpm oss berkdb gdbm tcpd pam
libwww ssl alsa nls mitshm perl python esd gif sdl
vorbis ogg gnome gtk X qt kde motif opengl mozilla
objprelink"

# PIII and Athlon-class machines
# --------------------------------------------

CHOST="i686-pc-linux-gnu"
CFLAGS="-mcpu=i686 -march=i686 -O3 -pipe"
CXXFLAGS="-mcpu=i686 -march=i686 -O3 -pipe"

----------------end make.conf-------------

this is the make.conf file I have. I continued with
errors until I had a bootable system and then booted
into gentoo and had no further problems emerging
packages. Thanks for the help.
Mark 


__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

Re: [gentoo-dev] A wishlist

[Dan Armak]

Some followups and suggestions:

For the documented portage API:
I don't mind it being in python, although c/c++ would be nice sometime down 
the road. This is a must for all the stuff karltk calls Gentool.Configure.
At least, I wish for a short summary of the portage.py api. I tried reading 
it through; there are no comments at all.

For the ebuild review team:
They could have several separate Gentoo installs. Maybe in chroots.
One would be empty (emerge system only), good for checking depends. Ebuilds 
are unmerged once they are confirmed to be working.
Another would have all existing ebuilds installed, good for checking 
conflicts. It would also have all revs installed, good for checking upgrades 
and different dep version scenarios.
We could have [at least] two devs on the team, one for each of these configs, 
running emerges in the background whenever they aren't using the cpu. Say on 
non-main machines.
Of course, there'll probably also be a more standard testing machine.

For the ebuild layout (Martin's wish):
IMHO one of the best things here, beyond guides and docs, is eclasses. They 
ensure maximum standardization, and a lot of other fun things too.

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] A wishlist

[Dan Armak]

Another item: an automated dependency checker.

It would build a file->package database from /var/db/pkg and update it 
whenever a request for a non-registered file is made.

It would run ldd on all dynamic exes in CONTENTS of a requested package, find 
which packages the linked libraries were from and list the packages.

With an interface to portage.py, it could caculate the DEPEND of the ebuild 
and list missed deps.

Also, maybe this Subterfuge can make a list of programs called by the ebuild 
during emerge (make, gcc, ld, perl, whatever) and look those up too.

-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] A wishlist

[Joshua Pierre]

On Mon, Oct 15, 2001 at 12:47:59AM +0200, Dan Armak wrote:
> Another item: an automated dependency checker.

So, something like Debian?

Would be quite cool if implemented, although difficult.

-J.
-- 
You can do it, you can do it all night long

Re: [gentoo-dev] A wishlist

[Chris Houser]

Dan Armak wrote:                      [Sun Oct 14 2001,  6:47:59PM EDT]         
> Another item: an automated dependency checker.
> 
> It would build a file->package database from /var/db/pkg and update it 
> whenever a request for a non-registered file is made.

This is done, although not well documented:
    gentoo-src/portage/bin/pdb

> It would run ldd on all dynamic exes in CONTENTS of a requested package, find 
> which packages the linked libraries were from and list the packages.

This isn't hard -- I wrote a little perl script to do this, but lost it
in my reiserfs fiasco.  I will try to write it again -- maybe in python
this time.

> With an interface to portage.py, it could caculate the DEPEND of the ebuild 
> and list missed deps.

It could assist it calculating the DEPEND, but there's no good way for
it to figure out version numbers, I think.  It could list missing deps,
and the ebuild author would have to make judgement calls about which
version to require.

> Also, maybe this Subterfuge can make a list of programs called by the ebuild 
> during emerge (make, gcc, ld, perl, whatever) and look those up too.

Hm! Interesting idea.  We've been discussing having emerge do everything
accept the merge itself as a non-root user to prevent 'make install'
accidents.  But if subterfuge could help with this step, perhaps it
would be a better solution.

--Chouser

Re: [gentoo-dev] A wishlist

[Joshua Pierre]

Hey :)

There is only one thing I can think of at the moment besides the bug/feature
tracking system and that it is an extra mailing list, gentoo-user.

I only ask for this list because Gentoo is getting more popular by the day
and as a result there will be more questions out there and I am not sure that
gentoo-dev or gentoo-ebuild is the correct place for the questions.

Hopefully a few of you agree with me so we can get this list happening :)

Just a suggestion though.

Regards,

Joshua Pierre
--
You can do it, you can do it all night long!

Re: [gentoo-dev] A wishlist

[Mikael Hallendal]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

mån 2001-10-15 klockan 15.17 skrev Joshua Pierre:
> Hey :)

Hi!
 
> There is only one thing I can think of at the moment besides the bug/feature
> tracking system and that it is an extra mailing list, gentoo-user.

Yes!

What I'd like to see is:

1) Set up a bug/feature/todo tracking system. This should be used   
   instead of dev-wiki (or these features should be added to dev-wiki).
   
   IMHO this should be _ONE_ system, Bugzilla is perfect for this 
   (before you start yelling that bugzilla is hard to learn read below).
   It is good to have all this in one system, a person adds a bug, I 
   move it to my todo-list (ie. assign it to me) instead of having to 
   manually move the item to my todo-list (if we use dev-wiki together 
   with some other system).

   I vote for setting up a new system (Bugzilla, GNATS, roundup,  
   whichever we find the best). The reason for this is that Thread 
   (author of dev-wiki), seems to have dropped Gentoo completly. And as 
   I've said since before dev-wiki was developed, there will be much
   more work to add features than to disable them (we would just end up 
   developing another bugzilla for no gain).

2) Remove gentoo-ebuild list, ebuilds should be commited through our 
   bug/feature/todo-tracking system. The current setup is insane, where 
   Dan has to manually move the ebuilds/patches to portage/incoming and
   add a todo in dev-wiki.

About Bugzilla:

Bugzilla is a set of cgi-scripts. Just because the default setup is hard
to learn doesn't mean that it can't be made easier. I like the
default-interface since I've taken the time to learn it (it's very
powerful). But I don't think that we should require our users to learn
it. I therefor propuse that we make a couple of simplified interfaces:

* Submit a bugreport: An easy interface where you can state which 
  package, version, error.

* Submit a featurerequest: These gets tagged with keyword FEATURE.

* Submit a todo: Set team, priority, what should be done. tagged with 
  TODO.

Ximian has such a interface for simple bugreports:
http://bugzilla.ximian.com/simple-bug-guide.html

And we can generate nice summarys like:
http://bugzilla.ximian.com/evo-report.cgi

-- 

Mikael Hallendal
Gentoo Linux Developer, Desktop Team Leader
CodeFactory AB, Stockholm, Sweden


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] A wishlist

[Joshua Pierre]

> About Bugzilla:
> 
> Bugzilla is a set of cgi-scripts. Just because the default setup is hard
> to learn doesn't mean that it can't be made easier. I like the
> default-interface since I've taken the time to learn it (it's very
> powerful). But I don't think that we should require our users to learn
> it. I therefor propuse that we make a couple of simplified interfaces:
> 
> * Submit a bugreport: An easy interface where you can state which 
>   package, version, error.
> 
> * Submit a featurerequest: These gets tagged with keyword FEATURE.
> 
> * Submit a todo: Set team, priority, what should be done. tagged with 
>   TODO.
> 
> Ximian has such a interface for simple bugreports:
> http://bugzilla.ximian.com/simple-bug-guide.html
> 
> And we can generate nice summarys like:
> http://bugzilla.ximian.com/evo-report.cgi
> 

Definately, Ximian make Bugzilla very easy to use so I am guessing it can be 
both powerful and a much easier tool to use than the wiki.

Hopefully we can get this up before 1.0/rc6 :)

Anyway, just my two cents to say that I support Bugzilla and the use of it in
Gentoo.

Joshua Pierre
-- 
You can do it, you can do it all night long