Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fork Consolidation #231

Open
urban-1 opened this issue Sep 10, 2017 · 0 comments
Open

Fork Consolidation #231

urban-1 opened this issue Sep 10, 2017 · 0 comments

Comments

@urban-1
Copy link

urban-1 commented Sep 10, 2017

Hi all

I think we should consolidate forks. New features and fixes are lately being added by various people on separate forks but they do not get merged on time or consistently. As a results we end up with duplication of work/fixes and most importantly with multiple packages on atom.io. I believe this is very confusing for end-users and could be easily avoided.

The majority of forks belong to two developement branches/streams. These are starting from @sveale 1.8.24 and have resulted in the following "major" versions (different packages on atom.io)

  • @sveale 1.9.0:
    The original development stream that lately only has minor fixes
  • @duxet 3.1.0:
    This branch has @duxet's and my features and extensions from last year. These are mainly around create file/folder, cut/paste, delete and sftp handler ... handling :)
  • @newinnovations 2.1.0:
    adding keyboard shortcuts, fixes for atom 1.19 and renaming the package
  • @urban-1 devel:
    My latest and greatly buggy probably version adding a tree-view like on top of the remote folder view... (it is not released yet but it is the reason I am raising this issue)

Merging these branches should be fairly straight forward, however, due to the fact that the package name is being used in the atom settings the above branches have three different names (remote-edit, remote-edit2, remote-edit-ni). I propose the following:

  • @sveale : If you want to maintain the original repo, that would be ideal! I would suggest tho that you add the most active users (the ones above) as collaborators so we can merge, manage versioning/releases and close issues. I understand that time is limited (that goes for us too) so the more the merrier in that sense (make the project responsive)

  • @duxet / @newinnovations: If @sveale prefers to keep the official repo clean and not add new features, I suggest that we do the same on @duxet's repo and be added as collaborators

My only concern is releasing on atom.io - I have never done that and I don't know what is involved, if multiple developers can release or if a single person should be responsible for this...

Please let me know what your views are on this, since I really don't want to create Yet Another Remote-Edit package (maybe named atom-yare :) - just discovered the word )!

Cheers,

Andreas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant