On 7/16/19, 4:51 AM, "Boris Kolpackov" wrote:
> Ok, I've got the ball rolling on this, sorry for the delay:
Thank you.
-- Scott
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail:
Ok, I've got the ball rolling on this, sorry for the delay:
https://issues.apache.org/jira/browse/INFRA-18755
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail:
> I think I now understand what's going on: the xerces/c/web/ repository is no
> longer used at all. Instead, it's all (including the generated Doxygen
> documentation) in xerces/site/trunk/production/xerces-c/.
Ah, sorry, I missed the distinction and was just seeing what my brain expected.
> I
Cantor, Scott writes:
> On 5/13/19, 9:23 AM, "Boris Kolpackov" wrote:
>
> > I also think we can drop any mentinoning of 2-series during this
> > conversion. There are, however, other bits of the documentation
> > (like Doxygen-generated). Here is step #15 that I mentioned:
>
> That's not in
On 5/13/19, 9:23 AM, "Boris Kolpackov" wrote:
> I also think we can drop any mentinoning of 2-series during this
> conversion. There are, however, other bits of the documentation
> (like Doxygen-generated). Here is step #15 that I mentioned:
That's not in the current readme I checked in for
Roger Leigh writes:
> Mentioned briefly a few months back, but we could take the Git migration as
> an opportunity to convert the old StyleBook XML to Markdown and move the
> docs to github pages, generated directly from git automatically.
I assume the "github pages"
On 5/10/19, 7:17 PM, "Roger Leigh" wrote:
> I would certainly be happy to do the conversion, if there was consensus for
> doing so.
I'm certainly in favor.
-- Scott
I suggest that we convert it to Git now and decide
what extra steps, if any, are required later.
We can, I'm just saying the site is then impossible to update until something
else is done.
Mentioned briefly a few months back, but we could take the Git migration
as an opportunity to conve
On 5/10/19, 8:15 AM, "Boris Kolpackov" wrote:
> Hm, looking at admin/release-procedure.txt, step 15 in particular,
> suggest that it's at least not the whole process.
There is no step 15, so you're looking at old notes I think.
> In any case, I suggest that we convert it to Git now and decide
Cantor, Scott writes:
> On 4/29/19, 10:34 AM, "Boris Kolpackov" wrote:
>
> > The latter two are direct copies from the web/ and admin/ SVN directories.
>
> I believe that the web/ repository is actually directly published as
> the web site, so there probably is additional work to do to change
Roger Leigh writes:
> > xerces-cxx.git
> > xerces-cxx-web.git
> > xerces-cxx-admin.git
>
> Do we need "-cxx" as a suffix here, or would "-c" be better?
Yes, good point. Our source distributions are called xerces-c, binary
packages seem to also be called like that (e.g., Debian's, libxerces-c).
On 29/04/2019 15:34, Boris Kolpackov wrote:
The vote to migrate the Xerces-C++ repository from SVN to Git has
passed and I would like to discuss the next step.
Sorry for the delay in replying; I've been away on holiday for the last
week.
As well as through the Xerces-C++ SVN repository to
On 4/29/19, 10:34 AM, "Boris Kolpackov" wrote:
> The latter two are direct copies from the web/ and admin/ SVN directories.
I believe that the web/ repository is actually directly published as the web
site, so there probably is additional work to do to change how that's
happening. I don't
The vote to migrate the Xerces-C++ repository from SVN to Git has
passed and I would like to discuss the next step.
According to https://gitbox.apache.org, this should be as easy
as opening and issue with the Apache Infra. Before doing this,
however, it would be good to agree on the desired
Cantor, Scott writes:
> Practically speaking, the security process and the web site have been the
> main sources of friction for me, and I think the latter is definitely a
> choice. We could simply accept that it's not viable and shut it down in
> favor of a simple wiki page with the download
Roger Leigh writes:
> I'm doing all my work in git using the git mirror anyway,, so I would be
> more than happy to use git for the main repository. It's much more
> efficient.
Great!
> Regarding build2, are there sufficient benefits over the existing autotools
> and cmake build to make it
On 3/24/19, 9:27 AM, "Boris Kolpackov" wrote:
> I used GitHub as an example. I am happy with any similar service(e.g.,
> GitLab).
I think most/all of them have similar terms. I get their perspective, it's
free, so they have to protect themselves, but I can't afford indemnification
insurance.
On 23/03/2019 15:30, Boris Kolpackov wrote:
I would like to add support for the build2[1] build system, similar
to how it was done recently for CMake. One of the benefits will be
continuous building and testing[2] on a wide range of platforms and
compilers[3] (currently 33). I am committing to
Cantor, Scott writes:
> No concerns with git, if that's something Apache allows as the
> "official" repo now [...]
I would sure hope so.
> My only concern with the build system is that I need the autoconf
> support so as long as that's not going anywhere, anything else is
> up to the people
On 3/23/19, 11:30 AM, "Boris Kolpackov" wrote:
> I would like to put these two points to a vote but before doing so
> I thought I would check what the sentiment is.
No concerns with git, if that's something Apache allows as the "official" repo
now (subject to it actually being an Apache
I would like to add support for the build2[1] build system, similar
to how it was done recently for CMake. One of the benefits will be
continuous building and testing[2] on a wide range of platforms and
compilers[3] (currently 33). I am committing to maintaining this
support going forward.
Before
21 matches
Mail list logo
