diff options
author | Mystery Man <unknown@mandriva.org> | 2002-08-22 15:26:01 +0000 |
---|---|---|
committer | Mystery Man <unknown@mandriva.org> | 2002-08-22 15:26:01 +0000 |
commit | add076e220fdffdeb6de5ae9a9efb6c7e3e0303e (patch) | |
tree | 956c3d91d4b8cfc7851ad7e02301fe5e6db1aa66 /docs/advocacy | |
parent | 76761ff24d3358147c214490defbab4910201d73 (diff) | |
download | drakx-backup-do-not-use-add076e220fdffdeb6de5ae9a9efb6c7e3e0303e.tar drakx-backup-do-not-use-add076e220fdffdeb6de5ae9a9efb6c7e3e0303e.tar.gz drakx-backup-do-not-use-add076e220fdffdeb6de5ae9a9efb6c7e3e0303e.tar.bz2 drakx-backup-do-not-use-add076e220fdffdeb6de5ae9a9efb6c7e3e0303e.tar.xz drakx-backup-do-not-use-add076e220fdffdeb6de5ae9a9efb6c7e3e0303e.zip |
This commit was manufactured by cvs2svn to create tag 'V1_1_9_16mdk'.V1_1_9_16mdk
Diffstat (limited to 'docs/advocacy')
-rw-r--r-- | docs/advocacy | 87 |
1 files changed, 0 insertions, 87 deletions
diff --git a/docs/advocacy b/docs/advocacy deleted file mode 100644 index 9e7f00b6b..000000000 --- a/docs/advocacy +++ /dev/null @@ -1,87 +0,0 @@ -a little DrakX history: - -june 1999: - i start rewriting redhat's install in perl, partly for the fun of it. I'm - still working for the army - -5 july 1999: - i start full time job at mandrakesoft. But we don't have many computers and i - must share the accounting computer with Merieme who is working half-time. No - test machine (i test on others box, and destroyed Jacques partitions once), - guess how it slows things down? - -august 1999: - at last computers, even test one - first DrakX version which can install things, very very rough - -september 1999: - a friend of mine help me 2 weeks on DrakX relayed by Francois - -november 1999: - first released version of DrakX (goldpack). Not really stable yet. - -january 2000: - 7.0 is out, with a DrakX quite stable - -july 2000: - dams starts working on draknet - -mid-october -> mid-january 2000: - gc rewrites the stage1 to win every kb we can - -> size divided by 7 (!) for cdrom - - -The DrakX team is also doing a lot of other things: -- drakxtools -- urpmi, early MandrakeUpdate, early rpmdrake... -- Mandrake Control Center (new DrakConf) -- packages maintenance/enhancing (esp. ghostscript, 3D-wrappers, lilo) -- fixing core packages to make them installable -- scoring packages, sorting them, flagging them... (compssList, rpmsrate) -- reading/answering cooker and other MLs -- helping non-perl gurus :) - -That doesn't give much. Me being the one more working on plain DrakX. It gives 2 -people working for 1.5 years. IMO it isn't ``spending an enormous amount of -resources''. -And what do you mean by ``compared to the code base size''??? DrakX is currently -around 28K lines, which is big IMO. You can compare it with linuxconf which is -170K lines. I think the achievement of DrakX is comparable (a 6 times code size -win from dumb C++ to expressive perl is normal imo). - - -Also it seems like we don't have the same understanding of the word -"maintenance". -DrakX functionalities have evolved *a lot* since the beginning: - -- hardware detection, configuration, debugging, work-arounding (multi-kernel installs...) -- making things prettier - - more bitmaps - - "advanced" button - - syslinux graphical boot -- making it work with latest versions of software (eg: switching to rpm4) -- finding out the best way to use rpmlib -- multi-cd -- draknet: configuring every piece of stupid protocols -- diskdrake: raid, loopback, LVM, resizing, checking stupid users entry -- XFdrake: multi-mice, multi-heads, 3D-accel -- porting to axp/sparc/ppc (with Stew's help) -- always more i18n -- keeping things small - - .cz format - - moving to .png - - getFile on demand from mdkinst for ramdisk installs - -[...] - -> You don't believe the books ? Count yourself; see the man/months spent -> in 'pure' developoment in drakX, and the resources put in mantainance -> of the code base; as far as i know, your count should confirm what the -> books says; more probabily, you will discover that our numbers are -> even worse. - -if you count enhancements, adding features... in maintenance, i confirm the -numbers, and find them quite normal. - -if you only count bug fixing, the time would be much shorter (around 30%). - |