Hi,
my concern is not the ultimate responsibility because if we get more and
more sub-projects then
I would NOT like to be responsible for the merges. I would prefer if the
responsibilities are agreed
beforehand and then every contributor would have, say, her subdirectory
and with it also the
responsibility in terms of maintenance and documentation for that
subdirectory.
As a GNU maintainer I would also think that the sources should be hosted
by the GNU project in the
first place, and that the GNU policies should be followed. I would also
like to mention that so far
GNU savannah worked very well for me and that the guys behind it are
very responsive when it
comes to problems. And many current GNU APL users follow the main GNU
APL SVN - why should we
change that?
That does not prevent a local repository for development. I have my own
local SVN (the 6000+ numbers
on the GNU APL welcome screen are my local SVN numbers). A commit to the
remote GNU APL SVN
repository is only made after a local build, debian packaging, and RPM
packaging has succeeded (see
make EXPO on top-level), I believe we should do something similar for
the sub-projects.
/// Jürgen
On 04/13/2014 04:56 PM, Elias Mårtenson wrote:
Another option would be to use a distributed VC like Mercurial or Git.
Then you'd still be ultimately responsible for all merges into
mainline, with contributors being able to work on off-site branches.
Regards,
Elias
On 13 Apr 2014 22:52, "Juergen Sauermann"
<juergen.sauerm...@t-online.de <mailto:juergen.sauerm...@t-online.de>>
wrote:
Hi Elias,
yes, you have a point there. My first guess would be GNU savannah
where
GNU APL lives. We would have to figure a few things like how to
change SVN permissions,
paperwork for contributors (as per
http://www.gnu.org/prep/maintain/maintain.html) and so
on, but that is doable.
Another point is packaging and testing if all works together.
Normally I test the core GNU APL automatically
before committing into the SVN at savannah. Something similar
should happen for those sub-projects that we
see as essential; we can be a bit more relaxed for demo projects.
/// Jürgen
On 04/13/2014 03:55 PM, Elias Mårtenson wrote:
There are now a few separate side-projects that all depend on and
integrate with GNU APL:
* Emacs mode
* Thomas' javascript port
* SQL API
* Possible Android port?
These ports are spread over different source repositories (I'm
not even sure where I can find the javascript port) it's getting
a bit messy, and I can only imagine the pain if Jürgen decides to
actually integrate this port into the mainline.
As for myself, keeping my github-based repository in sync with
the mainline is manageable, but not as smooth as it could be.
Because of this, would it make sense to migrate the repository to
a distributed system? I personally don't care which one, but
being able to work with the same repository as Jürgen would be
very nice.
Regards,
Elias
