Open GoogleCodeExporter opened 9 years ago
Where you able to contact someone or did you fork?
Original comment by ja...@theallens.id.au
on 8 Jan 2015 at 1:03
I did see you forked already.
It seems that more than you tries to fix some stuff... maybe we should
somewhere merge all fixes together.
If you search for shellinabox on github, you can find some projects that did at
least some small fixes.
To avoid growing all the dedicated clones without any link, forking the github
project with the most forks would make sense to me. Then adapt all your changes
there.
I can start over with that, but the problem is, I'm not into coding C what
should be a requirement for the new maintainer in my eyes.
I started to create a dockerfile for a container with some options to deploy it
fast with some of the most scenarios.. like acting as ssh gateway to the docker
host or just as a "dummy" linux box. Thats what I would like to contribute then
for the project.
Original comment by sp...@spali.ch
on 26 Feb 2015 at 12:44
sorry for being bit off-topic, but someone that is interested I the future
maintenance could have some interest in it. I made a Dockerfile with some
options. Good for testing and also to have a fast up and running shellinabox.
https://github.com/spali/docker-shellinabox
still need some work, especially ssl does not work for now, but it works and
for ssl currently a reverse proxy could be used.
Original comment by sp...@spali.ch
on 26 Feb 2015 at 7:54
Hi,
I am also interested in doing something like that ...
Problem is that alot of Github forks are almost dead. We should create new fork
and we should allow more people to manage this project so the project would not
be dependent on only one developer.
Probably it would be the best to create new fork on Github from here and merge
all
existing fixes. So that we won't break project history and all issues will be
traceble ...
Personaly I have a intentions to integrate shellinabox in my own project so I
have
some time for this during my work hours :)
I have some C knowledge, and I also created some forks on github but I will
probably
delete them, because they don't have proper project history.
https://github.com/KLuka/shellinabox
https://github.com/KLuka/shellinabox_fork/
Please tell me what do you think about this idea and if you would be willing to
collaborate with me?
Bye :)
Original comment by luka.kra...@gmail.com
on 27 Feb 2015 at 3:07
I would suggest to just create a non personal git hub repo. Then import the
complete svn history. Also i would recommend to import the issues to and sort
it then out later for dublicates etc.
Don't know about the ethics about how to overtake this project. Is a rename
required or something else? It's really a bummer we can't get any contact to
the original developer. Would be much cleaner to have a message here which
redirects to the new github project. Also to prevent new issues here and to
avoid confusions.
Is there any possibility to contact the owner via Google?
Am 27. Februar 2015 16:07:49 MEZ, schrieb shellinabox@googlecode.com:
Original comment by sp...@spali.ch
on 27 Feb 2015 at 9:10
just found some additional information..
I knew already, there is a debian package which has last changes in the
changelog also at 2012: https://packages.qa.debian.org/s/shellinabox.html
But in the change log, there are some mail changes visible of mark singer (not
sure if he is also the project owner here, but maybe he knows something).
There is also a domain referred as homepage, which redirects to this google
code project. But maybe the owner has also some information or could help.
Another thing we have to bear in mind, on google code there are also some forks
(2 with commits) which should be considered, not only the github forks.
So this would give maybe a bit more work, because I think without a clean
takeover, tje project runs a risk of getting under the hood with all these
distributed forks around there and fixes there and here.
for the issues there seems to be a some reasonable ways, on
http://beets.radbox.org/blog/github-issues.html is a good blog with a issue
converter hosted on github and here is another converter
https://code.google.com/p/support-tools/wiki/IssueExporterTool.
Original comment by sp...@spali.ch
on 27 Feb 2015 at 9:56
Maybe also interesting: https://code.google.com/p/support/wiki/FAQ
read the question:
What should I do if I wish to take over a project that appears abandoned by its
owners?
Sorry for spamming you guys here :) but I really hope this project can
resurrect. But now I have to take my flight to holiday... don't worry, I try to
keep me up to date with this issue :)
Original comment by sp...@spali.ch
on 27 Feb 2015 at 10:20
Hi,
it's nice to see that someone is spamming this thread :)
And it really is a shame that we can't contact project owners :/
So, for now I have created "shellinabox" organization with "shellinabox" project
on Github and I will add anyone from this thread who wishes to be repository
maintainer.
https://github.com/shellinabox/shellinabox
@spali: your Github account was already invited to organization, hope that is
OK :)
It is also important that this new repository will be visible and will show up
on
searches. So that people who are looking for latest updates and issues will find
it easily.
From legal point of view I think that this is not a problem. If anyone thinks
otherwise or has some other problems please tell me/us. If this really is a
problem
we could delete this fork. Although I don't think that this fork/organisation
is any
different from other github forks ...
So in this week I will try to import some stable code with complete history. I
will
also try to import issues from here as you suggested.
Do you have any suggestions on which fork do we want to use for our starting
point?
After that we will try to gather all existing patches and so on ... :)
Have a nice vacation ;)
Original comment by luka.kra...@gmail.com
on 2 Mar 2015 at 8:00
Thats great, still would suggest to try to contact the owner or maybe the
debian package maintainer.
I think at least a reference from here to the github organization would be
great, also the package maintainer of the debian package would switch to the
new project.
As a starting point, I would suggest the original repo and try to merge as many
as possible fixes around the forks. Maybe as branches in the new repo to sort
them out later or to associate them to an existing issue.
I would also suggest to use any of the free build CI's aut there so we can
automatically build all push requests before it will be integrated into the
master. I know some, but don't know which are preferred for C applications.
As soon as I have a good starting version of the docker project, I can move it
to the new organization.
Original comment by sp...@spali.ch
on 2 Mar 2015 at 8:28
Hi :)
clone of this repository was created
(https://github.com/shellinabox/shellinabox) and I started
to import issues...
Just for info I used google-code-issues-migrator, and it is actually pretty
simple :) You just have
to take it slow because github has a limit for spamming issues :)
https://github.com/arthur-debert/google-code-issues-migrator
I will contact the project owner and Debian package maintainer and let them
know what are
we doing here and to give us any thoughts on this :). Also I will try to
contact Google Code
staff to see if they can at least put up a link to Github project on the front
page or something
like that ...
As for the CI ... I don't have any experience with this kind of stuff :) I will
check it out but I
need some more time. It would be great if you would have some time and setup
something at least for
the start.
But for now I think that it is safe to start applying existing patches from
here which are already
tested. So that will be my next step :)
Regards, Luka
Original comment by luka.kra...@gmail.com
on 3 Mar 2015 at 12:26
Thats fine, i will check it out and try to setup something. Just can't promise
anything during holiday, my wife won't be amused :)
Beside of this you should think about how you plan to develop. I would suggest
at least to develop always in a own fork, and do pull requests to the project
repo. So the project repo keeps as clean as possible. Optional we can push to a
dev branch for build tests and then after successful builds we merge to the
master. What do you think?
Also we should write this down on the wiki for other interested developers.
How ever you decide to develop and branch, just do it manually for now, and I
will check later for the build automation.
Original comment by sp...@spali.ch
on 3 Mar 2015 at 2:48
We should also at least tag the release 2.14 used by the current debian
package. But there we have to find out the codebase first.
Hope you can get the debian packager to our project, so we don't have to start
from scratch with that.
Original comment by sp...@spali.ch
on 3 Mar 2015 at 2:57
Hi,
yeah I was thinking the same about the 2.14 tag :) I think that this fork was
used: https://github.com/pythonanywhere/shellinabox_fork/. But I am not so sure,
I have to check.
And as you say I will use my own fork to develop on this project and than we can
use dev branch for test builds. I have to tell you that I am quite new to open
source and github, so I really appreciate your advice, thanks :)
Enjoy on your holiday, and don't worry about this project, it can wait :)
Original comment by luka.kra...@gmail.com
on 3 Mar 2015 at 3:21
Hi, just a little update on https://github.com/shellinabox/shellinabox :)
1. Version 2.14 was tagged so now we are working on version 2.15 :)
2. I contacted original author of this project and debian package maintainer.
This was 5 days ago and they still didn't respond. I hope that they will respond
soon. But until then I think we should continue to work on our github fork so
that they can latter merge our changes here. Or whatever they will decided to
do.
3. I applied many patches from issue threads, not all, but i think it is a good
start.
As far I could tell, from reported issues here, that there are a lot of them
related
to Firefox keyboard problems. I hope I finally applied correct patch :)
I would really appreciate, if someone could test and report back with some other
keyboards. I tested German, Danish and Slovenian keyboards. For reference one
could
use terminal from project front page :)
4. I am trying to sort out imported issues. Because there are a lot of
duplicates and
some of issues are not valid or obsolete. I doesn't look good, if there are too
many
open issues on project :)
Ok, that is it for now :)
Original comment by luka.kra...@gmail.com
on 9 Mar 2015 at 8:40
Original issue reported on code.google.com by
qbradq@gmail.com
on 19 Aug 2014 at 11:50