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.
On Monday, September 10, 2012 4:56:24 PM UTC+3, Michael Pedersen wrote:
> 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.
> 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 ?
On Mon, Sep 10, 2012 at 10:40 AM, Christophe de Vienne
<cdevie...@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.
> On Mon, Sep 10, 2012 at 10:40 AM, Christophe de Vienne
> <cdevie...@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).
On Mon, Sep 10, 2012 at 11:11 AM, Christophe de Vienne
<cdevie...@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.
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.
On Mon, Sep 10, 2012 at 6:41 PM, Christoph Zwerschke <c...@online.de> wrote:
> 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
> --
> You received this message because you are subscribed to the Google Groups
> "TurboGears Trunk" group.
> To post to this group, send email to turbogears-trunk@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears-trunk+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears-trunk?hl=en.
> 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
FYI, bitbucket supports git repos now, as well as hg ones.
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
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.
On Tuesday, 11 September 2012 04:09:47 UTC+5:30, Craig Small wrote:
> 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.
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 <alindsha...@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.
On Monday, 17 September 2012 01:48:54 UTC+5:30, Roberto Guerra wrote:
> Honest question from a newbie: why github over bitbucket?
> On Monday, September 10, 2012 7:56:24 AM UTC-6, Michael Pedersen wrote:
>> 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.
On Sat, Sep 15, 2012 at 4:23 PM, Mengu <whalb...@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.
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.
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.
On Thu, Sep 27, 2012 at 10:44 AM, Christoph Zwerschke <c...@online.de> wrote:
> 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.
> --
> 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 turbogears-trunk@googlegroups.com.
> To unsubscribe from this group, send email to
> turbogears-trunk+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/turbogears-trunk?hl=en.
On Thursday, September 27, 2012 6:23:20 PM UTC+3, Michael Pedersen wrote:
> 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.
> On Thu, Sep 27, 2012 at 10:44 AM, Christoph Zwerschke <ci...@online.de<javascript:>> > wrote: > > 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.
> > -- > > 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<javascript:>.
