Willing to Take Over Maintenance

[GoogleCodeExporter]

I would like to assist with or take over maintenance of this project. 
Shellinabox is by far the easiest to administer and use browser-based shell in 
my opinion, and I see from the commits in the issue log that many others still 
find it valuable as well.

I have been working on the issues and feature requests that are important to me 
personally. Now I would like to start supporting the project for everyone else 
that finds it useful.

Unfortunately all project members have hidden email addresses and the project 
email group is locked, so this is the only way I have of potentially contacting 
the project owner. I would like to commit here, but if that cannot be worked 
out I will take a fork.

Thank you.

Original issue reported on code.google.com by qbradq@gmail.com on 19 Aug 2014 at 11:50

[GoogleCodeExporter]

Where you able to contact someone or did you fork?

Original comment by ja...@theallens.id.au on 8 Jan 2015 at 1:03

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Hi,

For Debian packaging, the official procedure is to contact the
MIA Team https://wiki.debian.org/Teams/MIA

> Hope you can get the debian packager to our project,
> so we don't have to start from scratch with that.

[start from scratch]
That doesn't work that way, as long as you reference previous packager in
debian/copyright; one can take over anyone else.

Original comment by alexandr...@gmail.com on 13 May 2015 at 7:42

[GoogleCodeExporter]

Hi Alexandre, and first of all thanks for the help on the new GitHub fork :)

Original owner of this project still didn't respond to my emails. But I 
actually exchanged some emails with Debian package maintainer Marc Singer. We 
discussed about releasing new version of deb package. Unfortunately he went of 
the grid and I didn't hear anything from him in two months.

It would be really great if we could get new Debian release out as soon as 
possible.

This are the major issues that are already fixed:
* Firefox international keyboard issues - this one is really urgent :) - 
https://bugs.launchpad.net/ubuntu/+source/shellinabox
* SSL patches - also urgent :)
* MAC users keyboard issue
* IE11 issue
* iPad issues
* 256 color support

I see that you have experience with Debian stuff :) What do you think that we 
should do?

Original comment by luka.kra...@gmail.com on 14 May 2015 at 2:25

[GoogleCodeExporter]

I've received an answer from Marc Singer yesterday.
In short: "I'm happy to push it into the repo." :-)

I had created this meta-bug to coordinate 2.15 release in a public way,
you can year the full thread there:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785181

BTW, a line stating " * Closing release coordination metabug (Closes: #785181 
)" should be the added but this is some very low priority stuff not worth a PR 
on it's own. This would close the bug when the new package enters the archive.

> as soon as possible.

I agree, new features like a systemd .service files are not a priority and can 
wait till a next release.

> experience with Debian stuff

well I'm not a Debian Developer nor Debian Maintainer yet, so for my self-made 
package and the one I "adopted" after it was "orphaned" I need that some D.D. 
"sponsor" (verify) my upload; if shellinabox wasn't already in the archive you 
could go through the same way yourself.

But as SiaB is already in the archive there are 3 scenarios possible:
- either Marc upload it, that's the easiest & best solution !

- either if he *weren't* interrested anymore, he could orphan it; then either 
you or I could adopt it and request a sponsor

- if there *were* no response at all, we'd need to convince some D.D. to upload 
it;
this is called a "Non-Maintainer upload"; here as this is a SSL-using package 
with a latent security risk this would have been probably ok; but for other 
packages this could have been seen as an agressive hijacking...

Having many users helps also getting thing fixed and finding a sponsor:
https://qa.debian.org/popcon-graph.php?packages=shellinabox (+199 for Ubuntu)

Original comment by alexandr...@gmail.com on 14 May 2015 at 5:28