Re: [ros-cvs] CVS Update: reactos

[Alex Ionescu]

[e-mail] wrote:
> CVSROOT:	/CVS/ReactOS
> Module name:	reactos
> Repository:	reactos/tools/
> Changes by:	[e-mail]	04/10/24 10:51:33
>
> Modified files:
>    ./: ChangeLog 
>    reactos/ntoskrnl/: Makefile 
>    reactos/regtests/regtests/: regtests.c regtests.def 
>    reactos/regtests/shared/: regtests.h 
>    reactos/tools/: regtests.c 
> Added files:
>    reactos/ntoskrnl/tests/: .cvsignore Makefile setup.c stubs.tst 
>    reactos/ntoskrnl/tests/tests/: .cvsignore
>
> Log message:
>    2004-10-24  Casper S. Hornstrup  [e-mail]
> ntoskrnl/Makefile (TARGET_REGTESTS): Define to yes.
> regtests/regtests/regtests.c (_ExitProcess): Declare.
> regtests/regtests/regtests.def (_ExitProcess@4): Ditto.
> regtests/shared/regtests.h (_ExitProcess): Ditto.
> tools/regtests.c: Exit process using _ExitProcess();
>
> Properly support fastcall symbols.
> ntoskrnl/tests: New directory.
> ntoskrnl/tests/tests: Ditto.
> ntoskrnl/tests/.cvsignore: New file.
> ntoskrnl/tests/Makefile: Ditto.
> ntoskrnl/tests/setup.c: Ditto.
> ntoskrnl/tests/stubs.tst: Ditto.
> ntoskrnl/tests/tests/.cvsignore: Ditto.
>
> Ros-cvs mailing list
> [e-mail]
> http://reactos.com/mailman/listinfo/ros-cvs

Hi,

I can't say I'm terribly overjoyed with having the /tests directory in 
/ntoskrnl. Would it be possible instead to have a /tests root (on the 
new SVN server) where all the tests would go? like /tests/ntoskrnl, 
/tests/kmregtests etc...

I think it would make it a bit clearer...it just bugs me to have /tests 
in ntoskrnl.

Best regards,
Alex Ionescu

[Filip Navara]

Alex Ionescu wrote:
> Hi,
>
> I can't say I'm terribly overjoyed with having the /tests directory in 
> /ntoskrnl. Would it be possible instead to have a /tests root (on the 
> new SVN server) where all the tests would go? like /tests/ntoskrnl, 
> /tests/kmregtests etc...
>
> I think it would make it a bit clearer...it just bugs me to have 
> /tests in ntoskrnl.

I'm personally quite happy with having tests as near as possible to the 
respective component. Wine does that for years and it works very well...

Regards,
Filip

[Alex Ionescu]

Filip Navara wrote:
> Alex Ionescu wrote:
> > Hi,
> >
> > I can't say I'm terribly overjoyed with having the /tests directory 
> > in /ntoskrnl. Would it be possible instead to have a /tests root (on 
> > the new SVN server) where all the tests would go? like 
> > /tests/ntoskrnl, /tests/kmregtests etc...
> >
> > I think it would make it a bit clearer...it just bugs me to have 
> > /tests in ntoskrnl.
>
> I'm personally quite happy with having tests as near as possible to 
> the respective component. Wine does that for years and it works very 
> well...
>
> Regards,
> Filip
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

How is /tests/ntoskrnl not near? You have to remember that not everyone 
wants to download the tests simply for building the core kernel, or even 
wait for them to be compiled. Part of the new directory structure that 
we are working on is exactly to ease down the bandwidth for developers 
or users who only want the kernel. They shouldn't be bothered with an 
obligatory test sub-directory (ie, this is also the reason Steven 
removed apps/tests). The advantage of the SVN tree will be that the 
/tests directory will have its own repository but still be included of a 
master repository/makefile for those who wish to have it all.

Best regards,
Alex Ionescu

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alex Ionescu
> Sent: 24. oktober 2004 22:29
> To: ReactOS Development List
> Subject: Re: [ros-dev] Re: [ros-cvs] CVS Update: reactos
>
> Filip Navara wrote:
> > Alex Ionescu wrote:
> > > Hi,
> > >
> > > I can't say I'm terribly overjoyed with having the /tests
>
> directory
> > > in /ntoskrnl. Would it be possible instead to have a
>
> /tests root (on
> > > the new SVN server) where all the tests would go? like 
> > > /tests/ntoskrnl, /tests/kmregtests etc...
> > >
> > > I think it would make it a bit clearer...it just bugs me to have 
> > > /tests in ntoskrnl.
> >
> > I'm personally quite happy with having tests as near as possible to 
> > the respective component. Wine does that for years and it
>
> works very
> > well...
> >
> > Regards,
> > Filip
> > _______________________________________________
> > Ros-dev mailing list
> > [e-mail]
> > http://reactos.com:8080/mailman/listinfo/ros-dev
>
> How is /tests/ntoskrnl not near? You have to remember that 
> not everyone wants to download the tests simply for building 
> the core kernel, or even wait for them to be compiled. Part 
> of the new directory structure that we are working on is 
> exactly to ease down the bandwidth for developers or users 
> who only want the kernel. They shouldn't be bothered with an 
> obligatory test sub-directory (ie, this is also the reason 
> Steven removed apps/tests). The advantage of the SVN tree 
> will be that the /tests directory will have its own 
> repository but still be included of a master 
> repository/makefile for those who wish to have it all.
>
> Best regards,
> Alex Ionescu

I feel really bad about you not considering tests as important
as "normal" code. I'm convinced that Extreme Programming (XP)
is the methodology for us to use and I'm set out to prove it.
XP is very good for high risk dynamic projects with varying
resources and this is exactly what ReactOS is.

If you are making a distribution and does not even bother to
run the tests before packaging it, why bother release the
possibly broken package then? If you are just monitoring
development why don't you just download one of the pre-built
packages? If you are a developer why wouldn't you want to run
the tests before a commit to make sure you didn't break
anything?

I want to make the tests an integral part of ReactOS
development. Not something that is just there because
then we can say we have tests for our software. So my
requirements are that running tests should be easy. You
write a test, then you write the domain code (the code
being tested) and finally you run the tests to make sure that
the domain code works as expected. There is no need to boot
ReactOS (in a VM or whatever) during this process so the
process is fast compared to booting ReactOS in order to test
every little change. Then you do it again and again until you
are satisfied with the result. Now you boot ReactOS and make
sure that it behaves as expected. If it does what you expect
it to then commit and go back to the first step otherwise just
go back to the first step.

See http://www.extremeprogramming.org/ for more information.

Casper

[Alex Ionescu]

Casper Hornstrup wrote:
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Alex Ionescu
> > Sent: 24. oktober 2004 22:29
> > To: ReactOS Development List
> > Subject: Re: [ros-dev] Re: [ros-cvs] CVS Update: reactos
> >
> > Filip Navara wrote:
> > > Alex Ionescu wrote:
> > > > Hi,
> > > >
> > > > I can't say I'm terribly overjoyed with having the /tests
> >
> > directory
> > > > in /ntoskrnl. Would it be possible instead to have a
> >
> > /tests root (on
> > > > the new SVN server) where all the tests would go? like 
> > > > /tests/ntoskrnl, /tests/kmregtests etc...
> > > >
> > > > I think it would make it a bit clearer...it just bugs me to have 
> > > > /tests in ntoskrnl.
> > >
> > > I'm personally quite happy with having tests as near as possible to 
> > > the respective component. Wine does that for years and it
> >
> > works very
> > > well...
> > >
> > > Regards,
> > > Filip
> > > _______________________________________________
> > > Ros-dev mailing list
> > > [e-mail]
> > > http://reactos.com:8080/mailman/listinfo/ros-dev
> >
> > How is /tests/ntoskrnl not near? You have to remember that 
> > not everyone wants to download the tests simply for building 
> > the core kernel, or even wait for them to be compiled. Part 
> > of the new directory structure that we are working on is 
> > exactly to ease down the bandwidth for developers or users 
> > who only want the kernel. They shouldn't be bothered with an 
> > obligatory test sub-directory (ie, this is also the reason 
> > Steven removed apps/tests). The advantage of the SVN tree 
> > will be that the /tests directory will have its own 
> > repository but still be included of a master 
> > repository/makefile for those who wish to have it all.
> >
> > Best regards,
> > Alex Ionescu
>
> I feel really bad about you not considering tests as important
> as "normal" code. I'm convinced that Extreme Programming (XP)
> is the methodology for us to use and I'm set out to prove it.
> XP is very good for high risk dynamic projects with varying
> resources and this is exactly what ReactOS is.
>
> If you are making a distribution and does not even bother to
> run the tests before packaging it, why bother release the
> possibly broken package then? If you are just monitoring
> development why don't you just download one of the pre-built
> packages? If you are a developer why wouldn't you want to run
> the tests before a commit to make sure you didn't break
> anything?
>
> I want to make the tests an integral part of ReactOS
> development. Not something that is just there because
> then we can say we have tests for our software. So my
> requirements are that running tests should be easy. You
> write a test, then you write the domain code (the code
> being tested) and finally you run the tests to make sure that
> the domain code works as expected. There is no need to boot
> ReactOS (in a VM or whatever) during this process so the
> process is fast compared to booting ReactOS in order to test
> every little change. Then you do it again and again until you
> are satisfied with the result. Now you boot ReactOS and make
> sure that it behaves as expected. If it does what you expect
> it to then commit and go back to the first step otherwise just
> go back to the first step.
>
> See http://www.extremeprogramming.org/ for more information.
>
> Casper
>
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

Casper,

I will be one of the first people to stand up in line and yell "we need 
tests", and I strongly agree with all your points, but you misunderstood 
mine.

My points were:
1) It is, in my opinion, cleaner to have a tests directory separate 
(This doesn't mean optional or not included or whatever, it will work 
the same way as you said). This is personal choice and debatable.
2) It is, factually, adding to the ReactOS direcotry what ****USERS**** 
will consider as junk. I run multiple programs from CVS, where I just 
build them. But I am not a developer for those projects. Nothing bugs me 
more then downloading 15MB worth of CVS files out of which only 4MB are 
source code and the other 11MB are stuff only the devs would want/need.

What I meant by "unnormal" code was code that is not part of the React 
Operating System. I didn't mean it as not part of the ReactOS Project. 
By not part of, I mean that it doesn't export or provide any functions 
that are compiled into the system. That's all.

So so reiterate, I have nothing against XP and I think tests are very 
valuable. I was just giving my opinion that I think they are in the 
wrong place.

Best regards,
Alex Ionescu

[Casper Hornstrup]

> Casper,
>
> I will be one of the first people to stand up in line and 
> yell "we need tests", and I strongly agree with all your 
> points, but you misunderstood mine.
>
> My points were:
> It is, in my opinion, cleaner to have a tests directory
>
> separate (This doesn't mean optional or not included or 
> whatever, it will work the same way as you said). This is 
> personal choice and debatable.

My arguments against it are:

* It will cause them not to be maintained. If a component is
moved then it is likely that possible related test are not
moved with them. I've seen this before. This was also the
reason I was pro inline API status data. Had the API status
data been in separate files they would likely not have been
maintained as good as they are today.

* It makes the build system even more complex. Now you also have
to tell the tests where to find the component containing the
domain code and tell the component where to find the related
tests (so "make test" works). This adds extra dependencies.
> It is, factually, adding to the ReactOS direcotry what
>
> ****USERS**** will consider as junk. I run multiple programs 
> from CVS, where I just build them. But I am not a developer 
> for those projects. Nothing bugs me more then downloading 
> 15MB worth of CVS files out of which only 4MB are source code 
> and the other 11MB are stuff only the devs would want/need.

Why can't you use the prebuilt binaries or packaged source code?
The repository is and will always be a tool for the developers.
Users should never have to use it and if they want to be wannabe
developers they need to accept the consequences of their actions.

Casper
> What I meant by "unnormal" code was code that is not part of 
> the React Operating System. I didn't mean it as not part of 
> the ReactOS Project. 
> By not part of, I mean that it doesn't export or provide any 
> functions that are compiled into the system. That's all.
>
> So so reiterate, I have nothing against XP and I think tests 
> are very valuable. I was just giving my opinion that I think 
> they are in the wrong place.
>
> Best regards,
> Alex Ionescu

On Mon, Oct 25, 2004 at 07:43:13PM +0200, Casper Hornstrup wrote:
> > It is, factually, adding to the ReactOS direcotry what
> >
> > ****USERS**** will consider as junk. I run multiple programs 
> > from CVS, where I just build them. But I am not a developer 
> > for those projects. Nothing bugs me more then downloading 
> > 15MB worth of CVS files out of which only 4MB are source code 
> > and the other 11MB are stuff only the devs would want/need.
>
> Why can't you use the prebuilt binaries or packaged source code?
> The repository is and will always be a tool for the developers.
> Users should never have to use it and if they want to be wannabe
> developers they need to accept the consequences of their actions.

In addition to this. With the continuous integration in place we need to
compile after each change, so it will be very easy to offer a cd iso/
binaries after _every_ change, so there's really no reason why a user
would want to use the cvs (unless he's a compilation addict or
something).

Mark

[Steven Edwards]

--- Alex Ionescu [e-mail] wrote:
> obligatory test sub-directory (ie, this is also the reason Steven 
> removed apps/tests). The advantage of the SVN tree will be that the 
> /tests directory will have its own repository but still be included
> of a

I removed apps/tests not because I disagree with having the tests in
the main module but because apps/tests sucked. It was not a real
regression suite and it needed to die a long time ago. I like the
library/test layout for regression tests. It works for Wine and it can
work for us. Not to mention it will mean less work keeping our changes
and Wines in sync.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Filip Navara
> Sent: 24. oktober 2004 21:56
> To: ReactOS Development List
> Subject: Re: [ros-dev] Re: [ros-cvs] CVS Update: reactos
>
> Alex Ionescu wrote:
> > Hi,
> >
> > I can't say I'm terribly overjoyed with having the /tests
>
> directory in
> > /ntoskrnl. Would it be possible instead to have a /tests
>
> root (on the
> > new SVN server) where all the tests would go? like /tests/ntoskrnl, 
> > /tests/kmregtests etc...
> >
> > I think it would make it a bit clearer...it just bugs me to have 
> > /tests in ntoskrnl.
>
> I'm personally quite happy with having tests as near as 
> possible to the respective component. Wine does that for 
> years and it works very well...
>
> Regards,
> Filip

They could, but I also think they should be close the what they test.
This makes it much clearer as to what they test and it also makes it
harder to forget to move them in a repository restructuring.

Casper

[Thomas Weidenmueller]

Filip Navara wrote:
> I'm personally quite happy with having tests as near as possible to 
> the respective component. Wine does that for years and it works very 
> well...

I have to agree with Alex. In my opinion all kind of test code 
(including regression tests) should stay out of the core implementation 
tree. Having test directories spread all over the place is imo ugly and 
disturbing. I'd rather like to have them collected in one folder or 
repository.

Best Regards,
Thomas

[Jason Filby]

Hi
> I have to agree with Alex. In my opinion all kind of test code
> (including regression tests) should stay out of the core implementation
> tree. Having test directories spread all over the place is imo ugly and
> disturbing. I'd rather like to have them collected in one folder or
> repository.

I'd say it's only ugly if you consider tests to be separate to your
"real" development. Should it really be separate?

Cheers
Jason

[Alex Ionescu]

Jason Filby wrote:
> Hi
> > I have to agree with Alex. In my opinion all kind of test code
> > (including regression tests) should stay out of the core implementation
> > tree. Having test directories spread all over the place is imo ugly and
> > disturbing. I'd rather like to have them collected in one folder or
> > repository.
>
> I'd say it's only ugly if you consider tests to be separate to your
> "real" development. Should it really be separate?
>
> Cheers
> Jason
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

Hi,

You have to remember that our CVS is anonymous and there are many 
non-developers (much more then developers) who will be using it and have 
absolutely no interest in downloading tests, and they consider it seperate.

Best regards,
Alex Ionescu

[Steven Edwards]

Hi,

--- Alex Ionescu [e-mail] wrote:
> You have to remember that our CVS is anonymous and there are many 
> non-developers (much more then developers) who will be using it and
> have 
> absolutely no interest in downloading tests, and they consider it
> seperate.

If they are downloading CVS even anon then they are developers and they
should have the tests. Whats worse having quite a few hundred K of
tests that take up space or having a testing system no one uses and is
out of sync? The answer is clear, we must package the tests with the
module in question.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

[Richard Campbell]

Not to mention those poor folks on dialup having to wait hours to 
download source as it is.

Only core files (core being defined as?  maybe what would be included on 
a real NT 4 or 2000 system?) should be in the main ReactOS tree.

Thomas Weidenmueller wrote:
> Filip Navara wrote:
> > I'm personally quite happy with having tests as near as possible to 
> > the respective component. Wine does that for years and it works very 
> > well...
>
> I have to agree with Alex. In my opinion all kind of test code 
> (including regression tests) should stay out of the core 
> implementation tree. Having test directories spread all over the place 
> is imo ugly and disturbing. I'd rather like to have them collected in 
> one folder or repository.
>
> Best Regards,
> Thomas
> _______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://reactos.com:8080/mailman/listinfo/ros-dev

[Steven Edwards]

--- Thomas Weidenmueller [e-mail] wrote:
> I have to agree with Alex. In my opinion all kind of test code 
> (including regression tests) should stay out of the core
> implementation 
> tree. Having test directories spread all over the place is imo ugly
> and 
> disturbing. I'd rather like to have them collected in one folder or 
> repository.

The Wine model has proven that it works and if the tests are written
properly they will not be to large in source or binary form.

Hows this for a solution....Lets get a regression testing suite in
place now using the model most of us like (The Wine Like layout) and
once we really HAVE regression testing in place and people use it, if
it is too big and too many people complain then we can look to moving
it to another module.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Steven Edwards
> Sent: 5. november 2004 00:18
> To: ReactOS Development List
> Subject: Re: [ros-dev] Re: [ros-cvs] CVS Update: reactos
>
> --- Thomas Weidenmueller [e-mail] wrote:
> > I have to agree with Alex. In my opinion all kind of test code 
> > (including regression tests) should stay out of the core 
> > implementation tree. Having test directories spread all
>
> over the place
> > is imo ugly and disturbing. I'd rather like to have them
>
> collected in
> > one folder or repository.
>
> The Wine model has proven that it works and if the tests are 
> written properly they will not be to large in source or binary form.
>
> Hows this for a solution....Lets get a regression testing 
> suite in place now using the model most of us like (The Wine 
> Like layout) and once we really HAVE regression testing in 
> place and people use it, if it is too big and too many people 
> complain then we can look to moving it to another module.
>
> Thanks
> Steven

I think that my second try at a testing framework has progressed
enough for it to actually be usable. I've documented most in
the chapter named "Testing Framework" in:
http://212.242.245.122/ReactOSDevelopmentModel.pdf

There is still room for improvement so let me know how I can make it
better.

Casper

[Aliberti Emanuele]

Hi Casper,
> I think that my second try at a testing framework has progressed
> enough for it to actually be usable. I've documented most in
> the chapter named "Testing Framework" in:
> http://212.242.245.122/ReactOSDevelopmentModel.pdf
>
> There is still room for improvement so let me know how I can make it
> better.

would it be possible to have that document added - in docbook format - 
in the old rosdocs module for everyone here to edit?

To make it collaboratively editable, I also suggest to split it in a 
master document with external sections or chapters (entities or xinclude).

Emanuele

[Steven Edwards]

--- Aliberti Emanuele [e-mail] wrote:
> would it be possible to have that document added - in docbook format
>
> in the old rosdocs module for everyone here to edit?
>
> To make it collaboratively editable, I also suggest to split it in a 
> master document with external sections or chapters (entities or
> xinclude).

Emanuele is right. Its time to bring rosdocs back from the dead. This
is the perfect case for it. We discussed this at LinuxWorld and
everyone seemed to like the idea.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

[Jason Filby]

On Fri, 5 Nov 2004 14:46:01 -0800 (PST), Steven Edwards
[e-mail] >Emanuele is right. Its time to bring
rosdocs back from the dead. This
> is the perfect case for it. We discussed this at LinuxWorld and
> everyone seemed to like the idea.

I don't think that rosdocs is the best approach; a wiki is a better
approach to collaboration online. If I understand Emanuele correctly,
the reason he wanted rosdocs back is because the current Library on
reactos.com doesn't yet support collaboration at all.

Cheers
Jason

[Casper Hornstrup]

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Aliberti Emanuele
> Sent: 5. november 2004 23:18
> To: ReactOS Development List
> Subject: Re: [ros-dev] Testing framework
>
> Hi Casper,
> > I think that my second try at a testing framework has
>
> progressed enough
> > for it to actually be usable. I've documented most in the
>
> chapter named
> > "Testing Framework" in:
> > http://212.242.245.122/ReactOSDevelopmentModel.pdf
> >
> > There is still room for improvement so let me know how I can make it 
> > better.
>
> would it be possible to have that document added - in docbook 
> format - in the old rosdocs module for everyone here to edit?
>
> To make it collaboratively editable, I also suggest to split 
> it in a master document with external sections or chapters 
> (entities or xinclude).
>
> Emanuele

Sure, I'll put it in CVS but can we make it stay in OpenOffice (XML)
format? Since I've started using OpenOffice, I've found that it is much
easier to do it this way compared to writing the documents in DocBook
format. I've never really found a free editor that was easy to use when
editing them so I ended up using a normal text-editor. I just want this
document to be in OpenOffice format. This is so we can have all the
information about developing ReactOS (the tools and the processes) in
one central place. For the techical and more dynamic documentation
(like articles and roadmaps), I'd prefer our WIKI over DocBook since
it is much faster to make changes (which occur often).

Casper

[Jason Filby]

Hi Casper
> This is so we can have all the information about developing ReactOS (the
> tools and the processes) in one central place. For the techical and more
> dynamic documentation (like articles and roadmaps), I'd prefer our WIKI
> over DocBook since it is much faster to make changes (which occur often).

There's no reason not to have documentation on tools and processes in
the wiki. You just might have tighter restrictions on which users can
access those pages (using a namespace). Wikis are great because they
have the collaboration of CVS except you don't have to worry about
publishing the latest version on the web - it's already there.

Cheers
Jason

[Steven Edwards]

Hi Casper,

--- Casper Hornstrup [e-mail] wrote:
> Sure, I'll put it in CVS but can we make it stay in OpenOffice (XML)
> format? Since I've started using OpenOffice, I've found that it is
> much
> easier to do it this way compared to writing the documents in DocBook
> format. I've never really found a free editor that was easy to use
> when
> editing them so I ended up using a normal text-editor. I just want
> this
> document to be in OpenOffice format. This is so we can have all the
> information about developing ReactOS (the tools and the processes) in
> one central place. For the techical and more dynamic documentation
> (like articles and roadmaps), I'd prefer our WIKI over DocBook since
> it is much faster to make changes (which occur often).

I like that idea of using OpenOffice. The nice thing about docbook is
that it makes it easy to generate all of the documentation in to HTML
at once. I dont know how or if you can script OpenOffice to convert
everything to HTML to be published on the web. Can you create a folder
in rosdocs for technical papers in OO format? I will see if there is a
way we can trick xlstproc in to generating HTML versions of the
OpenOffice files when we build the rest of rosdocs.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

[Jason Filby]

> I like that idea of using OpenOffice. The nice thing about docbook is
> that it makes it easy to generate all of the documentation in to HTML
> at once. I dont know how or if you can script OpenOffice to convert
> everything to HTML to be published on the web.

What is the advantage of using OpenOffice files, publishing them to
HTML over the use of a Wiki?

An immediate advantage of the Wiki over such is a system is the ease
of linking between pages. And publishing is instantaneous and easy.

Cheers
Jason

[Steven Edwards]

--- Jason Filby [e-mail] wrote:
> What is the advantage of using OpenOffice files, publishing them to
> HTML over the use of a Wiki?

What I am asking for is a easy way to import to the Wiki rather than
just copy and paste. I can think of two situations where most Wiki
software does not work well.

1. If we want to extract the documentation from the site and ship it
for download and packaging of ReactOS then using a backend format like
the XML markup of the OpenOffice files would make it easy.

2. Not all of our developers have unlimited access to the internet and
some like Eric Kohl have to pay by the minuet for dial up access. Being
able to write the docs offline would help him.
> An immediate advantage of the Wiki over such is a system is the ease
> of linking between pages. And publishing is instantaneous and easy.

I agree and I like the idea of a Wiki. I just would like to have a
system that makes it easy to import the docs we already have or other
external documents and allows for easy export.

Thanks
Steven

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

[Aliberti Emanuele]

Hi Jason
> > I like that idea of using OpenOffice. The nice thing about docbook is
> > that it makes it easy to generate all of the documentation in to HTML
> > at once. I dont know how or if you can script OpenOffice to convert
> > everything to HTML to be published on the web.
>
> What is the advantage of using OpenOffice files, publishing them to
> HTML over the use of a Wiki?
>
> An immediate advantage of the Wiki over such is a system is the ease
> of linking between pages. And publishing is instantaneous and easy.

There are a few notes I add here for further distributed thinking:

1. even if DSL access is currently offered at discount prices (at least 
here in Europe), please don't forget Italy and many other countries 
around the world, where dial-up access is the only option, or the only 
affordable/technical option; wiki is perfect for always-on users; 
eveyone else is most time off-line (me first*);

2. Docbook is an industry standard and using it as is allows easy 
generating many end-user formats (though I don't know if the local 
printing house would accept it raw; they used to accept raw PostScript 
files, a few years ago) at no cost;

3. Docbook can be used as plain 7-bit XML files or stored in a db, and 
switching between the two is possibile without loss of information 
(Exercise: provide an algorithm for storing a tree in an SQL database :);

4. For a really powerful WYSIWYG editor try XXE 2.8 by XMLMind (it's a 
Java application I currently use under Windows and under Linux; standard 
edition is free; professional edition has collaborative functions 
active, but is expensive); another powerful XML editor with team work 
capabilities is the one by Arbortext, but no free edition exist; the 
advantage in using structure-/semantics-oriented editors for writing 
large modular pieces of text is apparent;

5. Under Windows, try GemDoc for generating end-user documents given a 
valid {SGML|XML} Docbook (not perfect); under Linux, usually a full free 
Docbook toolchain is available (browse the Suse 9 user manual and at 
about page 2 you'll read it was generated from a Docbook source);

6. Given the proper XLT transformation, CVS or SVN could contain the 
whole web site, but forums (perhaps); this does not mean I am against 
eZP, I just suggest we could make the eZP engine extract some 
information from a static XML base we can access using CVS/SVN;

7. OO files are XML files (well packed and compressed collections of XML 
files and binary attachments); It seems OO can load simplified Docbook 
files and export to simplified docbook, which is good for short pieces, 
but not for a quite large documentation project like ros.

Emanuele

*) this is just an abscure problem of the telco, I suspect, because I 
live just 10 km (~6 miles) far from the chief town, where the local 
university has a 122 Mbit/s link and 3G/UMTS for live videocalls  is 
available;

[Jason Filby]

Hi Emanuele
> wiki is perfect for always-on users; eveyone else is most time

off-line (me first*);

Yes but I don't think that that's a reason to drop wiki; it's just a
weakness that we'll have to manage around. Local copies can be
obtained - but editing will have to be kept separate until online.
> Docbook is an industry standard and using it as is allows easy
>
> generating many end-user formats (though I don't know if the local
> printing house would accept it raw; they used to accept raw PostScript
> files, a few years ago) at no cost;

There's an extension to generate .pdf files from wiki pages, but
generating a book format - from a first to last page would require
extra effort. This is because a wiki uses a more flexible information
approach: a network model to browse data instead of the hierarchical
model found in books.

Cheers
Jason