> <mailto:
daniel@xxxxxxxxxxxxx>> wrote:
>
>
> I'm keen to see some packages happen within the next 6 months so
> that
> they will appear in the next releases of the major Linux
> distributions
> (e.g. the next Debian, Fedora and Ubuntu)
>
> I think this is actually critical for the future of the project,
> because
> it means more people will link their apps to resiprocate, then
> they will
> feed stuff back into the project, and things will snowball from
> there
>
> It is a chicken-and-egg problem: which came first? I understand
> there
> was previous concern about using autotools because no one is an
> expert
> on the subject. If we had autotools, however, then we will get more
> help from packaging experts familiar with autotools, because
> everything
> will be familiar to them. I'm willing to make the effort to get the
> project into that position.
>
> What I propose is that we take my autotools branch and proceed
> like so:
>
> a) prove that it builds with autotools on UNIX and that the Visual
> Studio on Windows build is not negatively impacted in any way (done,
> although a couple of the configure options are not implemented yet)
>
> b) prove that it runs all test cases (currently only one of them is
> built and executed, not hard to copy and paste for the others)
>
> c) prove that it meets the requirements for Debian, Fedora and
> OpenCSW -
> e.g. Debian raised questions about SONAME and ABI, this is
> documented in
> some old threads
>
http://lists.debian.org/debian-mentors/2009/07/msg00130.html
>
> d) prepare documentation showing
> - old build commands and their equivalent with the new system
> - steps to make release and build packages
> - other useful autotools features that relate to this project
>
> e) merge all recent work from trunk into my autotools branch
>
> f) repeat tests (a), (b) and (c)
>
> g) merge the branch into trunk - completely replace the old
> configure
> script and Makefile system for UNIX
>
> h) make a reSIProcate 2.0 release candidate (I think it is good
> to jump
> to a new version number because of the SONAME and ABI stuff, it
> makes it
> more obvious that there is a new approach)
>
> i) packages go into Debian unstable and OpenCSW catalog
>
> In parallel, we could potentially be doing all this with git,
> running a
> parallel repository (for testing git) up to step (g), and then
> replacing
> SVN. I've already been using git-svn as my local workspace, so I'm
> confident that we can introduce git in such a way.
>
> I'm happy to push ahead with these things but I really need to
> know that
> nobody has major objections or alternative proposals
>
> To see it all on a smaller scale, I would be using almost the same
> approach that I've used with other software:
>
>
https://sourceforge.net/projects/gmod-linux/
>
>
https://sourceforge.net/projects/gmod-solaris/
>
> The timescale for this would be about 2-3 months, to ensure
> people have
> time to check things at each stage and object at any step if
> something
> surprises them
>
>
>
> _______________________________________________
> resiprocate-devel mailing list
>
resiprocate-devel@xxxxxxxxxxxxxxx