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.
> 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?
Number three, but ideally should add comments with links to the corresponding issue in the other tracker.
When you created a migration script, let me know. Maybe I'll move TG 1 as well when I find some time.
I really appreciate this move and I would vote for variant 3, too!
I think duplicate or placeholder issues would be strange, as I've never
seen them in Github projects before. ;)
> 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.
I think too that moving to GitHub will make things easier as well more
visible, on the issue topic I too go with option 3, seems to me the
most sensible option.
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 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 Sun, Sep 16, 2012 at 4:18 PM, Roberto Guerra <uri...@gmail.com> wrote:
> Honest question from a newbie: why github over bitbucket?
The answers for this are not actually deep. I did answer this question
above, but here's the answer again (copy pasted from above):
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.
Okay, I *finally* have some news to actually be able to show people.
Please visit this repo: https://github.com/pedersen/tgmigrtest and
check out the issues. This is what the end result will look like.
Right now, all issues are collapsed into one repo, but the code
already supports adding tickets to the proper repo. I just haven't
wanted to mess with the others as yet, not while I'm testing.
Please look over the issues, and let me know if you find any problems.
The only ones that I'm aware are as follows:
* Almost all labels use black. I'll be manually changing, once we
decided on a color scheme.
* No attachments got copied from SF to GitHub. The API of SF didn't
provide a mechanism I could find for getting those attachments. Will
have to copy those manually, too.
Let me know if you find other errors. Without feedback, I'll be making
this migration official over the weekend, and closing down write
access to the repositories and tracker at SF.
On Tue, Sep 18, 2012 at 12:56 AM, Michael Pedersen
<m.peder...@icelus.org> wrote:
> On Sun, Sep 16, 2012 at 4:18 PM, Roberto Guerra <uri...@gmail.com> wrote:
>> Honest question from a newbie: why github over bitbucket?
> The answers for this are not actually deep. I did answer this question
> above, but here's the answer again (copy pasted from above):
> 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.
> Please visit this repo: https://github.com/pedersen/tgmigrtest and
> check out the issues. This is what the end result will look like.
> Right now, all issues are collapsed into one repo, but the code
> already supports adding tickets to the proper repo. I just haven't
> wanted to mess with the others as yet, not while I'm testing.
> Please look over the issues, and let me know if you find any problems.
> The only ones that I'm aware are as follows:
Seems ok, only extra "metadata" is missing such as version (where the
bug was found not milestone) but I think that we can leave that out or
added as part of the issue comment.
Other than that the formatting looks a bit messed in some issues but
it seems so does the original SF issue, for example:
I agree, adding the version as a tag would be really helpful.
Also there are things like the "module" which creates quite some chaos
(sqlalchemy, quickstart, core, and so on). To split between different
projects we can now add the tickets to the project itself (core vs
devtools) and actually I think that it is something that until we have
a team of many people splitted in subteams is not very useful.
On Thu, Sep 20, 2012 at 7:50 AM, Carlos Daniel Ruvalcaba Valenzuela
<clsdan...@gmail.com> wrote:
>> Please visit this repo: https://github.com/pedersen/tgmigrtest and
>> check out the issues. This is what the end result will look like.
>> Right now, all issues are collapsed into one repo, but the code
>> already supports adding tickets to the proper repo. I just haven't
>> wanted to mess with the others as yet, not while I'm testing.
>> Please look over the issues, and let me know if you find any problems.
>> The only ones that I'm aware are as follows:
> Seems ok, only extra "metadata" is missing such as version (where the
> bug was found not milestone) but I think that we can leave that out or
> added as part of the issue comment.
> Other than that the formatting looks a bit messed in some issues but
> it seems so does the original SF issue, for example:
> I think that it would be a waste of time to correct that (messed
> formating) and we can go as is with those issues imported from trac
> originally.
> Regards,
> Carlos Daniel Ruvalcaba Valenzuela
> --
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbogears@googlegroups.com.
> To unsubscribe from this group, send email to turbogears+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
Agreed with both Alessando and Carlos. I missed grabbing the version,
but that was an easy fix. I've added that in. Doing so meant creating
all new tickets, though, so check the newly made tickets. All the old
ones got closed.
As for extra labels, I wanted to try to capture all of the ones we had
up front, at least. Once the tickets are made, any extras will be
deleted. For instance, the component ones will become "internal" (for
TG itself) and "external" (for sqlalchemy, tw, etc). Should be able to
complete those changes across all the repositories within another hour
or so of getting the tickets uploaded.
On Thu, Sep 20, 2012 at 5:13 AM, Alessandro Molina
<alessandro.mol...@gmail.com> wrote:
> I agree, adding the version as a tag would be really helpful.
> Also there are things like the "module" which creates quite some chaos
> (sqlalchemy, quickstart, core, and so on). To split between different
> projects we can now add the tickets to the project itself (core vs
> devtools) and actually I think that it is something that until we have
> a team of many people splitted in subteams is not very useful.
> On Thu, Sep 20, 2012 at 7:50 AM, Carlos Daniel Ruvalcaba Valenzuela
> <clsdan...@gmail.com> wrote:
>>> Please visit this repo: https://github.com/pedersen/tgmigrtest and
>>> check out the issues. This is what the end result will look like.
>>> Right now, all issues are collapsed into one repo, but the code
>>> already supports adding tickets to the proper repo. I just haven't
>>> wanted to mess with the others as yet, not while I'm testing.
>>> Please look over the issues, and let me know if you find any problems.
>>> The only ones that I'm aware are as follows:
>> Seems ok, only extra "metadata" is missing such as version (where the
>> bug was found not milestone) but I think that we can leave that out or
>> added as part of the issue comment.
>> Other than that the formatting looks a bit messed in some issues but
>> it seems so does the original SF issue, for example:
>> I think that it would be a waste of time to correct that (messed
>> formating) and we can go as is with those issues imported from trac
>> originally.
>> Regards,
>> Carlos Daniel Ruvalcaba Valenzuela
>> --
>> You received this message because you are subscribed to the Google Groups "TurboGears" group.
>> To post to this group, send email to turbogears@googlegroups.com.
>> To unsubscribe from this group, send email to turbogears+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbogears@googlegroups.com.
> To unsubscribe from this group, send email to turbogears+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
On Thu, Sep 20, 2012 at 7:02 AM, Michael Pedersen <m.peder...@icelus.org> wrote:
> Agreed with both Alessando and Carlos. I missed grabbing the version,
> but that was an easy fix. I've added that in. Doing so meant creating
> all new tickets, though, so check the newly made tickets. All the old
> ones got closed.
Seems good so far, the only issues I see left is the module tags (as
mentioned earlier, but I think we can leave it as is) and testing with
splitting issues to multiple projects/repositories, but other than
that it seems nice enough to me.
As of now, I have begun the process of migrating to Github. This means
that all repositories and trackers for TG2 on Sourceforge are disbaled
for writing. Read will continue to work. In about a week, it is
expected that the repositories will be removed from SF as well,
leaving only the ticket tracker.
Once the migration is complete, I will post an update to this.
On Sun, Sep 23, 2012 at 8:58 PM, Michael Pedersen <m.peder...@icelus.org> wrote:
> As of now, I have begun the process of migrating to Github. This means
> that all repositories and trackers for TG2 on Sourceforge are disbaled
> for writing. Read will continue to work. In about a week, it is
> expected that the repositories will be removed from SF as well,
> leaving only the ticket tracker.
> Once the migration is complete, I will post an update to this.
I'm rather pleased by the results of this. I've updated the website,
I've updated SourceForge (pages and permissions), I've updated Github.
The repositories are all in place on Github, the issues have been
copied over, and everything belongs to the TurboGears organization on
Github.
The process was pretty painless. I've probably missed something, so if
somebody spots it, please let me know. As things stand, though, it
looks good, and looks like we can move forward again. Oh, and Carlos?
I see you've already forked the repo. Just glad i was done enough to
let you do so :)
Turns out that I *did* miss a few last minute updates from Alessandro.
You'll need to pull those in, just so you know (just added them a
couple mintues ago).
On Sun, Sep 23, 2012 at 10:27 PM, Carlos Daniel Ruvalcaba Valenzuela
<clsdan...@gmail.com> wrote:
> I saw the repo up and wanted to check it out, so far so good,
> everything seems to be working ok as far as the repositories on github
> goes.
> I can really see how this will simplify contributing to TG.
> Regards,
> Carlos Ruvalcaba
> --
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbogears@googlegroups.com.
> To unsubscribe from this group, send email to turbogears+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
Sorry I missed the move and pushed a few changes to sf.net.
I pushed the last remaining changes I did yesterday that were still
missing and now our full test suite passes on Python3.
I'll have to check it on Python2.6 and 2.7 to make sure that I kept
compatibility while moving forward (should be so, but didn't run the
testsuite on them yet since a few days ago)
On Mon, Sep 24, 2012 at 4:31 AM, Michael Pedersen <m.peder...@icelus.org> wrote:
> Turns out that I *did* miss a few last minute updates from Alessandro.
> You'll need to pull those in, just so you know (just added them a
> couple mintues ago).
> On Sun, Sep 23, 2012 at 10:27 PM, Carlos Daniel Ruvalcaba Valenzuela
> <clsdan...@gmail.com> wrote:
>> I saw the repo up and wanted to check it out, so far so good,
>> everything seems to be working ok as far as the repositories on github
>> goes.
>> I can really see how this will simplify contributing to TG.
>> Regards,
>> Carlos Ruvalcaba
>> --
>> You received this message because you are subscribed to the Google Groups "TurboGears" group.
>> To post to this group, send email to turbogears@googlegroups.com.
>> To unsubscribe from this group, send email to turbogears+unsubscribe@googlegroups.com.
>> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
> --
> You received this message because you are subscribed to the Google Groups "TurboGears" group.
> To post to this group, send email to turbogears@googlegroups.com.
> To unsubscribe from this group, send email to turbogears+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
On Mon, Sep 24, 2012 at 1:21 PM, Alessandro Molina
<alessandro.mol...@gmail.com> wrote:
> Sorry I missed the move and pushed a few changes to sf.net.
> I pushed the last remaining changes I did yesterday that were still
> missing and now our full test suite passes on Python3.
> I'll have to check it on Python2.6 and 2.7 to make sure that I kept
> compatibility while moving forward (should be so, but didn't run the
> testsuite on them yet since a few days ago)
My apologies. I thought I got the last of the changes from sf.net when
I did the move last night. I tried, anyway. Thank you for catching
that mistake, I really do appreciate it!
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:>.
