Am Mittwoch 10 März 2010 09:36:34 schrieb Martin Paljak:
> On Mar 10, 2010, at 10:07 , Andreas Jellinghaus wrote:
> > to me your emails read like you want to remove/loose/strip down
> > most information. the result might be small and up-to-date, but
> > it is not acceptable from my point of view to loose all the
> > information in the wikis we have already.
>
> A wiki should have self-organizing capabilites to only show relevant
> information in a useful way and so that it could be easily found. There
> can be (and usually is) a lot of "existing but abandoned" information.
"self-organizing capabilities"? lets not play buzzword-bingo.
> Looking at the trac contents of engine_pkcs11 and libp11 - seems to be
> mostly a copypaste.
well, both contain the minimum information needed as software documentation.
lets have a look at the latest tar.gz and the files it contains in doc/
(engine_pkcs11 in this example):
index.html
Project description and links to the other pages and api documentation.
AuthorsAndCredits.html
Copyright information and a place to thank people for helping.
Not up-to-date, some information missing, but has the general info.
MailingLists.html
We need to tell people how to reach us, for example users of packages
in normal linux distributions. This page does that.
PageTemplates.html
Trac seems to have added this page with some new version. We need to
update the wiki2html script to exclude this page.
QuickStart.html
How to compile the software and how to use it.
SubversionRepository.html
Some minimal documentation for developers, how to get started if they
want to improve the code.
trac.css
Required by the html files to render properly.
So I see no fat. This is a minimum of documentation, less would be a big
mistake from my point of view. Of course it looks like the documentation
of each other package, because every package should include such minimal
documentation from my point of view.
> Yet Another Trac Instance won't make it better. It should be a well known
> software myth: "or devs have the latest tools, the greatest utilities,
> fastest machines => they should be kickass" when in fact the kickass tools
> are not used.
what does trac instances have to do with whatever that myth is supposed to
tell me? you lost me.
> I don't believe that a new trac instance (or a bugzilla) would make
> anything better.
sure. it gives us a backup, something working we can use, till we see
the new one works and is ready. that is good.
in fact it would be stupid to remove content from the existing trac instances,
what would we do if you had to stop your work half way for some reason?
we would have neither the old working nor the new stuff, only shards.
and from your comments I'm still not exactly sure what you want to do.
you complain about cut&paste in libp11 and engine_pkcs11 - two very
small wikis with 5 pages in total, with all information essential from
my point of view. if this is the big problem, and you want a radical
change, then I have even more reason to stay back and say: hands off
the existing trac instances, instead show us what you want to do in
a new wiki/trac (or copied from opensc - whatever you prefer).
> OpenSC wiki is overloaded with information that has nothing to do with
> OpenSC. Having more of it can not hurt, especially if it is up to date and
> relevant.
>
> The wiki is not attached to a version. It is live documentation. There is
> no connection between wiki content and a snapshot of it in a versioned
> software tarball, doing it with this understanding would be wrong.
>
> IIRC the reason to bundle wiki docs in the tarball was that there are users
> without live internet connection. Whatever gets in the "offline wiki dump"
> for these people is better than nothing.
well, a software in .tar.gz form should include a copyright file, instructions
how to compile it and use the software, where to report bugs, and all that.
sorry if I'm old-fashioned, but I think it should be that way.
> The goal is to actually track tickets, not to have a a gazillion of bug
> tracking software instances. Whatever tool that works is better than
> nothing or better than a bunch of tools not being used. OpenSC trac has a
> lot of tickets that represent *something*
so if people file a ticket in "opensc" trac for "libp11" component,
with a bogus version, as they cannot select the libp11 versoin, that
will be easier than doing the same thing in the "libp11" trac?
sorry, but I think your changes - adding the other projects as
components inside opensc wiki - will cause a lot of more confusion
and not help at all. so please revert.
neither wikis nor control-version-systems nor having root on opensc-
project.org is a replacement for developer communication. if people
tell me I'm wrong we can follow your plan, but please lets discuss
such changes first, and not simply do things. in a wiki a changed
page can be reverted, but reconfiguring opensc ticket system is a
much more invasive change, and should be discussed first.
> Move was the wrong word. I meant copy.
ah, ok.
so what is your plan for the other project? I still think each
project needs to have some minimal user/developer documentation
shipped with them in the tar.gz, so it is available in the distributions.
do you agree? how should that documentation be written and maintained,
if you implement your plan with the new trac/wiki? I proposed docbook
(or some other format) with source code of the documentation inside
the svn, but I don't remember you commenting on that.
> Where does b...@opensc-project.org go? How many e-mails has it received?
bugs: aj,nils
I can add more people. maybe one email in three months.
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
