Community
Participate
Working Groups
ECF's IRC provider (org.eclipse.ecf.provider.irc) currently uses the IRCLib 1.10 as a jar. The IRCLib should be turned into a separate bundle, and that bundle added to the Orbit project as per it's expected format. ECF will then depend upon that new bundle, and remove dependency on the jar. See bug #166418 for previous discussion about IRCLib-based bundle.
Will this even be required since via comment #11 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=166418#c11), Christopher agreed to move over IRClib development to ECF as long as he can license it under both licenses. Have we come to a resolution over the license issue? If not, I can talk to Sharon or any of the IP staff over at the foundation to come up with the resolution. I don't think this will be a problem :)
Email contents below: -------------- Hi Janet, Question for you: If a contributor wants to make a contribution to a project under EPL, but would also like to distribute a library/plugin under other licenses as well (e.g. Apache 2) via other distribution vehicles (i.e. independent server/sourceforge, etc), is there any restriction from Eclipse Foundation preventing that? That is, is there anything in the EPL or by Foundation policy or convention that would prevent the author of the codebase from licensing it under other open source licenses? Thanksinadvance, Scott -------------- Hi Scott, No, none. In order to dual license effectively, the author would need to own all of the copyright or have the permission of all other copyright holders to license under any particular license. Any contributor to the project going forward would need to agree to license their contributions under both licenses. Keeping a record of the agreement of the contributors to dual license from a record keeping standpoint, would also help avoid potential difficulties down the road. Janet
looks like that problem is solved so I wouldn't see a need to put irclib into orbit, instead I would look into getting Christopher into ECF is everyone thinks that is the right direction.
(In reply to comment #3) > looks like that problem is solved so I wouldn't see a need to put irclib into > orbit, instead I would look into getting Christopher into ECF is everyone > thinks that is the right direction. > +1. Probably in org.eclipse.ecf/plugins module in CVS with appropriate project name (probably best to follow Orbit conventions anyway in this regard).
Awesome!!! How about org.eclipse.ecf/protocols? What's a good word for protocol specific impls? Maybe Remy would be interested in donating his unfinished MSN implementation also (seems like something fun to hack on). This could possibly spur some community contributions in the future.
btw, Remy and I were chatting about creating an ECF incubator for projects like this (protocol impls) that aren't 100% ready for ECF, but need to incubated a bit (along with the committers). PDE and Equinox are good examples of incubator projects (http://dev.eclipse.org/viewcvs/index.cgi/equinox-incubator/) What do you think Scott?
Hi Chris, (In reply to comment #6) > btw, Remy and I were chatting about creating an ECF incubator for projects like > this (protocol impls) that aren't 100% ready for ECF, but need to incubated a > bit (along with the committers). > > PDE and Equinox are good examples of incubator projects > (http://dev.eclipse.org/viewcvs/index.cgi/equinox-incubator/) > > What do you think Scott? I would personally be OK/happy with this, but I think the new development process may eliminate multiple project levels. Being discussed at BOD meeting tomorrow. We have been using OSU OSL for ECF...but would like to get away from this somehow. >
(In reply to comment #5) > Awesome!!! How about org.eclipse.ecf/protocols? > > What's a good word for protocol specific impls? I'm open to ideas too, but I think protocols/ will be the best most appropriate one, although possibly a little broad. > Maybe Remy would be interested in donating his unfinished MSN implementation > also (seems like something fun to hack on). This could possibly spur some > community contributions in the future. I have no problems with this. I was actually trying to implement the presence API with it last night. (In reply to comment #6) > btw, Remy and I were chatting about creating an ECF incubator for projects like > this (protocol impls) that aren't 100% ready for ECF, but need to incubated a > bit (along with the committers). This was raised because of the scenario I provided at [1]. I think this is a good solution for that scenario. (In reply to comment #7) > I think the new development process may eliminate multiple project levels. What is this "multiple project levels"? [1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=166418#c14
Sorry, didn't respond to this part before. In reply to comment #8) > (In reply to comment #5) > > Awesome!!! How about org.eclipse.ecf/protocols? > > > > What's a good word for protocol specific impls? > > I'm open to ideas too, but I think protocols/ will be the best most appropriate > one, although possibly a little broad. Having protocols as a CVS module would be fine, I think. I would like to keep the convention of having the project (and plugin) name for providers (implementers of ECF IContianer + any extension API) as org.eclipse.ecf.provider.<whatever> > > > Maybe Remy would be interested in donating his unfinished MSN implementation > > also (seems like something fun to hack on). This could possibly spur some > > community contributions in the future. > > I have no problems with this. I was actually trying to implement the presence > API with it last night. > > (In reply to comment #6) > > btw, Remy and I were chatting about creating an ECF incubator for projects like > > this (protocol impls) that aren't 100% ready for ECF, but need to incubated a > > bit (along with the committers). > > This was raised because of the scenario I provided at [1]. I think this is a > good solution for that scenario. > > (In reply to comment #7) > > I think the new development process may eliminate multiple project levels. > > What is this "multiple project levels"? Some projects now have, in essence, sub-projects...and therefore multiple 'levels'. This is a bit of a process problem, because the dev process (i.e. review, etc) doesn't know what to do with sub-projects (or sub-sub-projects), etc...and this apparently results in some sub-projects 'avoiding' project reviews, etc. http://wiki.eclipse.org/index.php/Development_Process_2006_Revision_Final > > [1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=166418#c14 >
(In reply to comment #9) > Having protocols as a CVS module would be fine, I think. I would like to keep > the convention of having the project (and plugin) name for providers > (implementers of ECF IContianer + any extension API) as > > org.eclipse.ecf.provider.<whatever> I don't have any qualms about this. I'm curious as to whether a new providers/ folder to place providers should be created for organization's sake...but that might be overdoing it. > Some projects now have, in essence, sub-projects...and therefore multiple > 'levels'. This is a bit of a process problem, because the dev process (i.e. > review, etc) doesn't know what to do with sub-projects (or sub-sub-projects), > etc...and this apparently results in some sub-projects 'avoiding' project > reviews, etc. > > http://wiki.eclipse.org/index.php/Development_Process_2006_Revision_Final Thanks for the explanation, Scott. I find it kind of hard to believe that one could actually "avoid" a review though, since I'd kind of expect a review to encompass everything.
If we are going through with this, we should submit the CQ as soon as possible because of the Europa deadline.
(In reply to comment #11) > If we are going through with this, we should submit the CQ as soon as possible > because of the Europa deadline. Oh wait, never mind, I totally forgot that the CQ for the library was already accepted. I guess what I meant to say was that we should push this into eclipe.org CVS soon.
(In reply to comment #12) > (In reply to comment #11) > > If we are going through with this, we should submit the CQ as soon as possible > > because of the Europa deadline. > > Oh wait, never mind, I totally forgot that the CQ for the library was already > accepted. I guess what I meant to say was that we should push this into > eclipe.org CVS soon. True. All this is waiting on is the 'bundleization' of the 1.10 irclib jar and following the orbit submission rules, etc. Scott
Setting target milestone to 1.2.0.
Resetting target milestone. It might be more productive for christoph to help with enhancements to IRCLib (i.e. 1.2 or further?)
addressed long ago
