On Wed, 30 Aug 2000, Andreas Beck wrote:
> > > I need to talk to Marcus about that, to recheck, that there isn't much that
> > > really needs to be fixed.
>
> > No! You and Marcus _NEVER_ will find _every_ bug!
>
> We never claimed that. However we both know probably best where some
> conceptual problem lie deep within the code, especially in very obscure
> areas, which were pretty often written by one of us.
>
> These are not bugs in the sense of "it doesn't work", but rather small
> deficiencies in interfaces that would make some possible future
> enhancements hard.
Sure. But the user-community can give hints, you didn't though about, which may
helpful to find these conceptual problems you are speaking of.
> > Only a _community_ can do that. Make _public pre-releases_ available
>
> We have CVS and daily snapshots. Everyone can review the code.
Sure. But who _does_ that? How much users reported bugs, which are fixed a long
time?
> This is not about me and Marcus doing some kind of conspiracy. It's just
> that we had some issues that need sorting out on our schedule in the past.
>
> But o.k. - as you want to know it, I'll tell you about the most prevalent
> issue we worried about the last time we talked:
>
> Security. LibGGI is - due to its dynamic loading mechanism and its external
> configurabilty via the environment - very unsuitable to be run suid.
>
> While most people here will agree, that there isn't much use in making
> LibGGI progs suid, SVGAlib users might think otherwise as well as some
> lazy people that would like to make something like ggipasswd or similar,
> without doing "the right thing" and split it into a front- and a backend.
How about forcing people doing "the right thing"?
> I see two possible solutions:
>
> 1. Moan at ggiInit, if eid!=id. Teach people not to do that. Bad for the
> SVGAlib target maybe.
That is IHMO the right solution. Just do a special handling _in_ the target and
keep all other code "as-is".
> 2. Check through all of the code, replacing all file operations with "safe"
> versions that work on the uid of the calling user, checking all fork()s
> and stuff to start things with the right uid (like the pipe-feature in
> the file-target), etc. .
Don't do that. That makes the code less cleaner and slower.
> > - EARLY AND OFTEN - and wait for feedback from the user-community!
> > This is much more efficient. You will see.
>
> Technically this has been done the last few weeks ... except that noone
> announced something like a "feature freeze - please test everything".
>
> I had assumed that would be done automatically by the people here, when they
> see a CVS update bring significant changes.
I think, people don't do that, because they don't notice, when changes
happened to the cvs-tree.
But every second or at least third release will be announced automatically by
the maintainers, so that people will notice that.
> > > When we agreed on that, making a release would be
> > > nothing but keeping our hands off the code until the next snapshot
> > > generation, if we adopt the model from 3.
>
> > OK. Please don't forget to post a actual job list permamently for the
> > final release. Each point should be small enough, so that it can
> > ideomatically be done within a few days...
>
> Don't think there will be much to do.
Don't undervalue that. You have each job to check out, which _kind_ is it
and belongs to which section:
TODO and SHOW-STOPPER
-----------------------
- do this and that...
- update the documentation...
- sort out and update the libedemo-extension...
- blabla...
- ....
TODO and NON-STOPPER
----------------------
- libwmh isn't finished yet...
- libgwt need's lots of work...
- finish the directX-target...
- blabla...
- ....
TO CHECK
--------
- this and that should be fixed now. Please check, if it works for you...
- libgic has reached the alpha-state. Please check, if it works for you...
- blabla
- ...
DONE
----
- this and that is done. Should work well for most people...
- ....
I hope I am clear enough...
> > > 7. Someone suggested a big IRC meeting.
>
> > Yes! But please don't forget to post the log to the ML... ;-) see my
> > earlier mail.
>
> Yeah - we've done that always anyway.
OK.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
