We should put a bit of order in the development process

[jonan]

@fadils @Meisolsson @hzsweers @mustafa01ali

Hi guys, I've been on vacations for a few weeks now, so I haven't been able to contribute (I'll get back to it soon), but I've been following the development process and running the latest master on my phone, and I haven't updated the ForkHub app because I've found too many bugs and inconsistencies.

I know the development is going really fast and it's impossible to add no bugs, but we could minimize them. So please test harder the PRs before merging, I'll help with this as soon as I can.

I've also noticed that the git history is quite messy and it's hard for me to revise the commits. Please try to rebase your branches before merging.

We'll have a really awesome app in next to no time, thank you all for your contributions.

[fadils]

Ah, this is a very good point.

We need to decide about this. Whether we want to merge fast, and fix later when there is a problem. Or we want to make sure first (put a thorough check on the PR, create a unit test where applicable, etc) before merging it to the master.

Several things to put in mind though. First, none of us is maintaining this repo full-time. Second, the urgency to progress this project is pretty dire. And how to keep contributors contributing.

[Meisolsson]

A good thing would be to add a checklist for PR's. So we who are new to the whole Git thing do it right from the start

[ZacSweers]

Separate question, but could you guys give us a little big of background on what the situation is with you guys, GitHub, and ForkHub? It seems strange to me that a collaborator for this repo is still maintaining a separate fork, and I can't actually tell if anyone here works for GitHub.

[jonan]

@fadils the development is moving really fast, and I'm very happy to see the app active again, I want to keep it that way. But, as long as the feedback is quick, I don't think discussing and testing the PRs harder will push back contributions, and I'll be back soon to help in this.
Everyone wants their patches to be great, lets help them do it by pointing out the possible improvements.

@hzsweers we don't work for GitHub, I have a full-time job at another company and just contribute on my spare time, just like everyone else.
I created ForkHub because the official app was unmaintained and had several bugs that made it unusable and I like GitHub to much for not being able to use it on my phone 😆
We don't have access to GitHub's Play Store account, so I'll keep updating ForkHub at least until a new version of the official app is uploaded. I think that having an app in the Play Store (even if it's not the official one) will also attract contributors, but I wont upload version that aren't stable enough for daily use.

So, lets make an awesome app 👍

[ZacSweers]

Does @fadils work for GitHub?
On Thu, Jan 15, 2015 at 4:30 PM Jon Ander Peñalba notifications@github.com
wrote:

@fadils https://github.com/fadils the development is moving really
fast, and I'm very happy to see the app active again, I want to keep it
that way. But, as long as the feedback is quick, I don't think discussing
and testing the PRs harder will push back contributions, and I'll be back
soon to help in this.
Everyone wants their patches to be great, lets help them do it by pointing
out the possible improvements.

@hzsweers https://github.com/hzsweers we don't work for GitHub, I have
a full-time job at another company and just contribute on my spare time,
just like everyone else.
I created ForkHub because the official app was unmaintained and had
several bugs that made it unusable and I like GitHub to much for not being
able to use it on my phone [image: 😆]
We don't have access to GitHub's Play Store account, so I'll keep updating
ForkHub at least until a new version of the official app is uploaded. I
think that having an app in the Play Store (even if it's not the official
one) will also attract contributors, but I wont upload version that aren't
stable enough for daily use.

So, lets make an awesome app [image: 👍]

—
Reply to this email directly or view it on GitHub
#682 (comment).

[fadils]

@hzsweers I wish I worked at GitHub. =)
I think we can tell @kevinsawicki to update the app on the Play Store.
I mean, it's quite a progress compared to Play Store's version.

[ZacSweers]

It feels kind of weird that GitHub isn't actually leading the effort to improve their app. I'm all for open source work and contributions, but they should be the ones organizing this. Have you guys been in touch at least regarding the work over the past few weeks?

[fadils]

I'm in touch with Kevin. Will update you once I receive his response.

[ZacSweers]

Any response?

[kevinsawicki]

I'm in touch with Kevin. Will update you once I receive his response.

I'll respond directly here instead.

After thinking about this for the last couple days, I think it makes sense to move this repository from the GitHub org to somewhere else and remove the original app from the Play store.

No one at GitHub is currently working on this app or planning to work on it in the future. People are instead working on mobile web views for the site.

If people want, I would be happy to transfer the repository to a new organization so all the issues are preserved.

I'm sorry I haven't properly maintained this app but it has been great seeing renewed interest in it. I just don't think it makes sense to keep it under the GitHub organization if we aren't prepared to maintain it properly and publish it regularly.

[ZacSweers]

If this detaches from being an official GitHub app, we forfeit being able to use any logos or even the word "GitHub" in the name due to the Play Store's strict policies.

IMO it would be best to keep this as an official project if at all possible. Is there any way we could have someone liaison with you about development and let you know when we should update the store build?

[fadils]

The man @kevinsawicki has spoken.

First, there is nothing to feel sorry about. You started everything from scratch and it's full of awesomeness.
But sometimes, somethings are getting more interesting and people just choose to go with it.

In all honesty, we all thank you for this repo.

Continuing, we need to look this issue two ways.

1. The importance of the word "GitHub" goes with this repo. I can always fork this repo, add whatever I want, and upload it in the playstore. But people will still search and use the official app.
   Heck, even when we're looking at some issues reported, it still references to the official app although @jonanp has in several places mentioned about ForkHub, which is less bugs, and more-improved cloned version.
2. We also need to respect @kevinsawicki responsibilities and personal interest.

All we need is a little persuasion. Is there anything we can do to minimize the interruption to your work @kevinsawicki ? I mean perhaps a simple once-a-month update?

This is an awesome app. Lots of good codes in it. Many people are being helped by it.
And I'm just afraid that once it loses its GitHub association, then everything will stall.

[dgw]

As an outsider to this situation, I feel my perspective might need to be shared.

I, and no doubt the vast majority of users with the app named "GitHub" installed on their phones, thought this was an official project. It makes sense, after all, for GitHub to make it as easy as possible for us users to use their service from our mobile devices. But the app published in the Play Store is essentially unusable. It hasn't been updated in 11 months. GitHub looks bad for that.

From where I sit, it would be a poor choice to remove the official app from the store or from the GitHub org. Might come across as GitHub the company saying, more or less, "we don't care about Android, you guys should just use a browser".

If the original maintainer isn't willing to upload an updated build every few weeks, then the app listed on Google Play should be transferred to someone willing to maintain it. Not abandoned—revived. Lead by example and show us that community development can support an official offering.

[ZacSweers]

@dgw I'm not sure which side you're a proponent of. On one hand you seem to suggest that it should remain an official GitHub client, but then you also suggest that it should be turned over to someone else/another group. Could you clarify?

[dgw]

@hzsweers The main goal is to get the official app updated. In order to use GitHub logos and names, the app has to be official, doesn't it? Ideally the other person who'd be taking over maintenance of the Google Play listing would be affiliated with GitHub so it could remain official. I'm probably not being as clear as I could be (it's late night here and I'm about to go to sleep) but I advocate for NOT removing the app from Google Play, and for keeping it in the GitHub org.

[ZacSweers]

Ok thanks for clarifying. I agree with you

[kevinsawicki]

Is there anything we can do to minimize the interruption to your work @kevinsawicki ? I mean perhaps a simple once-a-month update?

I think something like this could work, just doing regular, consistent, once a month updates. And maybe starting a CHANGELOG to document the changes over the past month.

[jonan]

That would be a great solution.

It would need some work (like having an always-ready-for-release branch), that's kind of the original objective of this issue, so it's fine with me.

[dgw]

Yes, exactly. What my tired mind could not articulate last night was the need to maintain a stable branch always, and merge in changes only after testing. That way whenever @kevinsawicki has time he can just push a build with whatever the current stable revision is.

[EddieRingle]

Just an FYI to @kevinsawicki, I haven't been focused on Hubroid for a long time now since I thought this official app would have taken off. I'd be sad to see it go (even if I don't currently have any mobile client installed on my devices). Don't create more work for me. ;)

[ZacSweers]

@kevinsawicki that sounds great. A changelog would be easy to maintain as well, and we could easily set up way to programmatically update the play store builds and changelog (we do something similar for internal builds here at Flipboard).

@jonanp @dgw Git-flow seems like a good approach, where master is always "ship-able", and branches/pull requests are reviewed heavily.

[fadils]

+1 with @hzsweers although either way is doable.

Special thanks for @kevinsawicki.

[jonan]

I've been thinking a lot about all this the last couple of days and I think the best solution is to start a new stable branch from the last release. I'll explain.

I think we all agree that we need a new release ASAP, we have three very important bugs that should be fixed in the Play Store: #609, #513 and #582. Current master has a lot of important changes not well tested that will take quite some time to get to a releasable state.

I suggest a stable branch that cherry-picks the bug fixes from master (#609 and #513 are already fixed) so @kevinsawicki can prepare a release soon enough, maybe not even fixing #582 just yet (which needs a significant change).

Most of the work is in fact mostly done, I'd do a 1.9.1 release with exactly what ForkHub has know in the Play Store, that is, just bugfixes for: #495, #554, #513, #609, #561, #591 (and all the duplicates of those bugs), and later a 1.9.2 release for #582.

Once we have this ready we can concentrate on 2.0.0 with all the new Material Design stuff.

What do you think?

[ZacSweers]

I'd rather we just make master stable, and release later down the line.

I think we shouldn't make separate release branches, as that just makes
things confusing (merge to master? Merge to "Release"? When does release
get updated? What is master for anyway?)

I'm a little disheartened by the lack of interest from Github in
maintaining an app they developed, and am worried about that if this goes
forward as a community project. There needs to be some sort of formal
leadership, and communication with Github must be a two way street with
good faith that both sides will respond in a timely manner. There's more to
this than just updating the app as well. Crash reporting, user feedback,
new feature planning, who settles/moderates issue/PR discussions, should
there be project style guidelines, how much can we really test as a small
group, and more.

Basically, there needs to be a well organized group behind this, but I'm
pretty sure all of us have other full time responsibilities. Right now it
feels like we have a lot of people that want to help, but this thread
doesn't seem to be going anywhere fast.

On Wed, Jan 28, 2015, 3:53 AM Jon Ander Peñalba notifications@github.com
wrote:

I've been thinking a lot about all this the last couple of days and I
think the best solution is to start a new stable branch from the last
release. I'll explain.

I think we all agree that we need a new release ASAP, we have three very
important bugs that should be fixed in the Play Store: #609
#609, #513
#513 and #582
#582. Current master has a lot
of important changes not well tested that will take quite some time to get
to a releasable state.

I suggest a stable branch that cherry-picks the bug fixes from master (
#609 #609 and #513
#513 are already fixed) so
@kevinsawicki https://github.com/kevinsawicki can prepare a release
soon enough, maybe not even fixing #582
#582 just yet (which needs a
significant change).

Most of the work is in fact mostly done, I'd do a 1.9.1 release with
exactly what ForkHub has know in the Play Store, that is, just bugfixes
for: #495 #495, #554
#554, #513
#513, #609
#609, #561
#561, #591
#591 (and all the duplicates of
those bugs), and later a 1.9.2 release for #582
#582.

Once we have this ready we can concentrate on 2.0.0 with all the new
Material Design stuff.

What do you think?

—
Reply to this email directly or view it on GitHub
#682 (comment).

[EzraBrooks]

Technically, master should always be stable. We should be branching out for fixes and development.

[mustafa01ali]

I am disappointed with the lack of interest from Github as well. If the folks there are not interested in maintaining this app or actively participating if it becomes a community project, it doesn't make sense to keep working on it.

[jonan]

I don't want to enter the debate of what GitHub should or shouldn't do, they are free to do what they want and the solution @kevinsawicki proposed is good enough for me. I'll start working on a stable branch we can release every month.

[fadils]

I'm closing this. First and foremost is to prevent the negativity vibe that this thread may cause. This project is basically stalled ever since. Other issues such as master, stable, whatever, please create in another issue. Finally, whoever wants to contribute then you're very welcome. And who doesn't feel to contribute then you're very welcome too. Thanks so much for the input and important points stated in this thread. But it's time to move on.

[ZacSweers]

I think this project is a bust. It's been nearly 2 weeks since we last heard from GitHub, how is this going to get off the ground if we can't get a solid dialogue going? I personally would be (and am) hesitant to contribute any further for worry that nothing here will actually see the light of day.

I get that everyone here wants to help and likes the idea of being in charge of the Github app development, but there needs to be some level of official oversight.