art yerkes wrote:
> > Which is of course fine, but since ReactOS has no use for
> it, why commit it?
> > It isn't needed to meet the goals of ReactOS.
> >
> > Casper
>
> I don't agree with this sentiment at all. We've always
> before been proactive
> about implementing at least visible parts of the API to make
> it more likely
> that applications we didn't know about would have a chance to
> work. I think
> that's a reasonable way to work, especially if you're working
> in an area you've
> got a good understanding of.
I completely agree with this. Some of the rules being proposed seem to be a
little over cautious.
This 'shake up' shouldn't put a strangle hold on the project.
Ged
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
> Too vague in my book. I request a reformulation. I sort of get what you
> try to indicate, but it's too easy to explain incorrectly and the
> meaning as I understand it doesn't include enough APIs to be of any
> significance to note down in the IP policy. There are also arguments
> against it, like the educational purpose of being able to lecture at
> universities on the subject of NT using ReactOS.
Why would you want to lecture on the subject "alternative ways to implement undocumented APIs that are not used by any 3rd party software"?
/Johannes Olofsson
Hi all.
Would someone be willing to put a flow chart together on moving code
from the main branch to the audited branch.
I think if something like this is put in place, it would ensure everyone
was operating in the same manner.
Pasted from IRC when discussing the audit methodologies:
<GedMurphy> I understand what qualifies for being 'unclean' (which it
seems most of ReactOS will be initially), in which case it should be
placed into the intermediate repository. However it isn't clearly
stated what happens then. If documentation can't be located or test
cases aren't written, how is that code further analized?
<sedwards> If the code is 'unclean' then someone need to mark themselves
down to rewrite it on the audit page
<GedMurphy> but what if it's not unclean, but there is no documentation
for it? Is it automatically deemed to be unclean in that case?
<GedMurphy> e.g. Exception wrote most of the original part of the
network stack. I'm positive this was done in a clean manner, but where
are the docs? Does he still have them? What happens if there aren't any
or they have been lost?
<GedMurphy> does rewriting them automatically mean that code is then ok?
<GedMurphy> senario 2. No docs can be found, but someone writes some. If
that code was ripped from Windows assemblies but we provide docs, that
code might get through. However it doesn't get around the fact that it's
been 'borrowed' from Windows dissasemblies.
<GedMurphy> at what point in the audit is the code checked for
similarities to the Windows counterpart, if at all?
<GedMurphy> This is what I mean by set methodologies. Something should
be laid down, like a flow chart
I would offer to do it, but I think one of our more experienced dev
would make a better job. Maybe someone who has done something like this
before. I was hoping for one to follow for myself to make sure I don't
drop a b*ll*ck :)
Ged.
