Qtox: Repo management

[zetok]

Preface

@tux3 is constantly absent.

Some time ago (few months) I've tried to convince @tux3 that repo should be
moved from under tux3/ to qTox/ github organization. He was not convinced,
and opted to do organizational things first instead.

Those were things like meetings on IRC, during which decisions would be made
regarding e.g. matters that maintainers disagreed on by voting, and things like
that.

When agreeing on the time & day of the week for the meetings, I've asked @tux3
if he will be able to attend the meetings, and he said that he can.

Now, at the present day idea of meetings & getting organized has been nuked,
main reason for it is @tux3's constant absence during the meetings. It would be
understandable that life gets in the way, and even just a prior notification
about absence in $time_period would be good enough to keep things going. There
was no such thing from @tux3. For months by now.

Generally, tiring, and seems kinda like a waste of time to wait when @tux3
won't appear.

Why the move

The main reason is to not have a single point of failure, like @tux3 seems to
be now.

There are other reasons:

• making needed changes to the repo when needed, rather than waiting for
  single, fairly inactive person to do it
• there are things that would improve workflow with the repo
  
  
  
  • required checks for PR merge
  
  
  • travis – this needs though someone actively managing the repo, so
    
    that check could be disabled if for $random_reason travis decides that
    
    it's time to break.
  
  

  There was discussion about it, and @tux3 said that it's not important
  enough to require a check if with changes from PR qTox even builds.

  Plus he's not even really managing the repo, so there's that.

  Also said that if someone doesn't even check if qTox builds before
  merging a PR and pushing it to master, it's quite a good way to weed out
  people who shouldn't be pushing to master.

  This isn't quire right, since whatever can be pushed to master with no
  review or checks for anything, and this can't even be ammended, since
  `master` branch is protected against force pushes.

  The code that is on master is being automatically compiled for e.g.
  nightly jenkins windows builds, and users of several distros also have an
  option to use latest master. Furthermore, lots of other things depend on
  the things in master, e.g. translations on weblate.

  The only person who could do something about it if problem were to happen
  with `master` branch is @tux3.
- PRs should be **reviewed and approved**, otherwise they can't be merged.

  For this, `reviewable` would do the job. This is least problematic thing
  to use. @tux3 enabled reviewable 2 days after I've emailed him to do it,
  but it's still not quite the way it should be, since there is still no
  required check for review.

  Note that with repo under a gh org, it's ~possible to have more granular
  control access, so that e.g. more people than just the ones with write
  access to the repo could review PRs.

  This, among things, would:
  - clearly show that people's involvement in reviewing is really
    appreciated
  - show a way for contributors to become maintainers (points below), aka
    get write access
- The workflow for this is quite nicely shown e.g. on [hstox PRs](https://github.com/TokTok/hstox/pulls). Note that even though it may
  look like lots of people have write access, only a few of them can
  actually push things to master, and only after checks pass (review &
  travis).

• contributors & maintainers
  
  
  
  • currently only @tux3 can add new maintainers (people with write access)
    
    to the repo.
  
  
  • process of adding new maintainers is not clear
    
    
    
    
    
    • due to this there might have been people who could have had a way to
      
      
      become maintainers, but they didn't even know that they could(!). This
      
      
      is simply wrong.
    
    
    
  
  
• various other things – as time flows, there are other things that come and
  go. There were some in the past that don't matter now, and there are and
  will be issues that I haven't touched upon.

@tux3 doesn't want to move

That's basically it. Not all hope for it died in me, but after yesterday's
conversation in IRC I kinda lost almost all of it.

Relevant part:

[17:16:57] <zetok> tux3: so, can you move the repo? or is the answer "no" ?
[17:19:10] * tux3 has quit (Quit: Leaving)

What moving away means without @tux3 cooperating?

What is tied to the repo:

• issues & pull requests
• links on the internets
• wiki
• github stars (the most important thing :D )

If cooperation were to happen, all of that would be ~preserved.

• issues are moved along with the repo
• links to tux3/qTox would be redirected by github to qTox/qTox
• wiki would be moved along with the repo
• github start are kept \o/

This would just require from @tux3 to not create/fork qTox repo under tux3/
for links to be redirected.

Cooperation doesn't seem like the most likely variant, so the eventual outcome
could be:

• issues & pull requests are left behind
  
  
  
  • they could be tried to be migrated, but it might be error-prone
  
  
• links point to the old repo
• wiki can be just copied, since when it gets down to it, it's just a git repo
• no gh stars ;c

Since links would be pointing to the old repo, code still would be getting
synced with the new repo – in a year or some more time syncing could be left
behind.

The most painful thing are issues & pull requests. If there is ~consensus that
move should happen, we might try to look into trying to get that data.

Apparently there are some things for it; as for how well it would those
things work.. E.g. https://github.com/IQAndreas/github-issues-import

What is ready?

qTox org is there, with all the maintainers added.

I've added @iphydf to the org, since they're a person who could help with
review & merging PRs. They've set up things on the repo that could improve
current workflow. I also asked in email @tux3 to add @iphydf to tux3/qTox
repo, but he didn't do it.

There's an example of workflow that would benefit qTox:
https://github.com/qTox/qTox/pull/3

What do you think?

I really would like to hear what the people think about it.

Note that we can wait, and what not, but if we're to move, the sooner the move
will happen, the smoother it will be.

[antis81]

I never understood why we didn't chose for this right from the start and think the qTox community would greatly benefit from this. It's worth alone for the fact, that the organisation gets an identity and more transparent to contributors and users.

[sudden6]

I also strongly favor moving to an org, as this would remove a single point of failure. Also this would represent what qTox is, a peer to peer network.

[nikitasius]

SantaBarbara....

[ghost]

I also am favor of moving to an org. What this will do is benefit the community and strengthen the positioning of qTox by allowing for more contributors to be added to the project, as well as the other benefits listed in the first post. The way I see us moving forward is by doing so without @tux3. We thank him for his many past contributions to qTox, but at this point due to his inactivity and his self-admitted lack of current interest in qTox, I honestly see no valid reason for him not to relinquish control of the tux3/qTox repo.

This in no way is intended to be any type of hostile fork. Instead, this is a community push to do what's best for qTox, and in effect this also affects the Tox project as a whole as qTox is the most popular client. The door is open at any time for @tux3 to further contribute to qTox.

[zetok]

Since there is ~consensus. :)

So, with the above mentioned tool I've tried to start test of importing the issues.

It needed a bit of friendly touch to get it to work: https://gist.github.com/zetok/99ebe97d3503f0b80c604474010f15b4

test repo: https://github.com/qTox-issue-import/qTox/issues ← you can watch as it slowly (due to gh rate-limiting) gets populated :)

[zetok]

And it looks like rate-limiting won't allow for anything more :/ nvm, it's even slower than it initially seemed

[initramfs]

Not that my opinion particularly matters but I support the move.

@zetok Will the issues with "[CLOSED]" in their title actually be marked closed in GitHub? If not that'd be painful...

[zetok]

Will the issues with "[CLOSED]" in their title actually be marked closed in GitHub? If not that'd be painful...

They will be needed to be manually closed. Something that I'll do. I've looked a bit into closing the issues automatically right when creating them, so that there would be no need to add [CLOSED] to them, but gh doesn't really expose a straightforward way to close issues automatically (or at least I couldn't find it), so. :/

[ProMcTagonist]

send a bunch of PRs that close them

[zetok]

cc @agilob

[zetok]

So, thanks to @agilob now we know how easy it is to break issue order. Eh.

@agilob github seems to have an option to just ignore all the notifications for a repo, does it not work?

As for your question – preserving data in the issues and issue references.

Since the current one was broken, it will need to start again. AKA, remove repo and start again -.-"

Edit:

[agilob]

I was for moving to org long time ago. I ignore notification from qtox-issue-import because got >20 of them over night. I don't see the point of it at all? If you're importing it, your script is broken, it should not call me to copy of issues from here. I've seen those issue, I've responded there, most of them were closed/invalid/solved, so why notify me again about it if there is no regression?

If you're asking if I'm ok to pass my IP rights in this repo to different ownership (which I believe is a case now), than I'm completely OK with it. To make it even easier for you all, I officially pass all my IP rights to the organisation that will be created and all its members :) I trust you @zetok know what is best for qTox and tox and let you make future decisions for me.

[zetok]

If you're importing it, your script is broken, it should not call me to copy of issues from here.

Um, no, script doesn't call anyone. It just copies content of the issues and posts that content. It's not possible to "just copy", the only apparent way is to recreate all the issues. So when issues have @mention in them, one gets notified.

If you're asking if I'm ok to pass my IP rights in this repo to different ownership, than I'm completely OK with it. To make it even easier for you all, I officially pass all my IP right to the organisation that will be created and all its members :) I trust you @zetok know what is best for qTox and tox.

Um, no, this is not what move is about – move is only about "location" of where development will be happening, and that's it.

Sorry for the "spam". Since I've recreated repo to start again, you'd (and preferably anyone else) need to ignore new one again. Sorry again, it didn't really occur to me that everyone would be @notified of things again.

[agilob]

Replace @zetok with @zetok @**zetok**

Um, no, this is not what move is about – move is only about "location" of where development will be happening, and that's it.

If you move it from person to organisation it changes ownership of IP rights?

[zetok]

Right, thanks, I'll see if my non-existent python knowledge can be extended with info about regexps in python :)

[initramfs]

@zetok In order to make your life easier, should a issue/PR freeze be imposed on the current repository? Even just informally? I do have something I want to submit (very minor, not time critical at all), though I don't want it to just add to your workload...

[zetok]

Well, current PRs will need to be merged from tux3/qTox, since they will be just recreated as issues and marked that they were PRs; if it's about new PRs, migrating is very slow, it may take 3-4 days or so to migrate it all. Or more.

For one, I don't really believe that people would "just stop/wait" for migration to happen, but it would be nice, as those "missing" new issues/PRs/comments wouldn't need to be recreated (manually? there is a PR to the script that claims to do this, but it didn't really seem to work, and I don't know enough of python to get it to work).

Script (slowly) crawls through all the issues & comments, caches them, and then (very, very slowly) recreates issues & comments from cached ones.

So once I get script today to not notify @ people, I guess freeze would be nice.

[initramfs]

@zetok Okay, I'll reframe from submitting stuff then.

In the interest of helping, I have taken it upon myself to write a GitHub issue importer in java, just in case that Python script isn't cutting it. It's about 70% done though it has a few issues that I do not know how to resolve. One nice feature that my program can do is auto mark-closed issues that are actually closed.

If ever you feel that that Python script is giving you more pain than it's worth, I'm happy to share my importer with you if you'd prefer that.

[zetok]

Sounds great, thanks :)

I think that I got the regexp done, and it's time to see if I put it in the right place. If at the end of the day I still won't be able to get it to work the way it is supposed to work, we can always try with java :)

[agilob]

@zetok make repo private for the time of migration.

[tux3]

Hi everyone, let me try to answer things!

Should we move qTox to an organization?

When we discussed this with @zetok (and we discussed this at length!), I was not convinced, since I though that it was not addressing the problems we have. I saw no advantage to moving everything when there are more important problems to take care of (such as, the high number of bugs open, the languishing PRs, etc).

However it seems pretty clear by now that everyone agrees we should move, so maybe I was wrong. Let's move.

@tux3 is constantly absent

When I created qTox, I imagined it would be a fun little side project around this awesome little messenger called Tox, and it was. But now it's become this huge — still fun! — side project that demands hours and hours of maintenance every week.
I've happily developed and maintained qTox for a little while now, and it seems I'm still responsible for most of the code in here, but after so long it's harder to find the time every week to spend hours taking care of all the work that has piled up, when there are so many other things and projects I could be working on at the same time!

And so I have an obscene amount of unread notifications, and PRs pile up because I'm not always here to review them.
However, because I don't want to block other people's work, some time ago I added several people as collaborators to the repo. I have tried to answer my mail in a timely manner so that whenever I was needed, I would not delay things for more than a day or two, and although I'm not as active as I used to be I can be seen on IRC from times to times :)

Unless something dramatic happens, I don't think that I will have much more time to dedicate to qTox in the future than I do today, which is from a couple to several hours a week. That said I'm committed to keeping things running smoothly, and I hope I'll be able to move things forward, because even with its flaws, I still think that Tox is a wonderful idea.

@tux3 evades questions on IRC

Now, this one is unfair!

That's basically it. Not all hope for it died in me, but after yesterday's
conversation in IRC I kinda lost almost all of it.

Relevant part:

[17:16:57] tux3: so, can you move the repo? or is the answer "no" ?
[17:19:10] * tux3 has quit (Quit: Leaving)

Conveniently missing from those two lines, is hours of context and previous discussions :)
That and the fact that I actually quit after 18 minutes of inactivity and not in the middle of a discussion (my last message was at 17:01:52 in @zetok's timezone) because I had been on the phone with a family member for the past half hour and was too busy with real life matters to start another heated discussion on IRC.
I'm always happy to talk until both our ears will bleed, but sometimes if I have to quit for the day please don't immediately assume bad faith!

@iphydf

I've added @iphydf to the org, since they're a person who could help with
review & merging PRs. They've set up things on the repo that could improve
current workflow. I also asked in email @tux3 to add @iphydf to tux3/qTox
repo, but he didn't do it.

My mistake, I did receive your mail, @zetok, but among the things you asked I missed this part.
I'm very sorry @iphydf and I'll try to be more careful reading my mails in the future!

[initramfs]

@tux3 Forgive my ignorance in this matter but, by "moving" (officially that is), apart from URL changes (and build scripts/nightly packaging programs that need to be redirected) would there be any sort of service change/interruption in qTox development as it stands right now?

I know that everyone who spoke up here has already agreed to a move, but that's probably mostly due to what @zetok said (at least for me). I'm not trying to sway people the other way (I agreed to a move) but would you kindly share your rationale to way you didn't want to move? Just for the sake of documentation? Hence me asking the above, does moving somehow adversely affects the speed that bugs can be fixed? Or does it stop PRs from being merged? etc...

[agilob]

be any sort of service change/interruption in qTox development as it stands right now?

Update documentation.
Update build scripts
Update links
I think github automatically redirects tux3/qtox to qtox/qtox after change to organisation, so you don't have to update hundreds of links on blogs and social media...

[zetok]

@agilob private repos on github are a paid feature.

[zetok]

We have migrated \o/

Anyway; changes done: now checks are required – code review via reviewable (needs :lgtm: & reviewing files (pressing that red button on top of changed file by reviewer (person assigned) for review to pass) + travis check. For travis check, @iphydf made a fix for osx travis, which is going to be merged ~now.

[agilob]

@agilob private repos on github are a paid feature.

It is not.

[zetok]

Oh, it has changed?

Thanks, I'll look into this when I'll have some time :)

[antis81]

@zetok Just created first new PR after renaming my "upstream" remote and everything works like a charm, thanks!

It may help others to smoothly migrate :cocktail:. So here's what I did:

# Copy folder. Just in case anything goes wrong
cp -r qtox qtox.tux3

# rename and add new "upstream" remote
git remote rename upstream tux3
git remote add upstream [email protected]:qTox/qTox.git

# update
git fetch upstream


# The following steps are helpful for maintainers:

# point local "master" branch to moved "upstream" 
git checkout -B master upstream/master

# Check, that everything goes fine.
git push -nu upstream master
  #  Would set upstream of 'master' to 'master' of 'upstream'
  #  Everything up-to-date

# Everything ok? Do the real thing:
git push -u upstream master
  #  Configured branch master to follow remote-branch master of upstream.
  #  Everything up-to-date

[agilob]

Oh, it has changed?

I had this since ever Oo

[Diadlo]

@agilob
Click on it :)
Or maybe you have student/teacher account

[agilob]

Or maybe you have student/teacher account

Don't have any of these :)

[Diadlo]

@agilob https://education.github.com/guide/private_repos

[nikitasius]

off.. fuuu~, i click unsubscribe. Thats much more boring than viagra spam.

[antis81]

I'm always happy to talk until both our ears will bleed, but sometimes if I have to quit for the day please don't immediately assume bad faith!

:+1: I agree, the "aborted discussion statement" is unfair and you're a valued maintainer for the project. Happily you wrote a differentiated reply and still with us. So: Feel warmly welcome (still) to qTox maintainers group! :+1:

@initramfs (and all actually):

…I'm not trying to sway people the other way (I agreed to a move) but would you kindly share your rationale to way you didn't want to move? …

Let me clear this up:
When I started contribution around middle last year, we have been in a situation, that qTox was a personal repository contributions regularly got staled during Tux3's absence. We had a quite productive discussion via mail and to my knowledge he was never strait against moving to the organization. The only reason was simply, that nobody had the time to realize the migration step from start to finish and values of a Github organization seemed to little to be worth it. Times have changed now and qTox became more stable with more active supporters. So the time for migration is just the right time now. That's all. It's done and even no cats died in the process. :smile: A big thanks to @tux3 for creating this "little" project!!