Support for build2, migration to git, etc

[Boris Kolpackov <bo...@codesynthesis.com>]

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 doing this (and provided there is support in the first place,
of course), I would really like to migrate the project from svn to
git (hopefully with the help of Apache Infra). Last time this came
up, I don't believe there were any strong opposition to such a
switch.

I would like to put these two points to a vote but before doing so
I thought I would check what the sentiment is.

Finally, seeing that we are on the topic of migration and switching,
the question of the overall viability as the Apache project has come
up recently and some mentioned that they have considered forking the
project and hosting the fork in a less "structured" setting (e.g.,
GitHub). So maybe it makes sense to consider/discuss this possibility
as well (perhaps it could be a "move" rather than a fork if Apache is
no longer interested in the project).

What do you think?

[1] https://build2.org/
[2] https://ci.cppget.org/
[3] https://ci.cppget.org/?build-configs

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Support for build2, migration to git, etc

[Boris Kolpackov <bo...@codesynthesis.com>]

Roger Leigh <rl...@codelibre.net> 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 worth the cost for supporting three build
> systems?

Continuous CI would be the major benefit. And I am committing to absorbing
the costs by maintaining it (also see below).


> Maintaining two with exact feature parity and behaviours is already a
> maintenance burden.  I think three is too many, and would recommend we
> drop one if we are going to support a new one.  And I think that would
> have to be the autotools build.

I would prefer not to make support for build2 conditional on dropping
support for autotools (but we can vote on this separately if you would
like). As I mentioned above, we are prepared to do all the maintenance.
In fact, bared some major restructuring, I don't expect there to be any.
In particular, addition/removal/renaming of source code will be picked
up automatically. Upon release, the version will need to be changed in
one place but I am prepared to handle that as well.


> Regarding the CI side, can it integrate with Apache's github repo like we
> have already for Travis and AppVeyor?

build2 CI is a bit different in that it is "push" rather than "pull".
That is, you normally develop something in a branch, then CI it, if
all looks good, merge to master and then maybe CI master, for good
measure.

This is not to say that we can't also trigger it from a post-commit
hook or some such.


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Support for build2, migration to git, etc

[Roger Leigh <rl...@codelibre.net>]

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 maintaining this
> support going forward.
> 
> Before doing this (and provided there is support in the first place,
> of course), I would really like to migrate the project from svn to
> git (hopefully with the help of Apache Infra). Last time this came
> up, I don't believe there were any strong opposition to such a
> switch.
> 
> I would like to put these two points to a vote but before doing so
> I thought I would check what the sentiment is.

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.

Regarding build2, are there sufficient benefits over the existing 
autotools and cmake build to make it worth the cost for supporting three 
build systems?  Maintaining two with exact feature parity and behaviours 
is already a maintenance burden.  I think three is too many, and would 
recommend we drop one if we are going to support a new one.  And I think 
that would have to be the autotools build.

Regarding the CI side, can it integrate with Apache's github repo like 
we have already for Travis and AppVeyor?


Kind regards,
Roger

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Support for build2, migration to git, etc

[Boris Kolpackov <bo...@codesynthesis.com>]

Cantor, Scott <ca...@osu.edu> 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 links, etc.

Agree.


> Apache's security process is definitely a source of problems for me, it
> demands too much effort and is one of the reasons I tend to look for reasons
> not to do them. I don't believe in doing the work of downstream packagers as
> a precondition for doing fixes, and their process leans too far in that
> direction.

Ok, didn't know that.


> I just believe in transparency so everybody knows the situation.

Yes, I agree we should make it clear if/when things are insecure.
And I think it is also perfectly reasonable to switch to "disabled
by default" for functionality (such as DTD) which has known security
issues but which we cannot fix (for whatever reasons).


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Support for build2, migration to git, etc

["Cantor, Scott" <ca...@osu.edu>]

On 3/24/19, 9:27 AM, "Boris Kolpackov" <bo...@codesynthesis.com> 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.

> Well, my motivation for forking would be to continue maintaining the
> project for general use but with less "friction".

It may be useful to unpack that a bit. 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 links, etc.

Apache's security process is definitely a source of problems for me, it demands too much effort and is one of the reasons I tend to look for reasons not to do them. I don't believe in doing the work of downstream packagers as a precondition for doing fixes, and their process leans too far in that direction. So that would be a win, certainly.
 
> I also think you are over-burdening yourself with responsibility:
> yes, security issues are bad news but in the end the license clearly
> states that things come as-is and without any warranty.

I definitely have a different perspective on that. I don't think the code should be in the open and under an Apache banner if that's the level of support it has. I think the ASF would rightly view that as a justification for terminating the active project. It's important that projects not receiving active maintenance be documented that way. If that applies to specific parts of the code base, then that's also a useful qualifier.

I just believe in transparency so everybody knows the situation.

> We have a product (CodeSynthesis XSD) that depends on it so we are
> planning to use and maintain it going forward. At the same time we
> view it as a mature (if not legacy) codebase so we have no plans to
> add any new features, etc. I am, however, not sure whether Apache is
> interested in a project like this.

They don't handle it especially well culturally, but I think they are correct in recognizing that just because it's in maintenance mode doesn't mean bug reports, and especially security reports, should get ignored, whether due to resources or simple lack of ability to fix the code due to unfamiliarity.

-- Scott

Re: Support for build2, migration to git, etc

[Boris Kolpackov <bo...@codesynthesis.com>]

Cantor, Scott <ca...@osu.edu> 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 offering to maintain it.

Yes, it will be purely additive and I am committing to maintaining
it.


> FWIW, GitHub's terms of use are impossible for me to accept for
> any active development work due to their indemnification clause.

I used GitHub as an example. I am happy with any similar service
(e.g., GitLab).


> If I were to fork, it would only be in the interest of ensuring that
> nobody else used the code under the impression it were being maintained
> for general use, and to ensure that the library naming wouldn't conflict
> with any other packaging.

Well, my motivation for forking would be to continue maintaining the
project for general use but with less "friction".

I also think you are over-burdening yourself with responsibility:
yes, security issues are bad news but in the end the license clearly
states that things come as-is and without any warranty.


> But fundamentally, the issue is viability.

We have a product (CodeSynthesis XSD) that depends on it so we are
planning to use and maintain it going forward. At the same time we
view it as a mature (if not legacy) codebase so we have no plans to
add any new features, etc. I am, however, not sure whether Apache is
interested in a project like this.

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Support for build2, migration to git, etc

["Cantor, Scott" <ca...@osu.edu>]

On 3/23/19, 11:30 AM, "Boris Kolpackov" <bo...@codesynthesis.com> 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 project, obviously).

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 offering to maintain it. I can't see anything happening any time soon that would be so disruptive to the code as to break that support.

> Finally, seeing that we are on the topic of migration and switching,
> the question of the overall viability as the Apache project has come
> up recently and some mentioned that they have considered forking the
> project and hosting the fork in a less "structured" setting (e.g.,
> GitHub).

FWIW, GitHub's terms of use are impossible for me to accept for any active development work due to their indemnification clause. I literally work on a project that IBM tried to sue over IPR rights once, so it's not a theoretical consideration for me.
 
If I were to fork, it would only be in the interest of ensuring that nobody else used the code under the impression it were being maintained for general use, and to ensure that the library naming wouldn't conflict with any other packaging. Red Hat, for example, packaged 3.1 on RHEL7 but then never bothered to maintain it or apply security fixes, which screwed over my project nicely. Getting 3.2 out allowed me to avoid that soname conflict, but I do fear them (or others with similar lack of diligence) repeating that again with 3.2, so it's a race to stay ahead of it right now.
 
But fundamentally, the issue is viability. If people think the project is viable (which to me means security issues across the code base are actually going to get dealt with promptly), then venue is really a political and process conversation more than anything. But if it's not, I think encouraging people to fork and rename it is a responsible choice.

-- Scott