Firstly, Roger, sorry for just forwarding this on to the list, but you''re not the only one to ask, so... As much as it would assist me using github (much cheaper branches, and I''d be using 6 or 7 of them right now), what I am afraid of (and in fact this happened already), is that a non-synced mirror will simply split the project and lead to increased overhead and code management. Typical example: About 1 month ago I tried to get a copy of ''ticgit-watchtower'' working (see on github). Now the app worked, but I wanted the simplest of simple authentication in front to use for a distributed tracker for a particular task. I searched and I searched for a copy of sinatra that was either a) properly integrated with rack, or b) at least would boot the app without errors. Turns out, at that particular time, that the projects wiki had been broken by some lovely person. The github project was tracking a version 2 behind the gem, and contained (to my knowledge of the project at the time), some broken code. The ''official gem'' itself seemed actually older than the github repository (iirc it wasn''t even on top of rack). The problem in the above story is not that there wasn''t production ready code available (on the contrary, I''ve since spoken to the lead, and found the right code), it was that as an outsider, someone who didn''t know the projects details, I had no way (within a few hours) of deciphering which code should work, and why that wasn''t working. As the number of forks increases, it can become increasingly difficult for new users to get into the project, being awash with different code bases and reliability all over the place. The issue that is arising for a number of projects is the divergence of release cycles and developer attention by the use of DVCS. We have to be careful with this, I for one, and I know others do, run production code on EventMachine day in day out. To have patches ''sneaking in'' by overzealous merging can be dangerous - indeed this already happened when we tried the move before. Now as I said, I''ve been asked before, and in fact we did get it up on github. More than that, at Amans request I started doing patchwork inside a fork that I started under my account. That night, Francis committed similar patches to the svn repository. The repositories were then out of sync, and we didn''t have the git-svn clone with which to sync/merge them. I threw some patches out the next morning, and felt real good about staying up late to finish them... As I''ve said to Aman on this topic, I''d be more than happy to help set this up, I''d love to be working off of git instead, but fragmenting the project at this point is dangerous, especially with a high workload, and low commit rate that we''re currently having to put up with whilst the team get through their busy lives. Base minimum requirements for any github mirror are: - It must be synced in real time with the svn repo (this may require merge failure notifications, we need to policy that on the merge server side). - We must maintain a full formal release cycle (many projects are neglecting release cycles after the move to github, I can''t live on "edge" from "trunk" for all my apps, sorry). - Please consult with branch owners / developers to ensure that the correct code is cloned into the correct places. The worst of what happened previously was an experimental patch (which had actually been already backed out in the svn repo), ended up being merged forward into ''master'' in a github clone. At the time I was actually ready (in the svn, after the patches committed to github) for a merge forward of branches/raggi to trunk, but alas, I realised that the repository history was incorrect. Eventually I gave up, ported most of my patches back over to the svn repo, and blew away my fork on github. Besides all of that, there was no way for me to pull in to git, the changesets that were committed to the svn repo that very same night. I know this may seem like a bit of rant, please understand, I''m not here to upset anyone or point fingers, I''m here because I''ve said "I told you so" a couple of times already on this (I anticipated problems like we ended up having, and warned, and I was ignored). I''d like input and consideration given what I''m trying to explain. I''m very open to suggestions and assistance to get this stuff sorted out, but please do it properly, as otherwise I and others will be nothing but hindered by it. If no one steps up to sort out this infrastructure, then personally, I shall keep working out of the svn repository for the time being, and I will do the github mirror when I have some time to devote to that. One important question might be, would you rather I tackle github, or patch backlog first? (that''s a question for everyone). Thanks for reading, James. Begin forwarded message:> From: "Roger Pack" <roger.pack at leadmediapartners.com> > Date: 27 June 2008 02:37:01 BST > To: "James Tucker" <jftucker at gmail.com> > Subject: new git fork > > It might be a nice idea to create an ''edge'' git fork of the normal EM > branch. That we could all upload ''edgy'' stuff, like vital patches, > which patches apparently never make it to trunk otherwise. > Thanks! > -R
To avoid confusion with repositories, I would suggest having one ''overall responsible'' maintainer of the master git repo. Then if people want to do additions just have them do it on a new branch of their own. Or fork. Then do merge requests. Easiest would be to NOT try and sync with SVN at all, to avoid the [as you pointed out] confusion that can provide. But that''s just my opinion. My actual question was whether we should start a fork that would be something like ''experimental'' and that multiple people could contribute to, so it could be stronger. For example I submitted a patch from something like a year ago that is basically necessary for windows to work if you try and use > 64 sockets. It has never been committed, nor have I heard back from the maintainer, despite submitting it with tests, etc. I created a ticket a few days ago for a patch that enables code that raises during unbind to not kill EM [1]. And I don''t expect my patch to ever be accepted. So I was looking for an outlet where I could actually contribute to EM. Currently it is unstable and I am <cough> getting sick of it. Of course, I always say that and come back, but hey :) Thanks! -R> About 1 month ago I tried to get a copy of ''ticgit-watchtower'' > working (see on github). Now the app worked, but I wanted the > simplest of simple authentication in front to use for a distributed > tracker for a particular task. I searched and I searched for a copy > of sinatra that was either a) properly integrated with rack, or b) > at least would boot the app without errors. Turns out, at that > particular time, that the projects wiki had been broken by some > lovely person. The github project was tracking a version 2 behind > the gem, and contained (to my knowledge of the project at the time), > some broken code. The ''official gem'' itself seemed actually older > than the github repository (iirc it wasn''t even on top of rack).[1] http://rubyeventmachine.com/ticket/33 Ex: this causes EM to segfault or SIGILL: module SlowClosers @@total_closed = 0 def unbind @@total_closed += 1 raise LocalJumpError.new() if @@total_closed == 2 end end class DeathEnd < Test::Unit::TestCase def test_ends_well_multi_thread begin EM::run { 3.times {EM::connect ''127.0.0.1'', 6000, SlowClosers} } rescue LocalJumpError # we should get here--if it errs it will err with a ''HARD'' c-style error or segfault. which is hard for a unit test, but hey :) end end end
On 30 Jun 2008, at 17:09, Roger Pack wrote:> To avoid confusion with repositories, I would suggest having one > ''overall responsible'' maintainer of the master git repo. > > Then if people want to do additions just have them do it on a new > branch of their own. Or fork. Then do merge requests. Easiest > would be to NOT try and sync with SVN at all, to avoid the [as you > pointed out] confusion that can provide. > But that''s just my opinion.That sounds fine, too, but it needs to go both ways, and ideally quite rapidly. An auto-sync is not too hard to achieve especially if you lock on error. We can cherry-pick and manually resolve conflicts quite easily, but at the moment it''s developer time that is in high demand. On that note:> My actual question was whether we should start a fork that would be > something like ''experimental'' and that multiple people could > contribute to, so it could be stronger.Absolutely I want to do that, and encourage it. What I don''t want to do is halt other development by increasing code management overhead, however:> For example I submitted a patch from something like a year ago that > is basically necessary for windows to work if you try and use > 64 > sockets. It has never been committed, nor have I heard back from > the maintainer, despite submitting it with tests, etc.I have quite a big list of tickets at the moment, which I am going to work through some of them tonight. Please do assign any tickets (and outstanding patches, on this note, Aman Gupta has been an absolute star recently) you have to me (raggi on trac) and I will get to them as soon as I have time, and they will be merged and/or committed as appropriate. I run anything heading for trunk by Francis first, but if I am at all confident it will get committed to my branch immediately, and a subsequent ticket for signing off will be created.> I created a ticket a few days ago for a patch that enables code that > raises during unbind to not kill EM [1]. > > And I don''t expect my patch to ever be accepted.Please keep sending them in, I will get to them as soon as I can, as I say. I am sure Francis will be feeling the same.> So I was looking for an outlet where I could actually contribute to > EM. Currently it is unstable and I am <cough> getting sick of it. > Of course, I always say that and come back, but hey :)Well, I''m glad to have you around, you know EM better than most of us, and your contributions are appreciated. I run production ruby & EM stuff on win32 too, I know your pain.> Thanks! > -R >
>Absolutely I want to do that, and encourage it. What I don''t want to do is halt other development by increasing code management overhead, however:Create the fork and give me write access and I will commit all my patches to it.> I have quite a big list of tickets at the moment, which I am going to work > through some of them tonight. Please do assign any tickets (and outstanding > patches, on this note, Aman Gupta has been an absolute star recently) you > have to me (raggi on trac) and I will get to them as soon as I have time, > and they will be merged and/or committed as appropriate. I run anything > heading for trunk by Francis first, but if I am at all confident it will get > committed to my branch immediately, and a subsequent ticket for signing off > will be created.I have submitted tickets. Thanks for working on them!> Well, I''m glad to have you around, you know EM better than most of us, and > your contributions are appreciated. I run production ruby & EM stuff on > win32 too, I know your pain.Thanks! -R