Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Fri, Jul 1, 2011 at 1:29 PM, Laurens Van Houtven _...@lvh.cc wrote: As some of you may already know (either through a backchannel or because you talked to me at Europython), there has been some talk about moving Twisted way from Trac+SVN to somewhere that isn't Trac+SVN. There are always talks about moving here of there, because people are bored or it _seems_ to them that the other way of doing things is much better, because everybody else praises it. It is hard to resist this opinion. Some people even take it fundamentally - I won't commit, because its not in Git. The worst that it doesn't mean these people will participate if the project is be in Git, but a small percentage will. Problem with Git/Bazaar/Mercurial and DVCS in general is much higher contribution barrier. So, if you want to switch, you need to know _exactly_ why, and more importantly - which features are you going to miss. See below: A lot of the devs do like SVN. My guess is that that's mainly because they don't actually use SVN, they use Combinator, or something. On the other hand, I do think that Trac is pretty universally loathed, and it would be a good idea to get away from it. I believe nobody uses Combinator, because it is dead http://divmod.org/trac/wiki/DivmodCombinator SVN has one major flaw - you can not stack patches on your system naturally when you don't have write access to repository. I believe that's the major complain behind DVCS is better. Second problem - there in no _convenient_ way to share these patches to be reviewed and incorporated upstream. I do not think Trac is universally hated. It is the application one level above Python API as Twisted itself. Trac has its own architecture, different from standard OOP hierarchy. This architecture is not obvious and may be inconvenient to debug and extend. It may be that everybody is tired of Trac design, or Trac doesn't provide review and push/pull integration, but it has some other awesome features. There's a few existing hosting solutions: Launchpad (+ Bazaar as the default vcs) Bitbucket (+ Mercurial as the default vcs) Github (+ Git as the default vcs) I am not sure if the following possible with these services: L G B [ ] [ ] [ ] Project timeline with changes to wiki, tickets, commits etc, [ ] [ ] [ ] Editable issue description (Google Code suxx at this) [ ] [ ] [ ] Commit history navigation from patch view (next/prev buttons) [ ] [ ] [ ] Colored blame history browser [ ] [ ] [ ] Hook scripts for bots and other stuff [ ] [ ] [ ] Full project data export Unless someone is going to go all NO GITHUB IS TERRIBLE AND YOU ARE A BAD PERSON FOR EVEN SUGGESTING IT on me, maybe we can talk about planning the transition? :) To know if Github is terrible or not, you need some data - examples, use cases. The first step in planning is to look at the current workflow and gather a list of ways current Trac+SVN is used and see where Github has advantages and where it suxx. Usually, people realize the latter when it's too late. As we are all mostly too busy, if you want people to participate in discussions, it will be better to outline the features you need from development workflow and separate discussion with some summary about them into separate thread. Right now I see that there is a thread about reviews and as a Rietveld user, I may have a lot to say about that. =) -- anatoly t. ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 05, 2011 at 09:41:12AM +0300, anatoly techtonik wrote: To know if Github is terrible or not, you need some data - examples, use cases. The first step in planning is to look at the current workflow and gather a list of ways current Trac+SVN is used and see where Github has advantages and where it suxx. Usually, people realize the latter when it's too late. As has been mentioned in earlier in this thread: http://twistedmatrix.com/trac/wiki/WorkflowRequirements (which I have updated with some of the website requirements that Glyph mentioned in one of his posts). ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
Hi, just to note. If a move is preferred I give +1 for bitbucket (mercurial) If you ever want someone contributing under Windows, github with git is not a good solution. For Windows there are good clients for mercurial and bazzar. Git is more a Unix only solution. Launchpad has a horrible and unusable web ui so -1 on that. Also python has moved to mercurial and bitbucket catched up in features to github. Why should we move to a no Python system ? Regards, Wolfgang ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
Pretty much all of those can be supported with GitHub: they can POST to a generic website as a commit hook[0], along with a number of other integrated services[1]. The only thing that I can think of is that GitHub issues doesn't have hooks, so we'd have to poll if we wanted an IRC bot for GitHub issues. Thankfully, they have an API for issues[2] that should make it easier. re: Mercurial, I didn't like it when I used it. If someone can tell me how to do this[3] in hg, I'd be more inclined to play along. And that said, I think we'd get a much better reception and amount of contributors if we're on GitHub, if only due to the scale compared to LP/BB. I think we're all familiar with the denied story :). On Tue, Jul 5, 2011 at 2:49 AM, Tim Allen screwt...@froup.com wrote: On Tue, Jul 05, 2011 at 09:41:12AM +0300, anatoly techtonik wrote: To know if Github is terrible or not, you need some data - examples, use cases. The first step in planning is to look at the current workflow and gather a list of ways current Trac+SVN is used and see where Github has advantages and where it suxx. Usually, people realize the latter when it's too late. As has been mentioned in earlier in this thread: http://twistedmatrix.com/trac/wiki/WorkflowRequirements (which I have updated with some of the website requirements that Glyph mentioned in one of his posts). ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python [0] http://help.github.com/post-receive-hooks/ [1] https://github.com/github/github-services [2] http://developer.github.com/v3/issues/ [3] http://people.gnome.org/~federico/news-2008-08.html#git-rebase-interactive -- Jasper ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 05, 2011 at 03:42:04AM -0400, Jasper St. Pierre wrote: re: Mercurial, I didn't like it when I used it. If someone can tell me how to do this[3] in hg, I'd be more inclined to play along. And that I do this sort of things using mercurial queues. I pile up patches in a queue and can subsequently navigate in the queue (hg qgoto fix_header1) and fold it with a later one (hg qfold fix_header2). While the queue is not yet committed I can change the commit log of a patch in a simple way. hg qnew -f fix1 -m this fixed issue 1 hg qnew -I debian/control -m fix control hg qnew -f fix1.1 -m forgot something in issue 1 hg qgoto fix1 hg qfold fix1.1 # This concatenate the 2 comments hg qrefresh -e # fix your comment as you like it hg qpush hg qfinish -a # commit all queues currently applied sandro *:-) -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.orgSQLkit home page - PyGTK/python/sqlalchemy ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On 5 Jul 2011, at 10:31, Wolfgang wrote: If you ever want someone contributing under Windows, github with git is not a good solution. For Windows there are good clients for mercurial and bazzar. Git is more a Unix only solution. I have no vote on the whole moving off SVN, but as a former windows user I'd like to make it clear that git has absolutely no issues with Windows and it has been so for 3 years now. Either in cygwin or by using the (officially linked from the git home page) msysgit standalone package, you get a completely functional git CLI tool plus a completely functional and awesome gitk graphical interface. I've been using that for a full year (including git-svn) and it's been working completely fine. (Of course it may have other limitations that I'm not aware of, but I haven't come across them). Finally, for what it's worth, for me as a potential contributor to Twisted (I still want to help with documentation) SVN is a much bigger barrier of entry than Trac. Even an official git mirror (complete with branches) that I could work against would be hugely beneficial. Git has a lot of local graphical tools that you can use to search, browse history, do diffs and so on, so that Trac+git can be a viable solution, even without Trac-git integration. Orestis ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 5, 2011 at 9:31 AM, Wolfgang tds333...@gmail.com wrote: Hi, If you ever want someone contributing under Windows, github with git is not a good solution. Why not? I know the reasons three years ago (and most of them were either permissions or performance), but I have been assured multiple times that this is no longer the case at all. Also python has moved to mercurial and bitbucket catched up in features to github. Why should we move to a no Python system ? Because the community on Github is significantly larger. At some point, this devolves into bikeshedding. Twisted devs would prefer Launchpad, but many people hate Launchpad with a passion. Between Github and Bitbucket, as you've said yourself, Bitbucket is playing feature catch-up (whether they're doing that successfully or not is something I'm willing to skip discussing). I don't think features are the thing to differentiate the two on (even though I think Github wins because of polish). It's network effects. Github has more following, so it's more interesting. The thing is, it's not so much a vote. This is a do-ocracy. The breaks were I'll move it to Github, *or* someone stops me, not I'll move it to Github, or Bitbucket, or whatever else you folks think is a good idea. If people are going to try and stop me from moving it to Github, I'm not going to move it to Bitbucket or anything else. It's just going to stay Trac/SVN. Regards, Wolfgang cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 5, 2011 at 11:05 AM, Orestis Markou ores...@orestis.gr wrote: Finally, for what it's worth, for me as a potential contributor to Twisted (I still want to help with documentation) SVN is a much bigger barrier of entry than Trac. Even an official git mirror (complete with branches) that I could work against would be hugely beneficial. Git has a lot of local graphical tools that you can use to search, browse history, do diffs and so on, so that Trac+git can be a viable solution, even without Trac-git integration. Orestis Excellent! It looks like the Github *mirror* is going to be a thing, so that will at least make some of you happy. Unfortunately, it looks like the *move* (including tickets etc) to Github is never going to happen. I'm not going to elaborate. Someone else might. cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On 07/05/2011 06:05 PM, Orestis Markou wrote: On 5 Jul 2011, at 10:31, Wolfgang wrote: If you ever want someone contributing under Windows, github with git is not a good solution. For Windows there are good clients for mercurial and bazzar. Git is more a Unix only solution. I have no vote on the whole moving off SVN, but as a former windows user I'd like to make it clear that git has absolutely no issues with Windows and it has been so for 3 years now. Either in cygwin or by using the (officially linked from the git home page) msysgit standalone package, you get a completely functional git CLI tool plus a completely functional and awesome gitk graphical interface. I've been using that for a full year (including git-svn) and it's been working completely fine. (Of course it may have other limitations that I'm not aware of, but I haven't come across them). Most people who stay on windows do not find cygwin or even CLI tools an acceptable solution. I think it is fair to say that git is a very unixy tool, and windows not its strong point when compared against bzr or hg (and I say that as someone who find git UI significantly better and easier then either bzr or hg). The situation on windows is consistantly improving though, with tools like smartgit which feel much more native to the typical windows user/developer. cheers, David ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 5, 2011 at 12:22 PM, David da...@silveregg.co.jp wrote: Most people who stay on windows do not find cygwin or even CLI tools an acceptable solution. So, the argument isn't that git is worse on Windows than it is on *nix: it's just that Windows users don't want to use CLI tools? cheers, David cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] SURVEY: Have you submitted a patch to Twisted and it never got in?
On Tue, Jul 5, 2011 at 7:36 AM, Johan Rydberg johan.rydb...@edgeware.tvwrote: On 7/1/11 6:08 PM, Itamar Turner-Trauring wrote: In order to have at least some anecdotal evidence -- I've had some patched rejected, probably on sound basis. But the experience always leave you with a feeling that you got stabbed. Yes, this is terrible. How can we fix it? Sometimes it _is_ be better to get some basic functionality in place, instead of arguing about how things should be done the right way. From time to time you find a ticket that you want fixed, and start working on it, but end up never submitting it since you already know that even if it fixes the problem it will be shot down, since it doesn't do it this or that way. Well, I think everyone would agree that a system where it's easier to pick up such a half-finished thing that just needs some love would be better, regardless of whether that unfinished work should go into twisted or not. Right? cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] Ways to register stuff only done for backwards compatibility
Hi, In doing twisted.positioning I find my self writing a bunch of code in ways I would ordinarily write it differently, because we have to support 2.4 still (when is that going away? Isn't the most recent RHEL 2.6 already?). Is there some way to register that so that as soon as we stop supporting 2.4, we can make a lot of code a lot prettier? For certain functions such as any/all, perhaps a twisted.python._backports (with the explicit mention that code in backports will go away as soon as the version it's built to work around is no longer supported). That way, as soon as you support 2.5 (which has any/all), you just remove it from _backports, see which tests break, remove the imports, run tests again, commit. Woo! Of course, _backports is obviously not a solution for everything, since not every language feature can be fixed by defining a class or a function somewhere. cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On 12:32 pm, _...@lvh.cc wrote: Hi, In doing twisted.positioning I find my self writing a bunch of code in ways I would ordinarily write it differently, because we have to support 2.4 still (when is that going away? Isn't the most recent RHEL 2.6 already?). Is there some way to register that so that as soon as we stop supporting 2.4, we can make a lot of code a lot prettier? For certain functions such as any/all, perhaps a twisted.python._backports (with the explicit mention that code in backports will go away as soon as the version it's built to work around is no longer supported). That way, as soon as you support 2.5 (which has any/all), you just remove it from _backports, see which tests break, remove the imports, run tests again, commit. Woo! Of course, _backports is obviously not a solution for everything, since not every language feature can be fixed by defining a class or a function somewhere. Previously we've added things like this - socket.inet_pton, set, even dict long, long ago - to twisted.python.compat, which sounds similar to the _backports module you suggest. I didn't think of the addition of such things to a module as registration or I would have mentioned this when you asked before on IRC. :) Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
By registration I meant stuff where we could put reminders that some code can be cleaned up now. Perhaps that means ticket, if there's some way to mark a ticket as being only relevant when we stop supporting $PYTHON_VERSION_WHATEVER? cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On 01:41 pm, _...@lvh.cc wrote: By registration I meant stuff where we could put reminders that some code can be cleaned up now. Perhaps that means ticket, if there's some way to mark a ticket as being only relevant when we stop supporting $PYTHON_VERSION_WHATEVER? In the past we haven't tried too hard to do this kind of tracking, because we have actually avoided going out of our way to break Twisted in lots of ways for older versions of Python after we stop supporting them. Going through the codebase and making changing things to use Python 2.5 features *just* because we don't have to make the code run on Python 2.4 anymore is to be avoided. Instead, code can be updated to Python 2.5 syntax and APIs where changes are being made anyway and/or where the Python 2.5 version otherwise reduces the maintenance burden. Otherwise, it's just busywork from which no one really benefits. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Ways to register stuff only done for backwards compatibility
On Tue, 2011-07-05 at 14:32 +0200, Laurens Van Houtven wrote: In doing twisted.positioning I find my self writing a bunch of code in ways I would ordinarily write it differently, because we have to support 2.4 still (when is that going away? Isn't the most recent RHEL 2.6 already?). The plan was to drop 2.4 as of 11.2. At the rate things are going (someone review #5118 so I can merge it and put up #5063 for review!) we may not have 11.2 this year, only 11.1... in which case I'd be happy to drop 2.4 in this release. Others may disagree - discuss it here: http://twistedmatrix.com/trac/ticket/4962 ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] Twisted Project Jobs Volunteer
Hi, I have been using Twisted for about 6 months and looking for ways in which I could help the project. I just read the announcement and I would like to volunteer for one of the Twisted jobs. I am familiar with bzr and git and for the beginning I would like to start with maintaining the version control mirrors (bzr and git) and if this will not consume all my free time, I would also like to take care of buildbot master and slaves (or some other job that you consider is more important). Beside the job description, I was thinking that creating repositories mirrors on Github/Gitorious could be useful. The Launchpad BZR mirror seems to be functional. Hoping that I can be useful, please let know if my application is accepted. Cheers, -- Adi Roiban ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Twisted Project Jobs Volunteer
Hey, Cool, thanks for offering to chip in! I think buildbot management is more important, since I can manage github + wolfwood git mirrors pretty much on my own, and the launchpad mirror looks permanently up to snuff. cheers lvh ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Twisted Project Jobs Volunteer
On 05:56 pm, _...@lvh.cc wrote: Hey, Cool, thanks for offering to chip in! I think buildbot management is more important, since I can manage github + wolfwood git mirrors pretty much on my own, and the launchpad mirror looks permanently up to snuff. *Keeping* the Launchpad bzr mirror up to date is still a job we're trying to assign (that's why it's on the jobs page). Beyond that, it would be nice if more than just trunk were on Launchpad. As it is now, if you want to use Launchpad, you can't work on any branches people have made in svn. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] [Bug 775213] pymsnt 0.11.3-5 fails to start due to broken python-twisted-words 10.2.0-1 (AttributeError: 'module' object has no attribute '_parse')
On Jul 4, 2011, at 9:48 PM, Diane Trout wrote: Almost - I should have mentioned http://twistedmatrix.com/trac/wiki/TwistedDevelopment and http://twistedmatrix.com/trac/wiki/ReviewProcess first. When you put that branch on Launchpad, you'll need to put #4799 into review as well, as per that process; just link to the branch. Also, make it clear that you've volunteered for this work somewhere public, ideally in a ticket comment. Thanks again! Please don't hesitate to get in touch if you need any further guidance. Ok I have linked to my branch in http://twistedmatrix.com/trac/ticket/4799 Does that look right? is the next step to put review into 4799's keywords field? The next step is actually to make a backported patch specifically for http://tm.tl/4799, and get that merged into a release branch. The idea with the release ticket is that it's for the release notes and final QA; all the actual code should be complete in individual feature tickets first. I'm sorry - now I'm noticing that the workflow on the linked tickets (for example http://tm.tl/4786) is actually wrong for a maintenance release, as there's no cloned bug to indicate the backport. If I recall correctly, /branches/releases/release-10.2.0-4651-2 is the branch to merge things into for a 10.2.x maintenance release. At this point it would probably be good to get on the mailing list http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python and discuss these issues more publicly; someone else with more experience with the release toolchain can provide you more specific advice, and you'll get faster responses than from me personally. I'm Cc:ing this message to that list so that there will be some context when the discussion starts. I was going to recommend the IRC channel too, but I am told you've already been there; I hope I'll run into you there :). Also I don't know how to get the code changes out of launchpad and into your svn repository. A committer will do that, based on your branch. You may have to use our all-branches mirror to continue work, as Launchpad only mirrors trunk. Or, you may become an committer; we normally ask that people fix a few smaller bugs first, but given that you're volunteering to manage a release we may expedite that process :). Diane Once again I _really_ appreciate your time here. As you can probably tell, we rarely have the contributor bandwidth to do maintenance releases and so we're somewhat rusty at it. We like to provide a smooth upgrade process for our users though, so when we manage to get this pushed through it will be a big benefit to our XMPP users. Thanks, -glyph ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] SURVEY: Have you submitted a patch to Twisted and it never got in?
On Jul 5, 2011, at 1:36 AM, Johan Rydberg wrote: On 7/1/11 6:08 PM, Itamar Turner-Trauring wrote: In order to have at least some anecdotal evidence -- I've had some patched rejected, probably on sound basis. But the experience always leave you with a feeling that you got stabbed. We're always very grateful for contributions. I'm very sad to hear that you feel like you got stabbed. Sometimes it _is_ be better to get some basic functionality in place, instead of arguing about how things should be done the right way. Can you point to a specific ticket where you think this was the case? I have this same general feeling, but pretty much all of the reviews I found when I went looking for specific examples included at least some significant coding-standard, documentation, and test coverage problems. If we can find more specific examples, perhaps we can prevent this from recurring. I do agree that we don't want to block every ticket on the absolute best possible implementation; but, allowing changes that don't have test and documentation coverage is a recipe for creating an unmaintainable mess. Trust me, having dealt with Twisted in both modes, it's harder to get a patch into a release if the requirement is demonstrate to everyone that it doesn't break everything without tests and documentation. It's just that it moves the work from you, the contributor, to a special hell that the release manager inhabits for months of painful pre-release debugging, or users who notice that all their applications are broken and file lots of bugs. From time to time you find a ticket that you want fixed, and start working on it, but end up never submitting it since you already know that even if it fixes the problem it will be shot down, since it doesn't do it this or that way. In these cases it would be best to file the ticket and describe your potential solution before implementing it. You can even put the 'review' keyword on it to indicate that you want feedback from a contributor before proceeding. -glyph ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] server issues; SVN in read-only, but Trac isn't
On 5.7.2011 1:49, James Y Knight wrote: On Jul 4, 2011, at 7:06 PM, Glyph Lefkowitz wrote: Hello from the Twisted server operations team, The Twisted SVN server has run into some minor unexpected trouble during routine system maintenance. For now, SVN is in read-only mode. However, this shouldn't affect Trac, so feel free to keep doing reviews and submitting patches in the meanwhile. Hopefully many of you are working from DVCS mirrors and will hardly notice the interruption :-). We will send another notice as soon as things are back to normal. I believe it should be functional now. Please advise if anything seems broken. :) James Hello, It looks like the subversion commit mails to twisted-comm...@twistedmatrix.com list are not getting through for about a day. It would be great if they could be restored, I find them convenient to keep up with the Twisted development. Regards, Ziga ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] How do twisted and multiprocessing.Process create zombies?
Using twisted loopingcall, multiprocessing.Process, and multiprocessing.Queue; is it possible to create a zombie process. And, if so, then how? -- bitcycle ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] How do twisted and multiprocessing.Process create zombies?
On 09:51 pm, sean.m.oc...@gmail.com wrote: Using twisted loopingcall, multiprocessing.Process, and multiprocessing.Queue; is it possible to create a zombie process. And, if so, then how? Uh, why would you want to create zombies? Since Twisted installs a SIGCHLD handler, it's not unlikely that non- cooperating libraries that create subprocesses, such as the multiprocessing module, will miss their exit notification, leaving a zombie. If you *don't* want zombies, use reactor.spawnProcess (or a library on top of it, like Ampoule) instead. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 5, 2011 at 5:31 AM, Laurens Van Houtven _...@lvh.cc wrote: On Tue, Jul 5, 2011 at 12:22 PM, David da...@silveregg.co.jp wrote: Most people who stay on windows do not find cygwin or even CLI tools an acceptable solution. So, the argument isn't that git is worse on Windows than it is on *nix: it's just that Windows users don't want to use CLI tools? cheers, David cheers lvh Not in my opinion. I find hg, bzr, and svn all easier to use on Windows than git, and I use them all from the command line. For me the problem is that, while bash is certainly a superior language than Windows command language (a la cmd.exe), bash does not always map to Windows concepts/assumptions very nicely. This often leads to things occurring in unexpected (or at least unintuitive) ways (for Win32 users). Even though I use bash daily on Linux machines, I find using bash on Win32 painful (yes, even more painful than cmd.exe, which is really saying something!). Git requires bash. This makes it painful for me (on Windows). Also, Git _is_ worse on Windows than it is on *nix. It's just not as bad as it _used_ to be. It's functional. It works. But it is difficult to deal with, and a lot of Windows users I have talked to (as well as myself, of course) just don't like using it. I'm not necessarily saying that that means Twisted shouldn't use Git. But it _should_ be considered as a factor. Kevin Horn ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 5, 2011 at 22:19, Kevin Horn kevin.h...@gmail.com wrote: Git requires bash. This makes it painful for me (on Windows). In what sense? You can run git from cmd.exe, without having to deal with bash. (You're not required to use 'Git Bash'.) Also, Git _is_ worse on Windows than it is on *nix. It's just not as bad as it _used_ to be. It's functional. It works. But it is difficult to deal with, and a lot of Windows users I have talked to (as well as myself, of course) just don't like using it. Is there anything in specific that is difficult? I haven't had Windows-specific problems with Git on Windows, and I've been using it a lot. Ivan ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] How do twisted and multiprocessing.Process create zombies?
I like glyph's answer. :) http://stackoverflow.com/questions/6589225/how-do-twisted-and-multiprocessing-process-create-zombies/6589440#6589440 On Tue, Jul 5, 2011 at 3:00 PM, exar...@twistedmatrix.com wrote: On 09:51 pm, sean.m.oc...@gmail.com wrote: Using twisted loopingcall, multiprocessing.Process, and multiprocessing.Queue; is it possible to create a zombie process. And, if so, then how? Uh, why would you want to create zombies? Since Twisted installs a SIGCHLD handler, it's not unlikely that non- cooperating libraries that create subprocesses, such as the multiprocessing module, will miss their exit notification, leaving a zombie. If you *don't* want zombies, use reactor.spawnProcess (or a library on top of it, like Ampoule) instead. Jean-Paul ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python -- Sean | (206) 962-7954 ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 5, 2011 at 5:26 PM, Ivan Kozik i...@ludios.org wrote: On Tue, Jul 5, 2011 at 22:19, Kevin Horn kevin.h...@gmail.com wrote: Git requires bash. This makes it painful for me (on Windows). In what sense? You can run git from cmd.exe, without having to deal with bash. (You're not required to use 'Git Bash'.) Interesting. I was told (and had read) that it _was_ required. So I've been operating under that assumption. If you can run it in a cmd.exe window that _might_ relieve one of my pain points. Also, Git _is_ worse on Windows than it is on *nix. It's just not as bad as it _used_ to be. It's functional. It works. But it is difficult to deal with, and a lot of Windows users I have talked to (as well as myself, of course) just don't like using it. Is there anything in specific that is difficult? I haven't had Windows-specific problems with Git on Windows, and I've been using it a lot. Ivan Nothing terribly specific comes to mind, as I don't _use_ git very often. Only one of the projects I have ever contributed to uses git, and they just switched recently (from Mercurial, which makes very little sense to me as they are just about feature-equivalent). The others all use Mercurial, with the exception of Twisted. So when I started learning about DVCS, Mercurial was pretty much my introduction (aside: it seems to me that people in general seem to prefer whatever DVCS they were originally introduced to). Every couple of months I pull down a new release of git or TortoiseGit or whatever and tinker around with it, but it just isn't very nice compared to Mercurial. Maybe it will be someday. And it's not that anything is particularly _difficult_, so much as annoying. I find the CLI interface weird and clunky. I recall thinking some of the design decisions were not particularly good (though it's been long enough that I can't recall what they were exactly...and I have some complaints about the design of pretty much every DVCS out there, so...). These aren't Windows-specific issues of course, but when you add the Windows-specific issues on top of them, it just makes git that much worse to deal with. Of course, this is entirely subjective, and is totally my own opinion. Maybe the next time I update git it will annoy me less. As far as specific Windows-related issues, here's what I can come up with. These are all pretty vague, I'm afraid... - Let's start with installing. It would be really nice to be able to go to a website, download a package or archive or something, read some instructions and install git. Preferably with Tortoise-X-like Explorer shell integration (though I can live without that). I have never been able to do that. Instead, it's try the above, have it not work, search Google for a bunch of tutorial-style blog posts, try a bunch of stuff, maybe edit or move some files in whichever of several distributions I've had to download, and spend at least a couple of hours getting things working. At this point I'm already annoyed with git and I haven't even started using it yet. - Now I'm going to check things out. OK, fine. First hurdle is that terminology is different from what I'm used to, though that's hardly Git's fault, and I can deal with that. But in order to deal with the change in terminology, coming from Mercurial, I'd really like to see some nice online help. Last I checked, git totally failed in this area, and was noticeably worse on Windows than on *nix. (This was maybe 3 or 4 months ago). Ok, so now I'm having to search web/man pages for how to use git properly. Admittedly, some of this is necessary anyway for something as complex as a DVCS system, but it shouldn't be necessary for basic commands. I also seem to recall being annoyed by syntax for various commands actually being slightly _different_ on Windows than on *nix, but I can't say definitely that that was the case now (it was a long time ago, my memory is hazy, and I may have just misunderstood something). I have no idea if this is still a problem (assuming it ever really was). - I definitely miss Mercurial's friendly little warnings about when I might be about to screw things up. I doubt git will ever have anything like this. It seems antithetical to the git mindset. - Git just seems like it's second class citizen in the git world (this is true of a _huge_ number of open source projects, so it isn't just git, but I have a whole other rant about why this is a Bad Thing [tm] ). A lot of complaints about git on Win32 (which I find to be pretty valid complaints) I see answered with a sneer and something like: Oh sure, but that's what you get for using _Windows_. To sum up, I use both Windows and Linux. That is unlikely to change any time soon. I want my tools to work nicely and be polished in both environments. Git has not impressed me as being able to do this yet. Even if it ever does get to this point, I still probably won't like it as much as Mercurial, just
Re: [Twisted-Python] Moving Twisted off Trac and SVN to somewhere nicer
On Tue, Jul 5, 2011 at 5:02 AM, Alessandro Dentella san...@e-den.it wrote: On Tue, Jul 05, 2011 at 03:42:04AM -0400, Jasper St. Pierre wrote: re: Mercurial, I didn't like it when I used it. If someone can tell me how to do this[3] in hg, I'd be more inclined to play along. And that I do this sort of things using mercurial queues. I pile up patches in a queue and can subsequently navigate in the queue (hg qgoto fix_header1) and fold it with a later one (hg qfold fix_header2). Hm. So it's like quilt? Are patch queues real commits (changesets, revisions, whatever), so I can log and blame and grep them while I'm working? While the queue is not yet committed I can change the commit log of a patch in a simple way. hg qnew -f fix1 -m this fixed issue 1 hg qnew -I debian/control -m fix control hg qnew -f fix1.1 -m forgot something in issue 1 hg qgoto fix1 hg qfold fix1.1 # This concatenate the 2 comments hg qrefresh -e # fix your comment as you like it hg qpush hg qfinish -a # commit all queues currently applied Neato. This requires me to be in a queue *before* I fix my patch, right? sandro *:-) -- Sandro Dentella *:-) http://www.reteisi.org Soluzioni libere per le scuole http://sqlkit.argolinux.org SQLkit home page - PyGTK/python/sqlalchemy ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python -- Jasper ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
