Community
Participate
Working Groups
IRCLib 1.10 approved for distribution. Update ECF IRC provider to use latest version of IRCLib
As part of this, I would like to refactor out the IRClib into its own bundle. If people agree, I would like to call it 'org.eclipse.ecf.irc' or something like that ;) I've been thinking lately of encouraging ECF and contributors to start "clean-house" implementations of various protocols and incubate them in the ECF project so they can easily be found. By the graciousness of Christoph Schwering, we already have a good start on the IRC one. What are people's thoughts on this? Would Christoph approve and would like to maintain IRClib within ECF using Eclipse's facilities?
(In reply to comment #1) > As part of this, I would like to refactor out the IRClib into its own bundle. > If people agree, I would like to call it 'org.eclipse.ecf.irc' or something > like that ;) Are you planning to Orbit this? > I've been thinking lately of encouraging ECF and contributors to start > "clean-house" implementations of various protocols A noble cause, I still have my half-baked MSN implementation from almost a year ago. I'm probably going to do a rewrite from scratch later though since I want to cover the features of the new protocol and also allow it to run on Foundation runtimes. > and incubate them in the ECF > project so they can easily be found. I'm not sure I follow here. What is this "can easily be found"?
(In reply to comment #2) > > Are you planning to Orbit this? There is no reason to Orbit this if the code is actually being maintained in ECF CVS along with bugzilla tracking etc... Orbit is for code outside of Eclipse that needs to be "bundlized" > A noble cause, I still have my half-baked MSN implementation from almost a year > ago. I'm probably going to do a rewrite from scratch later though since I want > to cover the features of the new protocol and also allow it to run on > Foundation runtimes. True, I'm a dreamer here, but I think if we at least start somewhere, I think more contributors would be interested. Or we could seek people that have projects out there now and get them to a) license under EPL b) develop it under ECF This would take some evangelizing though ;) > I'm not sure I follow here. What is this "can easily be found"? By easily found I'm saying we would have all the EPL'd protocols out in one place (under ECF). This is probably a less important reason, but my goal is to foster a really healthy community in ECF around protocols ;) Also Remy, would you be willing to contribute the BT implementation (not the provider) to ECF and have the code developed / tracked using Eclipse facilities (ie., org.eclipse.ecf.bt?)
Hi Chris, (In reply to comment #1) > As part of this, I would like to refactor out the IRClib into its own bundle. > If people agree, I would like to call it 'org.eclipse.ecf.irc' or something > like that ;) I have no problem with this in general, but I think it would probably have/should be called org.schwering.irc.lib. > > I've been thinking lately of encouraging ECF and contributors to start > "clean-house" implementations of various protocols and incubate them in the ECF > project so they can easily be found. By the graciousness of Christoph > Schwering, we already have a good start on the IRC one. > > What are people's thoughts on this? I'm more than OK with this general idea (getting 'clean house' impls of various protocols behind ECF), but it's going to take some infusion of resources to ECF to make it actually happen. As project lead I simply can't reasonably commit to being able to doing a number of protocol implementations, along with exemplary apps, along with API design/development, etc., all in parallel. I would like to, don't get me wrong. > > Would Christoph approve and would like to maintain IRClib within ECF using > Eclipse's facilities? I think probably so.
Hi Chris, (In reply to comment #3) > (In reply to comment #2) > > > > Are you planning to Orbit this? > > There is no reason to Orbit this if the code is actually being maintained in > ECF CVS along with bugzilla tracking etc... Orbit is for code outside of > Eclipse that needs to be "bundlized" > > > A noble cause, I still have my half-baked MSN implementation from almost a year > > ago. I'm probably going to do a rewrite from scratch later though since I want > > to cover the features of the new protocol and also allow it to run on > > Foundation runtimes. > > True, I'm a dreamer here, but I think if we at least start somewhere, I think > more contributors would be interested. Or we could seek people that have > projects out there now and get them to a) license under EPL b) develop it under > ECF > > This would take some evangelizing though ;) You're not kidding about that. > > > I'm not sure I follow here. What is this "can easily be found"? > > By easily found I'm saying we would have all the EPL'd protocols out in one > place (under ECF). This is probably a less important reason, but my goal is to > foster a really healthy community in ECF around protocols ;) Yeah! > > Also Remy, would you be willing to contribute the BT implementation (not the > provider) to ECF and have the code developed / tracked using Eclipse facilities > (ie., org.eclipse.ecf.bt?) > Not intending to split hairs here, but probably: org.eclipse.ecf.provider.bt. There's already a bug to follow this: #144133
Is it possible to cc Christoph on this bug to see his comments? I'm willing to do the bundlization once we have approval and willingness from Cristoph. As for doing clean-room implementations of protocol, isn't it possible to start somewhere at least? Maintain EPL'd providers/protocol implementors in Eclipse CVS, while maintaining others at Oregon that don't meet the license requirements. In regards to Remy's BT impl, shouldn't it be split into two, the protocol impl along with the provider impl? I would imagine there be two bundles. This would allow people to download simply the protocol impl w/o the ECF specifics. Thoughts?
(In reply to comment #6) > Is it possible to cc Christoph on this bug to see his comments? Yeah, I added him with this. Christoph could you please look at this bug thread and see what you think? Thanks. > > I'm willing to do the bundlization once we have approval and willingness from > Cristoph. > > As for doing clean-room implementations of protocol, isn't it possible to start > somewhere at least? Maintain EPL'd providers/protocol implementors in Eclipse > CVS, while maintaining others at Oregon that don't meet the license > requirements. Yes. This is what we've been doing, for all intents and purposes. No reason not to continue. But we do need to focus on improving/developing a new exemplary application at this point, prior to 1.0 and Europa. So I've been personally trying to move away from working on providers in favor of improving/adding to the user interfaces. I think we should particularly focus on IRC, IM/chat, and buddy list/roster UI features so that we have really *good* clients for IRC/chat, IM, buddy list. > > In regards to Remy's BT impl, shouldn't it be split into two, the protocol impl > along with the provider impl? I would imagine there be two bundles. This would > allow people to download simply the protocol impl w/o the ECF specifics. > > Thoughts? Fine with me. Up to Remy. I only care about ECF filetransfer impl for bittorrent, but no reason not to expose bittorrent directly...modulo the additional work involved in supporting multiple APIs.
> Yeah, I added him with this. Christoph could you please look at this bug > thread and see what you think? Thanks. I've no objections against refactoring Chris's plans. I'd also like to maintain the IRClib bundle within ECF, so that I can easily synchronize the original IRClib with ECF's copy.
(In reply to comment #3) > Or we could seek people that have > projects out there now and get them to a) license under EPL b) develop it under > ECF Okay, Chris, if I'm reading you right, what you're saying is asking people to (re-/dual-)license their software under the EPL (or does it only need to be EPL-compatible?), and also completely migrate development to occur under the eclipse.org setup, yes? I ask since Christoph's comment #8 with "synchronize" and “copy” seems to imply that development still goes on wherever the project originally was at and the difference now is that they're committing on two repositories. Yuck! Christoph doesn't sound like he minds, but I would mind. So which is it, or is it something entirely different? > This would take some evangelizing though ;) No kidding, if what I think you're saying is correct (migrate to eclipse.org completely as above), you're going to have to give the developers some real good reasons for switching. For starters, they may have to switch RCSes, to CVS, of all things. *shudders* > Also Remy, would you be willing to contribute the BT implementation (not the > provider) to ECF and have the code developed / tracked using Eclipse facilities > (ie., org.eclipse.ecf.bt?) I am not a lawyer, does it matter that it's being dual-ed or do I have to use EPL solely? Don't mind if it's the latter but if that is the case I'll probably prepare and release a dual-ed package over at eclipse-incub before switching to EPL completely. (In reply to comment #5) > Not intending to split hairs here, but probably: org.eclipse.ecf.provider.bt. At the moment the implementation is named org.eclipse.bittorrent and the provider is named org.eclipse.ecf.provider.bittorrent. Can rename/shorten as necessary. (In reply to comment #7) > > In regards to Remy's BT impl, shouldn't it be split into two, the protocol impl > > along with the provider impl? I would imagine there be two bundles. This would > > allow people to download simply the protocol impl w/o the ECF specifics. > > > > Thoughts? > > Fine with me. Up to Remy. I only care about ECF filetransfer impl for > bittorrent, but no reason not to expose bittorrent directly...modulo the > additional work involved in supporting multiple APIs. I think this raises an interesting point with regards to this whole "having-protocol-implementations-under-ECF". Is this, really, the scope of this project? Do we want our bugzilla to start getting filled with bugs like "com.xyz.msn.Client suddenly stopped connecting!" (more often than not this is a server problem)? We've been lucky not to have people file bugs they've found in Jive Software's Smack library since I've started watching those ecf inbox email accounts, but there's nothing saying that this won't ever happen. In the scenario above, the “additional work” would probably solely revolve around the fact that people are going to go through ECF discussion channels to mouth off their problems with a protocol implementation instead of wherever the project used to be hosted at. At the end of day, the physical work will be done by the person that said “yes, I will move my project to ECF at eclipse.org”. Point being that if it wasn't hosted here and someone filed a bug, the implementor would fidget away and fix it. If it was filed over here, it would still be that person doing the work, except that everyone else watching ecf-core (or another inbox email) is notified and this may displease them because it doesn't really have anything to do with ECF (per se). Don't get me wrong, I think this is a great idea (putting all EPL'd protocols in one place per comment #3), but I think this is something that's worthy of discussion and analysis. Anyway, we should probably take this to dev.
(In reply to comment #9) > (In reply to comment #3) <stuff deleted> > > Okay, Chris, if I'm reading you right, what you're saying is asking people to > (re-/dual-)license their software under the EPL (or does it only need to be > EPL-compatible?), and also completely migrate development to occur under the > eclipse.org setup, yes? I ask since Christoph's comment #8 with "synchronize" > and “copy” seems to imply that development still goes on wherever > the project originally was at and the difference now is that they're committing > on two repositories. Yuck! Christoph doesn't sound like he minds, but I would > mind. Christoph is already triple licensing IRCLib under EPL, Apache 2, and LGPL (nothing implied in ordering ;-). I don't think the expectation would be that Christoph would have to commit to two repositories. The one at sourceforge (or wherever he prefers) would be primary, and all updates to others...e.g. dev.eclipse.org would have to be done off of that one. Unless Christoph wants to move the primary to dev.eclipse.org under ECF project (under EPL, of course)...which he is most welcome to do...but I'm not going to ask him to maintain changes in two locations. > > So which is it, or is it something entirely different? > > > This would take some evangelizing though ;) > > No kidding, if what I think you're saying is correct (migrate to eclipse.org > completely as above), you're going to have to give the developers some real > good reasons for switching. For starters, they may have to switch RCSes, to > CVS, of all things. *shudders* :-). Subversion is coming...but will be a while. > > > Also Remy, would you be willing to contribute the BT implementation (not the > > provider) to ECF and have the code developed / tracked using Eclipse facilities > > (ie., org.eclipse.ecf.bt?) > > I am not a lawyer, does it matter that it's being dual-ed or do I have to use > EPL solely? Don't mind if it's the latter but if that is the case I'll probably > prepare and release a dual-ed package over at eclipse-incub before switching to > EPL completely. IANAL either, but I think the decision about dualing or single license is up to the copyright holder (you). If it's main home is dev.eclipse.org though it has to be under EPL (at least). Actually, it would probably be best to ask Janet Campbell (EF legal) about dual licensing...I don't think it's a problem for EF, but honestly I'm not sure. email: janet.campbell at eclipse.org. Let me know if you would prefer if I contact her as the ECF project lead and I'll do so. > > (In reply to comment #5) > > Not intending to split hairs here, but probably: org.eclipse.ecf.provider.bt. > > At the moment the implementation is named org.eclipse.bittorrent and the > provider is named org.eclipse.ecf.provider.bittorrent. Can rename/shorten as > necessary. > > (In reply to comment #7) > > > In regards to Remy's BT impl, shouldn't it be split into two, the protocol impl > > > along with the provider impl? I would imagine there be two bundles. This would > > > allow people to download simply the protocol impl w/o the ECF specifics. > > > > > > Thoughts? > > > > Fine with me. Up to Remy. I only care about ECF filetransfer impl for > > bittorrent, but no reason not to expose bittorrent directly...modulo the > > additional work involved in supporting multiple APIs. > > I think this raises an interesting point with regards to this whole > "having-protocol-implementations-under-ECF". Is this, really, the scope of this > project? Do we want our bugzilla to start getting filled with bugs like > "com.xyz.msn.Client suddenly stopped connecting!" (more often than not this is > a server problem)? We've been lucky not to have people file bugs they've found > in Jive Software's Smack library since I've started watching those ecf inbox > email accounts, but there's nothing saying that this won't ever happen. I think this is inevitable. Note this problem isn't limited to ECF...in fact I think it's likely to be more accute and immediate for Orbit. It's happened several times recently with Mylar (http client) as well, and I'm sure it's happening with many other Eclipse projects. So, although I don't deny it's an issue, at least it's not an issue ECF has to face alone :). > > In the scenario above, the “additional work” would probably solely > revolve around the fact that people are going to go through ECF discussion > channels to mouth off their problems with a protocol implementation instead of > wherever the project used to be hosted at. At the end of day, the physical work > will be done by the person that said “yes, I will move my project to ECF > at eclipse.org”. Point being that if it wasn't hosted here and someone > filed a bug, the implementor would fidget away and fix it. If it was filed over > here, it would still be that person doing the work, except that everyone else > watching ecf-core (or another inbox email) is notified and this may displease > them because it doesn't really have anything to do with ECF (per se). Yes, all true. But as I said this problem exists more deeply as Eclipse uses more and more third party stuff (like Apache libs, etc). I'm thinking of bringing this up with the committer Board reps as I do think it's likely to be a growing problem (both because it makes more and more sense to use third party libs in Eclipse, and this will certainly be the result). > > Don't get me wrong, I think this is a great idea (putting all EPL'd protocols > in one place per comment #3), but I think this is something that's worthy of > discussion and analysis. Anyway, we should probably take this to dev. > Yeah, that would be fine.
(In reply to comment #10) > I don't think the expectation would be that Christoph would have to commit to > two repositories. The one at sourceforge (or wherever he prefers) would be > primary, and all updates to others...e.g. dev.eclipse.org would have to be done > off of that one. Unless Christoph wants to move the primary to dev.eclipse.org > under ECF project (under EPL, of course)...which he is most welcome to do...but > I'm not going to ask him to maintain changes in two locations. First of all, I'd like to move the primary development to ECF -- as long as I don't have to give up licensing IRClib under Apache 2 and LGPL additionally to EPL. I'm sorry my word choice was bad in my previous comment. I wouldn't use two repositories at once neither. What I wanted to point out is that, if I'd move IRClib's development to ECF (which I'd like to in general), I want to ensure that it's still licensed under LGPL, Apache 2, too, and I want to ensure that it won't disappear in the deepness of ECF's repository ;).
(In reply to comment #10) > Actually, it would probably be best to ask Janet > Campbell (EF legal) about dual licensing...I don't think it's a problem for EF, > but honestly I'm not sure. email: janet.campbell at eclipse.org. Let me know > if you would prefer if I contact her as the ECF project lead and I'll do so. I think it'd be better if you do it since I'm kind of a_random_person. Just CC me and Christoph given that he has a tri-licensing requirement wish as outlined in comment #11. Also, I think [1] is a good read about contributions to a project. That being, even if we move a protocol implementation here, can we really just "randomly" automatically give those developers committer rights? I think you all know what I'm trying to say here, it's a bit hard to put in words right now. [1] - http://dev.eclipse.org/newslists/news.eclipse.foundation/msg01353.html
Hi Remy, (In reply to comment #12) > (In reply to comment #10) > > Actually, it would probably be best to ask Janet > > Campbell (EF legal) about dual licensing...I don't think it's a problem for EF, > > but honestly I'm not sure. email: janet.campbell at eclipse.org. Let me know > > if you would prefer if I contact her as the ECF project lead and I'll do so. > > I think it'd be better if you do it since I'm kind of a_random_person. Just CC > me and Christoph given that he has a tri-licensing requirement wish as outlined > in comment #11. OK I sent a note to Janet and copied the two of you. > > Also, I think [1] is a good read about contributions to a project. That being, > even if we move a protocol implementation here, can we really just "randomly" > automatically give those developers committer rights? No. Like it says in [1], there are contributions and committers and one does not necessarily imply the other. OTOH...for folks that are interested in becoming committers and have already contributed significantly to ECF, as project lead I would have no objection to nominating both Christoph and Remy as committers for ECF. Of course, it's not entirely up to me...i.e. committer vote, Foundation check, etc are also required. >I think you all know what > I'm trying to say here, it's a bit hard to put in words right now. > > [1] - http://dev.eclipse.org/newslists/news.eclipse.foundation/msg01353.html >
Well, my point is that, okay, say I license some protocol implementation to EPL so there are no legal problems. 1. I make a bug and say "I contribute this code to ECF". 2. EF queries me during the IPzilla process and all is good. 3. It gets committed to eclipse.org's CVS repository. 4. A day later, I alter my code and says, "okay, this looks good, let's commit it". 5. Oh wait, I am not a committer, I can't do this myself, so I file a bug + patch. 6. Someone from ECF looks at it...and is generally confused because he or she is unfamiliar with my code (a_random_protocol_implementation_01). 7. I cannot update my code now that it's in eclipse.org because I have no committer rights and no committers knows my code enough to say "this looks good and safe". Okay, or we assume that 6 is void and the guy just says "okay if you think so" and commits it. That is "fine", but 5-6 keeps looping for infinity because I can't commit directly. If I am a freelance person and have wads of free time, this is going to be happen a lot, and is rather ugly. So how will this scenario be resolved?
assiging to slewis as will be able to do over next few days (12/12/2006)
IRCLib updated to 1.10 in org.eclipse.ecf.provider.irc. I'll close out this bug and create new one to handle task of migration if IRCLib to Orbit bundle. Updated version will be in 0.9.5 stable build of ECF targetted to 12/15/06 (In reply to comment #15) > assiging to slewis as will be able to do over next few days (12/12/2006) >
