Switching To GitHub

[Michael Pedersen]

Okay, a couple weeks back, right after we released TG 2.2.0, we
discovered a few things about the sourceforge system that makes it no
longer desirable for using as our tracker. We had been thinking of
using Github back when we switched last year, but (at the time) we
chose SF.

Now, we're going to make the switch to Github. I'm in the process of
writing a migration tool that will copy all the pieces over for us.
One question, though, has arisen, and this change is both significant
and inconsequential. All of our previous systems have used one issue
tracker for the entire project. Github uses one tracker per
repository, and we have three repositories (core, docs, and
tutorials). This means that I have to do something different for
copying ticket information, and I want to ask for feedback before I do
it. Here's the options:

1. Copy every ticket into every repository's issue tracker. Good:
Ticket numbers are preserved. Bad: Tickets are fully duplicated, which
could make it difficult for people to track the tickets they genuinely
care about. Also means we have to close a bunch of them
inappropriately (a ticket applies only to docs, so it has be closed on
core and on tutorials).

2. Copy only relevant tickets, but use placeholders for non-relevant
tickets. Good: Ticket numbers are preserved. Bad: Lots of tickets in
each repository that will read "Placeholder. Please ignore."

3. Copy only relevant tickets. Good: Each repository's issues are kept
to being just the relevant items. Bad: Ticket numbers are not
preserved.

I'm leaning towards number three, personally. However, I know that
there are some people who will prefer (or even demand) one of the
others, so as to preserve ticket numbering.

What do you think? Which one would you prefer?

--
Michael J. Pedersen
My Online Resume: http://www.icelus.org/ -- Google+ http://plus.ly/pedersen
Google Talk: m.ped...@icelus.org -- Twitter: pedersentg

[Mengu]

hi michael,

i am really happy to see this change. i'm glad that we are moving to github.

i vote for number three.

[Christophe de Vienne]

Hi,



Le 10/09/2012 15:56, Michael Pedersen a �crit :

> Okay, a couple weeks back, right after we released TG 2.2.0, we
> discovered a few things about the sourceforge system that makes it no
> longer desirable for using as our tracker.

I am interested in knowing the "few things", could you explain the
reasons for this decision ?

Thanks,

Christophe

[Michael Pedersen]

On Mon, Sep 10, 2012 at 10:40 AM, Christophe de Vienne
<cdev...@gmail.com> wrote:
> I am interested in knowing the "few things", could you explain the
> reasons for this decision ?

To some degree, yes. Parts are lost to memory, despite it being only a
couple weeks. Among them:

* I have tried two different browsers, and neither of them is able to
create a new Milestone for the next version.
* When going to sourceforge.net and doing a search for turbogears,
turbogears2 would *not* come up unless you turned off the "recently
updated" tag. This was a matter of days after the 2.2.0 release, and
TG1 was always able to be found.
* I'm seriously pondering switching jenkins to our own server. We're
not able to get emailed build failures due to anti-spam issues (the
sender line can't be changed without possibly breaking something else
on the machine, and I'm not willing to take that risk). Github offers
a CI service that we could begin using quickly, and even have our CI
scripts checked in and version controlled.
* A perception that Github is more active than SF (in general), and
therefore would be easier to bring people on board. Less friction
(since they're already using it) would mean it is hopefully easier for
people to submit patches.
* The layout of the projects on SF make it difficult to bring
everything together in one place. I'd like to see tgtools (tgext.crud,
tgext.admin, etc) all available at one location, so that we could tell
people to look in one place for everything TurboGears (as opposed to
the noticeable spread that we have).
* Better management of projects on Github. On Github, it feels easier
to allow people to control different aspects of the project as a
whole.
* Easier (and more complete) API access, allowing me to write some
tools to help make the release process *much* easier. I've looked at
the SF side, and it is much harder over there, trust me.

That's all that I can remember. Nothing huge, no one specific tipping
point, just a group of small items that eventually point to the need
to leave SF for something else.

[Christophe de Vienne]

Le 10/09/2012 16:54, Michael Pedersen a �crit :

> On Mon, Sep 10, 2012 at 10:40 AM, Christophe de Vienne
> <cdev...@gmail.com> wrote:
>> I am interested in knowing the "few things", could you explain the
>> reasons for this decision ?
> To some degree, yes. Parts are lost to memory, despite it being only a
> couple weeks. Among them:

[...]

Thanks for the precisions.

Have you considered bitbucket too ? IIRC the tg repositories were once
hosted there, and it has the same avantages over SF (the ones you
mention at least).

Christophe

[Michael Pedersen]

On Mon, Sep 10, 2012 at 11:11 AM, Christophe de Vienne
<cdev...@gmail.com> wrote:
> Have you considered bitbucket too ? IIRC the tg repositories were once
> hosted there, and it has the same avantages over SF (the ones you
> mention at least).

Actually, we did consider it. I chose not to go with Bitbucket for two reasons:

Github, for better or worse, has more developer activity (or, at
least, the perception of it). This makes Github more desirable over
Bitbucket.

The second reason is because we did use Bitbucket in the past. I'm
worried that using it again would increase confusion with links to no
longer valid repository URLs (in part because we very much modified
the repository structure when we migrated from Bitbucket). While we
don't deliberately leave the old URLs around, they are in mailing list
archives and the like. That source of confusion should be avoided if
possible.

So, even though Bitbucket is nice, the balance of factors leans towards Github.

[Christoph Zwerschke]

Am 10.09.2012 17:11, schrieb Christophe de Vienne:
> Have you considered bitbucket too ? IIRC the tg repositories were once
> hosted there, and it has the same avantages over SF (the ones you
> mention at least).

That would mean switching from git back to hg again. Much easier to stay
with git. It's bad enough that we have to change our project platform
again, but at least please let's not change the VCS type and convert the
repository again! Also, I remember there was a long discussion where
some developers had issues with both bitbucket and hg, and wanted to use
git instead. Not sure if these were real issues, or if they are solved
now, but that's actually why we moved away from bitbucket. If we move,
we should at least not move in circles.

-- Christoph

[Alessandro Molina]

Also currently travis.ci doesn't provide support for bitbucket, and
travis was one of the reasons for moving to GitHub.

> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears Trunk" group.
> To post to this group, send email to turbogea...@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears-tru...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears-trunk?hl=en.
>

[Kevin Horn]

FYI, bitbucket supports git repos now, as well as hg ones.

Kevin Horn 

[Christoph Zwerschke]

Am 10.09.2012 20:45, schrieb Kevin Horn:
> FYI, bitbucket supports git repos now, as well as hg ones.

Thanks for the update, that move had indeed slipped under my radar.

-- Chris

[Craig Small]

Hello Michael,
Thanks for giving some information about the reasons for the switch.
When I saw your announcement my first thought, like some others, was
why. I'm involved in a bunch of project across a variety of sites
(including SF but not github) which is why I was curious.

We got the "why".

I think option 3 seems the nicest, or least-worse.

- Craig
--
Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5

[jeetu]

1) Why not merge all three into one repository. This may allow (and facilitate) users to do minor changes in docs as well easily. Additionally, It will have the benefit of docs and code up-to-date for each other. As all three are very well dependent on each other, it should be merged into one. Hopefully size of all together is not much so as to have an impact on cloning and pushing time.

2) Personally I like mercurial but git is no doubt the most used DVCS. Also the commands are mostly the same for normal working. So congrats on the move.

[Michael Pedersen]

This post winds up being in reply to one particular post, but that's a
quirk of replying to a topic. I'm going to try to address points
raised by several people.

First, on the topic of bitbucket: Yes, they use git, and hg. They
provide a number of very nice tools. No argument there. Despite this,
they still fall short of the sheer mass that Github has. If you look
for open source code, Github will wind up hosting quite a lot of it.
If you look for developers and developer profiles, you will find quite
a lot on Github. It is easier to share on Github than it is on
Bitbucket, by virtue of the fact that more people are already *on*
Github than on Bitbucket. They are already used to using the tools,
and (let's face it) we're trying to find ways to bring people in. The
less friction we put in their way, the more likely we are to get
contributions.

Like it or not, Github wins on this count. Unless you can provide some
sort of study that provides numbers that show Bitbucket has more users
doing more than Github, well, Bitbucket won't win this round. Add in
the confusion of the older URLs that still exist in email archives
(and we are not able to remove those archives), and going back to
BitBucket will create more confusion. I want to reduce it. Unless you
have a way (after dealing with the user issue) to deal with the old
email archives, Bitbucket loses there, too.

In short, expect to see things moved to Github, and more (and better)
definition given to the project there.

On Tue, Sep 11, 2012 at 12:31 AM, jeetu <alind...@gmail.com> wrote:
> 1) Why not merge all three into one repository. This may allow (and
> facilitate) users to do minor changes in docs as well easily.

There are three repositories for core pieces, and they are not
actually dependent on each other. They are related, but they are not
dependent. Furthermore, making changes to each repository has a
different enough process that knowing what you are doing in one does
not guarantee any knowledge of one of the others. Making docs involves
working with Sphinx and Restructured Text. Updating TG involves
working with TG and related libraries. Updating the devtools means
updating the templates that are used to produce a given quickstarted
application.

Since all of that is true, we want to make it possible for people to
make changes to one without having to change the others. The only time
people have to worry about multiple repositories is when release time
comes, and that's my problem to deal with.

End result: These repositories really should not be merged, and I have
no intention of doing such a merge. It would create work, and solve
only the problem of possibly renumbered tickets. The value here does
even come close to the amount of work required to merge them, and
that's with the merge being moderately easy. So, a merge is not going
to happen.

> 2) Personally I like mercurial but git is no doubt the most used DVCS. Also
> the commands are mostly the same for normal working. So congrats on the
> move.

I happen to agree, and like Mercurial more myself. Still, we went to
git, and I'm not going to switch back just on a whim. Especially when
using git can let us try to work with people on a very active code
hosting site that uses only git.

[Mengu]

so, when is the transition happening?

[jeetu]

Read the following thread and may be you'll get your answer.

https://groups.google.com/forum/#!topic/turbogears-trunk/PRiV1D7j7UU

On Monday, 17 September 2012 01:48:54 UTC+5:30, Roberto Guerra wrote:

Honest question from a newbie: why github over bitbucket?

[Michael Pedersen]

On Sat, Sep 15, 2012 at 4:23 PM, Mengu <whal...@gmail.com> wrote:
> so, when is the transition happening?

As soon as possible. I have *just* gotten the work done to download
all the available ticket information. Even still, from what I can
tell, the information about what attachments were done to a ticket
seems to be missing, and not retrievable from the API provided.
Tomorrow night, I'll work on being able to upload the data, which is
going to be mostly transformative work, and then I can ask for people
to review the newly created tickets. It won't have the repositories be
separated yet, but that's actually one of the easier parts to deal
with.

[Christoph Zwerschke]

Just want to point out that the move to GitHub has some other positive side-effects. For instance, GitHub makes it much easier for people to fork TurboGears and send in pull requests. Another advantage is that you can connect to the Github issues from Eclipse/Mylyn, for those who are using PyDev. If you haven't checked out the PyDev+Mylyn combination, I encourage you to do so, it's really useful and fun to work with.

[Michael Pedersen]

I am seeing lots of benefits from the switch to Github, honestly. And
that's just from the site itself. The ability to comment on pull
requests, diffs, everything. The integration of all of these
activities into one coherent news feed (check out
https://github.com/organizations/TurboGears ). The easier ability of
people to fork, commit, and submit pull requests.

In fact, I've only found *one* downside to Github so far: I can't find
a way to attach a file (such as a diff, or a screenshot) to an issue.
The rest, though? I'm very glad for this switch.

> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears Trunk" group.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/turbogears-trunk/-/N77a4J-TrXoJ.

> To post to this group, send email to turbogea...@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears-tru...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears-trunk?hl=en.

[Mengu]

you guys have no idea how great it is to be able to view turbogears source on github. :)

again, thanks for such a good decision.

[Jānis Ābele]

Another benefit of using GitHub is Travis-ci.

I think moving to GitHub was good move.