Re: DOM and SAX parsing in Ada

From: Stephen Leake (stephen_leake_at_acm.org)
Date: 01/28/05


Date: 28 Jan 2005 04:57:12 -0500
To: comp.lang.ada@ada-france.org

Pascal Obry <pascal@obry.org> writes:

> Martin Krischik <martin@krischik.com> writes:
>
> > So I would be in for a XML/Ada extension pack hostet at i.E. SourceForge.
>
> That's a very bad idea to me.

Some of us agree, but you have not addressed the issue that, for
XML/Ada at least, contributions are not available in a timely way.

> Better to have one strong Ada tools that zillions of
> not-well-supported forked ones. It is fine to have another project
> to build an XML parser in Ada but for me a fork is really bad and
> should happen only if there is *big* maintenance problem.

Waiting a year for a contribution to be generally available counts as
a "big" problem for me.

> One good point on the Ada side is the strong standard. We really
> want to build on this. Not a lot of libraries but some good, well
> documented, safe ones that does the job.

We all agree with that.

> Personally I would not like to find an AWS fork. I've tried (and
> will continue to) to work with the contributors to have patches
> integrated. But it is true that patches are not always very easy to
> integrate and requires some changes.

We all agree with that as well.

> Note that I know well the main XML/Ada maintainer and can tell you
> that if a patch is not integrated yet there is certainly good
> reasons.

The issue is, after a patch is integrated, how long is it before it is
available to others?

> Another note. In this thread one guy (can't remember who sorry) talked about
> CVS write access.

That was me; it appeared to be an issue for Nick Roberts.

> This is not serious.

I'm not clear what you mean here; I was certainly "serious".

> To have a write access to a project you really want to become part
> of the project team, take responsibilities for part of it... and of
> course you can't keep the copyright, this would be a problem for the
> product in the long term.

Ok, so you mean "it is not reasonable to grant write access to
everyone who makes a contribution". That's fine.

However, it is necessary for _everyone_ to have read access to a CVS
repository, if you want to encourage comtributions to that repository.

-- 
-- Stephe


Relevant Pages

  • Re: how to handling read only cvs trees
    ... > I usually checkout out src from a local cvs mirror of the FreeBSD ... > these files are included in the generated patch. ... > repository, could delete them with the next scheduled run. ... Either pack the files up in a shar or tarball or use diff -N against ...
    (freebsd-hackers)
  • how to handling read only cvs trees
    ... I currently working to get an old patch up to HEAD, ... I usually checkout out src from a local cvs mirror of the FreeBSD ... repository, could delete them with the next scheduled run. ...
    (freebsd-hackers)
  • Another experimental patch: quickhell
    ... An ALPHA-level patch without documentation or standards adherence. ... for reasons that will become clear. ... Qrzbtbetna vf abj n thnenagrrq zbafgre, ...
    (rec.games.roguelike.nethack)
  • Re: cvs question
    ... I did a cvsup on www & ... you can use anon cvs and something like: ... % setenv CVSROOT:pserver:freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs ... CVSROOT is where the repository resides. ...
    (freebsd-questions)
  • Re: Nautilus Absturz
    ... verschwindet der Desktop und kommt nach einer Weile ... nicht unbedingt den CVS code, ... Die Quellen zum kompilieren bekommen und Dev-Header sind dank Gentoo ... Auch den Bug zu finden und einen Patch zu ...
    (de.comp.os.unix.apps.gnome)