Menu
▾
▴
pidgin-cabal — DO NOT USE. See https://pidgin.im/cgi-bin/mailman/listinfo/devel
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(28) |
May
(32) |
Jun
(11) |
Jul
(24) |
Aug
(94) |
Sep
(74) |
Oct
(71) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Sean E. <sea...@gm...> - 2006-08-22 20:29:42
|
On 8/22/06, Warren Togami <wt...@re...> wrote: > >> I think I can finish my changes to make things cancelable by Sunday. > >> Hopefully sooner. I guess we'll release beta4 a few days after that, assuming > >> everything seems stable. I have no objections to a pre-beta4 snapshot in > >> rawhide. That's actually probably a pretty good idea. I also have a few fixes and things I want in beta4. Sunday sounds like a good goal to aim for, but again, we'd want to give AOL a heads-up about the release. -s. |
|
From: Warren T. <wt...@re...> - 2006-08-22 16:51:43
|
Nathan Walp wrote: > Mark Doliner wrote: >> On Tue, 22 Aug 2006 12:03:54 -0400, Warren Togami wrote >> >>> Hey folks, >>> >>> Any status update on beta4? >>> >>> Should I push a pre-beta4 snapshot into rawhide in order to quickly >>> flush out obvious nasty bugs before the beta4? >>> >>> Warren Togami >>> wt...@re... >>> >> I think I can finish my changes to make things cancelable by Sunday. >> Hopefully sooner. I guess we'll release beta4 a few days after that, assuming >> everything seems stable. I have no objections to a pre-beta4 snapshot in >> rawhide. That's actually probably a pretty good idea. >> >> -Mark >> > I hope to have some Jabber tweaks in by then as well. Right now I'm on > a WLAN connection with about 25% packet loss, and Gaim has crashed > several times. I haven't been able to get a backtrace yet. If I get > anything useful I'll post it. > > That said, having some rawhide pre-testing would definitely be a good thing. > > -Nathan That reminds me... gaim has historically had stability problems (deadlocks and crashes) for me when in non-ideal network conditions. It may be interesting to do controlled testing with simulated packet drops and higher latencies in order to stamp out more of these corner case bugs. Warren Togami wt...@re... |
|
From: Nathan W. <fac...@fa...> - 2006-08-22 16:43:37
|
Mark Doliner wrote: > On Tue, 22 Aug 2006 12:03:54 -0400, Warren Togami wrote > >> Hey folks, >> >> Any status update on beta4? >> >> Should I push a pre-beta4 snapshot into rawhide in order to quickly >> flush out obvious nasty bugs before the beta4? >> >> Warren Togami >> wt...@re... >> > > I think I can finish my changes to make things cancelable by Sunday. > Hopefully sooner. I guess we'll release beta4 a few days after that, assuming > everything seems stable. I have no objections to a pre-beta4 snapshot in > rawhide. That's actually probably a pretty good idea. > > -Mark > I hope to have some Jabber tweaks in by then as well. Right now I'm on a WLAN connection with about 25% packet loss, and Gaim has crashed several times. I haven't been able to get a backtrace yet. If I get anything useful I'll post it. That said, having some rawhide pre-testing would definitely be a good thing. -Nathan |
|
From: Mark D. <ma...@ki...> - 2006-08-22 16:38:11
|
On Tue, 22 Aug 2006 12:03:54 -0400, Warren Togami wrote > Hey folks, > > Any status update on beta4? > > Should I push a pre-beta4 snapshot into rawhide in order to quickly > flush out obvious nasty bugs before the beta4? > > Warren Togami > wt...@re... I think I can finish my changes to make things cancelable by Sunday. Hopefully sooner. I guess we'll release beta4 a few days after that, assuming everything seems stable. I have no objections to a pre-beta4 snapshot in rawhide. That's actually probably a pretty good idea. -Mark |
|
From: Warren T. <wt...@re...> - 2006-08-22 16:04:09
|
Hey folks, Any status update on beta4? Should I push a pre-beta4 snapshot into rawhide in order to quickly flush out obvious nasty bugs before the beta4? Warren Togami wt...@re... |
|
From: Daniel A. <dan...@gm...> - 2006-08-22 15:03:53
|
On 8/22/06, Tim Ringenbach <om...@ho...> wrote: > We use Jira at work. I'm not sure if I'd recommend it though. (Plus it > costs money I believe). Although if someone else has used Jira and can > compare it to Trac and RT, that might give me a better idea about how > good they are. Tim beat me to it. I was actually starting to write an email about JIRA. We also use it where I work. It is really customizable, you can put together all sorts of reports and stuff and it is easy to search and use. From what I can tell, it does about everything that RT does and has a really polished interface. There are a large number of plugins, including an email interface, Subversion integration and Wiki integration - I'm not sure about other VCS, but the plugin interface is relatively simple. JIRA is not OSS, but they do have a free-beer "Open Source / Non Profit" license that we would certainly qualify for. Apache has an instance and a bunch of Apache subprojects are using it. FWIW, people here love it. I haven't actually used RT (or Trac very much at all), so I'm not really in a position to offer a meaningful comparison. -D |
|
From: Tim R. <om...@ho...> - 2006-08-22 14:40:23
|
Ethan Blanton wrote: > Mark Doliner spake unto us the following wisdom: >> Sounds like sourceforge and bugzilla have been eliminated. Between RT and >> Trac I vote for Trac. >> >> It's possible that Fogcreek would license FogBugz to us for free, but even if >> they did I think I'd still vote for Trac. The FogBugz website says, "Academic >> and Non Profit Organizations - Please contact us via email." > > A friend of mine whose opinion I greatly respect, and who I queried > about various trackers (because I know he has used them) provided this > comment on FogBugz, which I had not brought up -- he felt strongly > enough to volunteer it: > > Do not, under any circumstances whatsoever, even give > consideration to using the fucking abomination called "fogbugz". > > For the record, his response to "Do you like trac?": > > No, but I like it more than the others. [It's] got a boatload of > baggage with it, [wiki, svn browser, tickets, timelines]. It's > pretty nice with svn. > We use Jira at work. I'm not sure if I'd recommend it though. (Plus it costs money I believe). Although if someone else has used Jira and can compare it to Trac and RT, that might give me a better idea about how good they are. --Tim |
|
From: Ethan B. <ebl...@cs...> - 2006-08-22 13:18:29
|
Mark Doliner spake unto us the following wisdom:
> Sounds like sourceforge and bugzilla have been eliminated. Between RT and
> Trac I vote for Trac.
>=20
> It's possible that Fogcreek would license FogBugz to us for free, but eve=
n if
> they did I think I'd still vote for Trac. The FogBugz website says, "Aca=
demic
> and Non Profit Organizations - Please contact us via email."
A friend of mine whose opinion I greatly respect, and who I queried
about various trackers (because I know he has used them) provided this
comment on FogBugz, which I had not brought up -- he felt strongly
enough to volunteer it:
Do not, under any circumstances whatsoever, even give=20
consideration to using the fucking abomination called "fogbugz".
For the record, his response to "Do you like trac?":
No, but I like it more than the others. [It's] got a boatload of
baggage with it, [wiki, svn browser, tickets, timelines]. It's
pretty nice with svn.
Ethan
--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
|
|
From: Mark D. <ma...@ki...> - 2006-08-22 05:47:23
|
On Mon, 21 Aug 2006 23:22:34 -0400, Luke Schierer wrote > On Mon, Aug 21, 2006 at 09:32:49PM -0400, Ethan Blanton wrote: > > > > I have grown to be a big fan of integrated VCS/issue tracker, and I've > > never even actually used one. ;-) It just seems like so clearly the > > Right Idea that I can't believe how long it's taken to come around ... > > maybe I'll find that it's not all it's cracked up to be in practice, > > but I think this is a bonus for trac, myself. > > > > That said, you're our heaviest issue tracker user, and that certainly > > carries some weight in the decision process. > > > > Ethan > > I want to pick something that will be more used than the SF trackers > are, something that you all will be willing to interact with. If > that means it is slightly less ideal for me, the end result would > still be a big win for me, as tracker items would actually be closed, > merged, and so on regularly and consistently. For that reason I've > asked for opinions rather than just waiting to have my grubby hands > at a command prompt and experimenting. Though it might come to that > anyway, if for example I go to install one of them and find that its > confusing me to no end. > > luke Sounds like sourceforge and bugzilla have been eliminated. Between RT and Trac I vote for Trac. It's possible that Fogcreek would license FogBugz to us for free, but even if they did I think I'd still vote for Trac. The FogBugz website says, "Academic and Non Profit Organizations - Please contact us via email." -Mark |
|
From: Evan S. <ev...@dr...> - 2006-08-22 03:26:59
|
On Aug 21, 2006, at 11:22 PM, Luke Schierer wrote: > Though it might come to that > anyway, if for example I go to install one of them and find that its > confusing me to no end. Luke, if it'd be at all helpful for you, I'd be happy to make you an account on Adium trac. We've got a Waiting On Libgaim milestone that's a place we throw Gaim bug reports / crashes (on good days, with a link to the Gaim support tracker) which would make a fine real- world sandbox if you're so inclined. -Evan |
|
From: Luke S. <lsc...@us...> - 2006-08-22 03:21:38
|
On Mon, Aug 21, 2006 at 09:32:49PM -0400, Ethan Blanton wrote: > > I have grown to be a big fan of integrated VCS/issue tracker, and I've > never even actually used one. ;-) It just seems like so clearly the > Right Idea that I can't believe how long it's taken to come around ... > maybe I'll find that it's not all it's cracked up to be in practice, > but I think this is a bonus for trac, myself. > > That said, you're our heaviest issue tracker user, and that certainly > carries some weight in the decision process. > > Ethan I want to pick something that will be more used than the SF trackers are, something that you all will be willing to interact with. If that means it is slightly less ideal for me, the end result would still be a big win for me, as tracker items would actually be closed, merged, and so on regularly and consistently. For that reason I've asked for opinions rather than just waiting to have my grubby hands at a command prompt and experimenting. Though it might come to that anyway, if for example I go to install one of them and find that its confusing me to no end. luke |
|
From: Luke S. <lsc...@us...> - 2006-08-22 03:19:00
|
On Mon, Aug 21, 2006 at 09:32:49PM -0400, Ethan Blanton wrote: > Luke Schierer spake unto us the following wisdom: > > What bug tracking software have you all interacted with? What are > > the pros and cons? > > My analysis of both SF and bugzilla are very similar to yours. For > the record, however, I would take sf over bugzilla any day. > > > RT: it is unfamiliar to most people. I can interact with it via web > > or email or command line client. It offers a top down view of a bug, > > vrs. SF's bottom up view. It lets us control what users can set, > > without confusing them. Downside: changing things can take several > > pages in the web interface. it offers good filtering. It has an > > integratable faq tool (RTFM). I've used it before. > > What sort of changing takes several pages? If normal interactions > (create a bug, add a comment, close a bug) are simple, that's good > enough ... infrequent actions are welcome to be somewhat more > cumbersome. http://www.bestpractical.com/images/screenshots/rt/3.0/readticket.gif shows the basic interface for reading a bug. There are links for "resolve" (you do not close bugs as a developer, the submitter or (in the case of abandoned bugs) the system must do that.) and comment in the history and at the top of the page. You'd use the "people" link to reassign a bug. You'd use the "links" link to create bug dependencies or to merge bugs. Unmerging bugs doesn't work well when I use RT, it might have improved. You can directly take a bug you are viewing if you are logged in and have access. So to assign to yourself does not require a different page. the "history" link is mostly useless unless you are trying to figure out what someone else did with a bug. I might use it, I doubt many other people would. "Basics" lets you move a bug to a different queue, change the subject, and mess with priority. It also has some other options we wouldn't use. I doubt we'd use "Dates" "People" deals with who gets emails about this bug, who owns it (excepting the "take" option). I'd use this. HOPEFULLY you all would if I mis-assign something ;-) "links" is described above. "jumbo" is new, it wasn't there when I used RT. the docs say it has all of the above, plus the comment/reply fields. You can search for bugs, and save your search. This is essentially filtering the view of the bug queue. Its alot more flexible than the filters SF provides. There are "comments" and "replies." Comments are by default hidden from the requestor/submitter. IE when I want to ask one of you to look at something, there's no need to email the submittor. "replies" are by default visible to the submitter. You can tell it to include an article from RTFM, the faq manager, in a reply. This is essentially a more powerful canned responce system. more on this at http://wiki.bestpractical.com/index.cgi?ManualUsingWebInterface The email interface appears to be poorly documented, and I'd have to research this to provide examples of how to use it. The debian package rt3.4-clients might have some of the neccessary docs. For users, they would just reply to the email and the system would take care of it for them, ie reopening their bug if it was marked STALLED (SF pending). Similarly, it can be set to create new tickets from mail sent to an email address. This would have some problems, such as spam filtering, but it would be essentially replacing having Sean and I seeing emails in our inboxes where users ask for support directly, with the same spam management issues I would face anyway. It would be a merge of the various SF trackers and associated mailing lists. luke |
|
From: Sean E. <sea...@gm...> - 2006-08-22 01:47:28
|
On 8/21/06, Ethan Blanton <ebl...@cs...> wrote: > I have grown to be a big fan of integrated VCS/issue tracker, and I've > never even actually used one. ;-) It just seems like so clearly the > Right Idea that I can't believe how long it's taken to come around ... > maybe I'll find that it's not all it's cracked up to be in practice, > but I think this is a bonus for trac, myself. I've never used one, either. Here's the one thing I would love it for: I would love to go to a page with a list of patches, view them all inline, type in a commit message and click "Accept" to apply the patch and close the ticket in a single click. If Trac can do *that*, we are *so* taking it. -s. |
|
From: Ethan B. <ebl...@cs...> - 2006-08-22 01:32:53
|
Luke Schierer spake unto us the following wisdom: > What bug tracking software have you all interacted with? What are > the pros and cons? My analysis of both SF and bugzilla are very similar to yours. For the record, however, I would take sf over bugzilla any day. > RT: it is unfamiliar to most people. I can interact with it via web > or email or command line client. It offers a top down view of a bug, > vrs. SF's bottom up view. It lets us control what users can set, > without confusing them. Downside: changing things can take several > pages in the web interface. it offers good filtering. It has an > integratable faq tool (RTFM). I've used it before. What sort of changing takes several pages? If normal interactions (create a bug, add a comment, close a bug) are simple, that's good enough ... infrequent actions are welcome to be somewhat more cumbersome. > Trac: it integrates well with subversion. It doesn't seem to > integrate with any other verson control system. It doesn't seem to > let me interact with it by email. Its unfamiliar to most of us. Its > web interface has been praised by several people I've talked to who > have used it. There is a trac-monotone plugin. I have no idea how far along it is. As I believe I've mentioned before, I think monotone is a front-line contender (the front-line contender, for me) for a replacement VCS. As a bonus, they're getting pretty serious about collecting real-world usage scenarios and workflows and making sure they work -- one of the lead developers asked me the other day what issues I see blocking it as a switchover for Gaim, and what work flow issues I see with our development model. Even if we don't want to switch, they're very concerned about making it comfortable for as many people as possible. Oops, that turned into a monotone advertisement. We can probably find or create an email interface for trac, at least for use by developers if not the whole wide world. I agree that it would be nice to not have to load a web page to file comments on bugs/etc. > My own feeling is to go with RT/RTFM, primarily based on the fact > that I can interact with it by email and the fact that I've used it > before, and found it more usable than I do either SF or bugzilla. My > feeling about trac is that its a significant plus if we stick with > svn, but doesn't offer much over sf if we go with any other system. I have grown to be a big fan of integrated VCS/issue tracker, and I've never even actually used one. ;-) It just seems like so clearly the Right Idea that I can't believe how long it's taken to come around ... maybe I'll find that it's not all it's cracked up to be in practice, but I think this is a bonus for trac, myself. That said, you're our heaviest issue tracker user, and that certainly carries some weight in the decision process. Ethan --=20 The laws that forbid the carrying of arms are laws [that have no remedy for evils]. They disarm only those who are neither inclined nor determined to commit crimes. -- Cesare Beccaria, "On Crimes and Punishments", 1764 |
|
From: Evan S. <ev...@dr...> - 2006-08-22 01:13:39
|
We're using Trac extensively for Adium, and on the whole I've been really happy with it. I don't have any experience with the non- subversion version control integrations, but its integration with subversion, anyways, is extremely handy. I can write commit messages like: "Made seventeen tasty sandwiches - fixes #4523. Also, refs #4525, which suggests more food be available." and Trac puts the revision number (automatically linked to the changelog and diffs) with the message in both those two tickets, and closes ticket #4523. What else does it do well? It's easy to generate reports based on various criteria (ownership, milestone/target, etc.), and save them for later viewing. Its wiki-style pages (and support for the same formatting style make in tickets) make cross-talk between documentation, tickets, and changesets simple. Plugins, as Gary mentioned, make it quite expandable, and with css you can make it look the way you want. What doesn't it do well? The default configuration suffers one of the same problems Luke mentioned about sf.net's tracketers - anonymous users can set priority, severity, and milestone. I think this should be fairly easily changed with some hacking, but I haven't tried. It doesn't do inter-ticket dependencies the way bugzilla can handle (from what I've seen), so those have to be managed textually ("This ticket depends upon #2049" or whatever). -Evan |
|
From: Gary K. <gr...@re...> - 2006-08-21 23:29:59
|
Luke Schierer wrote: > Before I open this up to a wider and noisier audience on -devel, I > thought I'd ask here. > > What bug tracking software have you all interacted with? What are > the pros and cons? > > SF is poor: it provides users the ability to modify all sorts of > things they don't understand our use of, like priority or category. > Users regularly do things like think that "logging" means "starting > gaim." It offers poor filtering abilities, and its view of the bug's > history is less than ideal. I cannot interact with it via email. I've already migrated guifications off of sourceforge, that alone says something ;) > Bugzilla is in my opinion worse. It offers insufficient history in > many cases, unless I obsessively save emails. It is simply too huge > for our needs, being better at handling something like gnome or > redhat with tons of unrelated or semi-related projects than something > like gaim. It is UBBER confusing. Totally overkill. > RT: it is unfamiliar to most people. I can interact with it via web > or email or command line client. It offers a top down view of a bug, > vrs. SF's bottom up view. It lets us control what users can set, > without confusing them. Downside: changing things can take several > pages in the web interface. it offers good filtering. It has an > integratable faq tool (RTFM). I've used it before. Haven't used it. > Trac: it integrates well with subversion. It doesn't seem to > integrate with any other verson control system. It doesn't seem to > let me interact with it by email. Its unfamiliar to most of us. Its > web interface has been praised by several people I've talked to who > have used it. Trac does support other SCMs, you just need a plugin for it. To the best of my knowledge, the only one that is "mature" is the subversion one. Although, to be completely honest, I haven't tried the others. Another plus about trac is that it's stupid simple to write plugins for it, which of course gives us a lot of options for improving the interface and so on. Also, there are already a bunch of preexisting plugins for trac up at http://trac-hacks.org/. Unfortunately, many of them leave a lot to be desired. > My own feeling is to go with RT/RTFM, primarily based on the fact > that I can interact with it by email and the fact that I've used it > before, and found it more usable than I do either SF or bugzilla. My > feeling about trac is that its a significant plus if we stick with > svn, but doesn't offer much over sf if we go with any other system. > > luke -- Gary Kramlich <gr...@re...> |
|
From: Luke S. <lsc...@us...> - 2006-08-21 22:00:16
|
Before I open this up to a wider and noisier audience on -devel, I thought I'd ask here. What bug tracking software have you all interacted with? What are the pros and cons? SF is poor: it provides users the ability to modify all sorts of things they don't understand our use of, like priority or category. Users regularly do things like think that "logging" means "starting gaim." It offers poor filtering abilities, and its view of the bug's history is less than ideal. I cannot interact with it via email. Bugzilla is in my opinion worse. It offers insufficient history in many cases, unless I obsessively save emails. It is simply too huge for our needs, being better at handling something like gnome or redhat with tons of unrelated or semi-related projects than something like gaim. It is UBBER confusing. RT: it is unfamiliar to most people. I can interact with it via web or email or command line client. It offers a top down view of a bug, vrs. SF's bottom up view. It lets us control what users can set, without confusing them. Downside: changing things can take several pages in the web interface. it offers good filtering. It has an integratable faq tool (RTFM). I've used it before. Trac: it integrates well with subversion. It doesn't seem to integrate with any other verson control system. It doesn't seem to let me interact with it by email. Its unfamiliar to most of us. Its web interface has been praised by several people I've talked to who have used it. My own feeling is to go with RT/RTFM, primarily based on the fact that I can interact with it by email and the fact that I've used it before, and found it more usable than I do either SF or bugzilla. My feeling about trac is that its a significant plus if we stick with svn, but doesn't offer much over sf if we go with any other system. luke |
|
From: Gary K. <gr...@re...> - 2006-08-18 23:16:47
|
Sean Egan wrote: > On 8/18/06, Evan Schoenberg <ev...@dr...> wrote: >> As mentioned by others, it'd be good to have the libgaim target part >> of Sadrul's SoC project in 2.0.0. > > I'm willing to say we should commit it and worry about any subsequent > problems after the fact, barring any objections, that is. > > Also, this is more appropriate for gaim-devel, which I would CC if it > didn't give away the existence of the cabal! Feel free to resend it > there, Evan, and we can pretend like this never happened... If we're killing off the v2_0_0 branch, then there is no need to halt this anymore. Run the script, use the patches, and commit. Then we still have a bunch of configure.ac hacking, but the hardest parts will be over. -- Gary Kramlich <gr...@re...> |
|
From: Sean E. <sea...@gm...> - 2006-08-18 20:57:15
|
On 8/18/06, Evan Schoenberg <ev...@dr...> wrote: > As mentioned by others, it'd be good to have the libgaim target part > of Sadrul's SoC project in 2.0.0. I'm willing to say we should commit it and worry about any subsequent problems after the fact, barring any objections, that is. Also, this is more appropriate for gaim-devel, which I would CC if it didn't give away the existence of the cabal! Feel free to resend it there, Evan, and we can pretend like this never happened... |
|
From: Evan S. <ev...@dr...> - 2006-08-18 20:50:43
|
As mentioned by others, it'd be good to have the libgaim target part of Sadrul's SoC project in 2.0.0. I have locally the patch which Sadrul and Gary constructed to do the restructure. The resulting tree is: core/ plugins/ gtk/ plugins/ pixmaps/ sounds/ win32/ console/ plugins/ In a conversation about this, Sadrul said to me: "This would both do the tree-restructure, and make the appropriate targets for libgaim, gaim (ala gtkgaim) and gntgaim. The script and the patches were then tested by a few people, including Luke, and it was working. There were some other concerns which I didn't really 'get'. Ethan, Luke and Gary talked over it, and decided on something. I am not sure what exactly the decision was, but I haven't heard anything on this, nor have seen anyone working on this since then." One concern I have is that such a move makes all local changes on all trees slightly problematic... Folks will need to something along the lines of svn diff -r version_before_move > myChanges.diff patch -p0 < myChanges.diff which isn't difficult, but is obnoxious. Merges to an old branch would also be difficult -- definitely will be best if the decision is to release off trunk rather than the 2.0.0 branch. -Evan |
|
From: Sean E. <sea...@gm...> - 2006-08-18 16:42:03
|
On 8/16/06, Sean Egan <sea...@gm...> wrote: > So, domain names. Thanks to an anonymous donor, we now own pidgin.im! Thanks again, anonymous donor! I'm working with Stephen Garrity to find someone who can update our webpage (he's too busy to do it himself, unfortunately). When Luke gets back, we should start talking about the tools we want to run on pidgin.im. -s. |
|
From: Sean E. <sea...@gm...> - 2006-08-16 19:06:16
|
On 8/16/06, Warren Togami <wt...@re...> wrote: > Do you have a 501(c)3? I'd even donate that much or more if I could get > the tax deduction. We're working on it. -s. |
|
From: Warren T. <wt...@re...> - 2006-08-16 18:49:02
|
I personally think shorter domain names are particularly attractive and effective. pidgin.im would get my vote. Do you have a 501(c)3? I'd even donate that much or more if I could get the tax deduction. Warren Togami wt...@re... Sean Egan wrote: > So, domain names. http://pidgin-im.[com|org|net] seems reasonable. It > reminds me a bit too much of Miranda, though. > > Luke says that .im domains go for 40 pounds/yr; I wouldn't mind paying > that out of my own pocket. pidgin.com is squatted; we could see how > much they want. > > Someone above mentioned purplepidgin.com. We could play on the homing > pidgin thing and grab homingpidgin, messengerpidin, carrierpidgin or > something. > > I think pidgin-im is probably the best choice. > > -s. > > On 8/14/06, Sean Egan <sea...@gm...> wrote: >> Just FYI, the lawyers did a more thorough check on Pidgin. They found this: >> A self-learning cross lingual interface based at the University of >> Twente in the Netherlands, but some of the links are broken and the site >> hasn't been updated since 2003: >> http://hmi.ewi.utwente.nl/Projects/pidgin.html >> >> Fotopages, a photo sharing site, appears to be run by a company called >> Pidgin Technologies Ltd, though they seem to be focusing on the >> Fotopages name. I don't see any social networking or chat components here. >> http://pidgintech.fotopages.com/ >> >> Pidgin Productions, "Producers Integrated Development Group, Initiatives >> and Network", is a non-profit in England focused on promoting cultural >> diversity in moving image media >> http://www.pidgin.org.uk/ >> >> Pidgen ML is a core subset of the Objective Caml programing language: >> http://www.inria.fr/rapportsactivite/RA2005/signes/uid40.html >> >> The Pidgen Compiler is a retired tool of Cornell University's Computer >> Science Department's Intelligent Software Systems: >> http://iss.cs.cornell.edu/p.aspx >> >> None of these projects are considered a bar from us using the name Pidgin. >> >> -s. >> |
|
From: Sean E. <sea...@gm...> - 2006-08-16 18:41:11
|
So, domain names. http://pidgin-im.[com|org|net] seems reasonable. It reminds me a bit too much of Miranda, though. Luke says that .im domains go for 40 pounds/yr; I wouldn't mind paying that out of my own pocket. pidgin.com is squatted; we could see how much they want. Someone above mentioned purplepidgin.com. We could play on the homing pidgin thing and grab homingpidgin, messengerpidin, carrierpidgin or something. I think pidgin-im is probably the best choice. -s. On 8/14/06, Sean Egan <sea...@gm...> wrote: > Just FYI, the lawyers did a more thorough check on Pidgin. They found this: > A self-learning cross lingual interface based at the University of > Twente in the Netherlands, but some of the links are broken and the site > hasn't been updated since 2003: > http://hmi.ewi.utwente.nl/Projects/pidgin.html > > Fotopages, a photo sharing site, appears to be run by a company called > Pidgin Technologies Ltd, though they seem to be focusing on the > Fotopages name. I don't see any social networking or chat components here. > http://pidgintech.fotopages.com/ > > Pidgin Productions, "Producers Integrated Development Group, Initiatives > and Network", is a non-profit in England focused on promoting cultural > diversity in moving image media > http://www.pidgin.org.uk/ > > Pidgen ML is a core subset of the Objective Caml programing language: > http://www.inria.fr/rapportsactivite/RA2005/signes/uid40.html > > The Pidgen Compiler is a retired tool of Cornell University's Computer > Science Department's Intelligent Software Systems: > http://iss.cs.cornell.edu/p.aspx > > None of these projects are considered a bar from us using the name Pidgin. > > -s. > |
|
From: Sean E. <sea...@gm...> - 2006-08-16 17:49:21
|
I'm asking the lawyers about whether we can release a beta4 and other maintenance releases. -s. |
