Martin Schlander wrote: > On Wednesday 10 May 2006 05:20, scsijon wrote: >> Let us split our community away to handle tasks such as:- >> a) assist with small useage \ new idea packages and >> unexpected extension requirements to existing packages.
With "package", you really mean RPMs ? So it would be a restructured/extension of the current wishlist: http://en.opensuse.org/Package_Wishlist Packages requested there should not (only) mean "I want it in the distribution", but could be solved by: - a package (+link) to the build service and/or Factory - a package in a 3rd party repository (packman, guru, suser-*, ...) (although for the latter, we have to keep potential legal implications in mind) >> b) assist as we do now in "field" testing through the beta >> program, but not only SuSE's but other packages that need larger >> variations of testers. That's a good idea. I'd sure like people to also test my packages (and those in Packman) ;D Though it is difficult to think about it now, it is highly dependent on how 3rd party packagers will work with the build service or not. Maybe all packages on Packman will be done through the build service, maybe not. Well, all of them can't be managed in the build service, because of legal reasons (mad, lame, mplayer, ...) >> c) assist as we do now in the problem fix process. Could you elaborate a little what you mean with that ? "Fix process" as in beta test phase or as general help to end-users, i.e. web forums, suse-linux-e, suse-factory, IRC ? >> d) documentation, not only "how to use" types, but "using >> this with these extensions this way allows you to do this" as well >> as "this plus this plus this and either this or this but not including >> this" makes a "qqqq" server. I, for example have decided to spend >> my available time this year in creating a "Mini-Command Useage" Manual >> that lists commands, what they are, their extensions plus a >> number of standard used matrixes (such as ls -la) and what they give >> you back. It will be able to be printed out as a mini-manual (a5/2 flip) >> or a cardfile format for pda's etc. But I will say more on this when I have >> my thoughts in propper order and under an appropriate subject >> header (of which this is not). Right. I would dub this the "howto collection". I think that part is very important, both for helping end-users but also for spreading SUSE Linux. "High level" HOWTOs, e.g. (I mentioned them before, but they're rather good examples IMHO): - how to set up LAMP on SUSE Linux: - SUSE packages to install (possibly with screen shots or CLI) - where/how to configure Apache, SUSE style (YaST2, SUSE's apache2 configuration scheme) - how to start/stop/reload Apache, SUSE style (rcapache2 ...), how to have it started at boot time (chkconfig ...) - how to enable/disable Apache modules - how to set up MySQL - how to create a MySQL database (not SUSE specific) - how to start/stop/reload MySQL, SUSE style (rcmysql ...), how to have it started at boot time (chkconfig ...) - what PHP packages do I need (many php4/php5-* subpackages on SUSE) - where to configure PHP (=> /etc/php.ini) - how to tell Apache to use mod_php* for .php files ? how to do that per vhost ? - how to install/set up PEAR, where do the files go, can I use the pear CLI installer, ... - how to set up an FTP server on SUSE Linux: - install vsftpd or pure-ftpd - how to enable vsftpd at startup (/etc/xinetd.d/vsftpd=>disabled=no + chkconfig xinetd on) etc... etc... Basically, all that information is already available, but spread into various places: - the internet, project homepage (e.g. apache website/documentation), various existing HOWTOs (TLDP, gentoo, ubuntu, fedora, blogs, other) - on other SUSE community websites (e.g. suselinuxsupport.de wiki, alionet, ...) - in the package documentation files (/usr/share/doc/packages/*/*) But there's no complete overview, and most less experienced users will struggle to - find all that information (especially the package documentation files) - use a HOWTO that's not related to SUSE Linux: wrong package names, obsolete information (e.g. recompiling the kernel, not needed on SUSE), wrong file/directory locations, etc... >> e) design and create the direction specifications of what we >> think users will be wanting in the near future. Could you elaborate ? I don't quite understand what you mean with this one. >> f) provide support to our communities across the world by >> assisting with technical translation of ideas and "command formats" Same as above ;) > g) marketing/promotion Yep. > h) writing code/patches As well. In the same category: making packages ;) > I like this idea of splitting things up - but I think we need some kind of We definitely have to categorize/split up those topics, which _could_ mean (just off the top of my head, maybe it's completely inadequate ;)): - specific mailing-lists per topic - specific "homepages" (or index, rather) on the wiki - some kind of structure of teams > formalized leadership/organization (call it what you want). I don't Yes... "some kind of structure of teams" ;) > necessarily believe in "leaders manifesting themselves naturally". I think we > need to form some kind of teams - with (elected) leads. And a wikipage where > you can see who are members of a certain team and how to join - and what the > tasks/responsibilities are, etc. Exactly. Topics, needed skills and interests are way different, which means we have to somehow split/organize/structure them. Splitting also means it's easier to structure and cope with goals, tasks, people. Of course, they're not totally independent and linking must happen where appropriate. And some tasks involve several topics/teams. > Of course everyone who's not in a team would be free to contribute in any way > he/she pleases. Yes, obviously. The "team lead" (or whatever) is not there to decide who may participate or not, it's there to coordinate tasks and communication, and possibly, in extreme situations, take a decision if no agreement can be found inside the team. cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels
signature.asc
Description: OpenPGP digital signature
