Community
Participate
Working Groups
ECF has implemented the OSGi 4.2 remote services specification (chap 13)...e.g. see http://eclipseecf.blogspot.com/ and we are nearly completed with implementing the OSGi 4.2 enterprise Remote Service Admin (RSA) specification (chap 122...see bug 324215. We are lacking resources to pay for network-based testing of remote services/RSA. We could either use our own/EF hardware (if available), or cloud services (e.g. Amazon), but our committers do not have resources to pay for such testing resources themselves, and ECF is not a corporate-controlled project. So the main usage for ECF would be to pay for either hardware and/or cloud-based services for network-based testing of OSGi remote services. Another possible usage would be that we have traditionally had a great deal of interest from students in ECF-based summer of code projects. Recently, we do not have sufficient support for mentoring time/mentors to meet these student desires. Further we have some previous student projects (e.g. ECF-based Google Wave provider...see: http://wiki.eclipse.org/Google_Wave_ECF_provider where the student and the community would like this work to be integrated into ECF itself, but has been unable to do so because of the student's time/resource limitations. Further Foundation resources could make help us address this community need.
Hi Scott. Sorry, but hiring additional resources is a non-starter. Unfortunately, we do not have enough money to hire anyone. We can, however, provide student payments along the lines of what Google Summer of Code does. Is that something you'd like to pursue?
(In reply to comment #1) > Hi Scott. Sorry, but hiring additional resources is a non-starter. Given the current EF approach to the projects, I knew that was true...but who said hiring? What I said/requested was student support...as ECF has always had a great deal of interest in contributors as part of the Google Summer of Code. That support could come through $$ payments as per GSOC...or it could come from support for mentoring (i.e. people like you or other committers actually doing project mentoring...since our committers aren't able to meet that support need without crippling actual development and/or going broke). > Unfortunately, we do not have enough money to hire anyone. Yeah, I'm not surprised. >We can, however, > provide student payments along the lines of what Google Summer of Code does. Is > that something you'd like to pursue? It depends upon whether I (or other existing committers) have to do all the actual work...i.e. for student support. If so, then no...as like I said, our committers don't have enough time resources to do this...and this is the real cost of student efforts in a project (as opposed to $$ payments to the student). If the EF can actually do something to support the student involvement...so that it doesn't just fail for lack of support, then yes, I would like to persue that.
Shouldn't this be split into two different bugzillas? One for the hardware/computing time request. The other for "student support"
We have money that we can potentially use to fund student work. We do not have any resources or bandwidth to find students on your behalf or manage their work. Before we can make any decisions, we need to have specifics and an actual figure. What hardware do you need and how much money do you need for the purchase? Where will it live? How much money do you need for the student and who will manage their work?
(In reply to comment #3) > Shouldn't this be split into two different bugzillas? > > One for the hardware/computing time request. > > The other for "student support" Fine with me.
(In reply to comment #4) > We have money that we can potentially use to fund student work. We do not have > any resources or bandwidth to find students on your behalf or manage their > work. Ok...forget the student support request then. > > Before we can make any decisions, we need to have specifics and an actual > figure. What hardware do you need and how much money do you need for the > purchase? To be able to test the remote services/rsa work...along with discovery. That implies > 1 system...because what this is all about is interprocess communication/testing...and testing on a single process just doesn't cut it. >Where will it live? Amazon/cloud would be fine with me. We can/could also probably get another system in at the OSU Open Source Lab (with free network costs), but I'm not sure about that.
(In reply to comment #6) > Amazon/cloud would be fine with me. We can/could also probably get another > system in at the OSU Open Source Lab (with free network costs), but I'm not > sure about that. So, what are you asking for? USD$10 in Amazon cloud credits? USD$100? $500? $1000?
(In reply to comment #7) > (In reply to comment #6) > > Amazon/cloud would be fine with me. We can/could also probably get another > > system in at the OSU Open Source Lab (with free network costs), but I'm not > > sure about that. > > So, what are you asking for? USD$10 in Amazon cloud credits? USD$100? $500? > $1000? I don't know exactly, but I would guess 3 Amazon images on EC2 for a month (with expected bandwidth and disk usage...changing things in/out) would run < $1000/month.
(In reply to comment #4) > We have money that we can potentially use to fund student work. We do not have > any resources or bandwidth to find students on your behalf or manage their > work. What kind of requirements does the student have to provide? E.g. I'm a student as well as an ECF committer. Do I qualify for the student program?
(In reply to comment #8) > I don't know exactly, but I would guess 3 Amazon images on EC2 for a month > (with expected bandwidth and disk usage...changing things in/out) would run < > $1000/month. Technically the Amazon cloud might not be what ECF needs (AFAIK it blocks multicast traffic even in the same security group). Does anybody know if other cloud providers allow multicast traffic between instances?
(In reply to comment #9) > (In reply to comment #4) > > We have money that we can potentially use to fund student work. We do not have > > any resources or bandwidth to find students on your behalf or manage their > > work. > > What kind of requirements does the student have to provide? E.g. I'm a student > as well as an ECF committer. Do I qualify for the student program? We're new at this, so we'll have to work that out. We are constrained by the bylaws of the Eclipse Foundation, so we may need a ruling from the EMO(ED).
(In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #4) > > > We have money that we can potentially use to fund student work. We do not have > > > any resources or bandwidth to find students on your behalf or manage their > > > work. > > > > What kind of requirements does the student have to provide? E.g. I'm a student > > as well as an ECF committer. Do I qualify for the student program? > > We're new at this, so we'll have to work that out. We are constrained by the > bylaws of the Eclipse Foundation, so we may need a ruling from the EMO(ED). So what do I/we have to do to get this started?
(In reply to comment #12) > > We're new at this, so we'll have to work that out. We are constrained by the > > bylaws of the Eclipse Foundation, so we may need a ruling from the EMO(ED). > > So what do I/we have to do to get this started? I recommend making a formal request for a specific dollar amount. If the committer reps decide that they feel it's a reasonable use of these funds, we'll take it to the EMO(ED) for his consideration.
Changing the title of this bug to 'OSGi remote services testing' If you want to discuss student contributions, we should do that in another bug.
I wouldn't be comfortable with sponsoring a single project. If we end up spending money on this, it should be accessible to other interested eclipse.org projects as well, with some simple way of managing who can use it at what time. Also, this request would need to be more specific - the ball park number of $1000 per month sounds way too high to me. Have you looked into Rackspace Cloud Servers at all? The smallest instance (256 M, but it runs Java/Equinox stuff fine) is <$15 per month if you stay under 5GB of data in/out. How many machines would be needed?
(In reply to comment #10) > Technically the Amazon cloud might not be what ECF needs (AFAIK it blocks > multicast traffic even in the same security group). Does anybody know if other > cloud providers allow multicast traffic between instances? No idea. Does it even make sense to go ahead with this request until you know more about this?
LMGTFY: http://serverfault.com/questions/118243/multicast-in-rackspace-cloud
(In reply to comment #15) > I wouldn't be comfortable with sponsoring a single project. If we end up > spending money on this, it should be accessible to other interested eclipse.org > projects as well, with some simple way of managing who can use it at what time. Then allow other projects to share the resources. I'm fine with that. Maybe you'll actually get the projects working and testing together. But don't expect us to manage multiple project use...that's just another cost to us (and probably other projects as well). > > Also, this request would need to be more specific - the ball park number of > $1000 per month sounds way too high to me. This begs the questions: What doesn't sound way too high? and Why does it sound way too high? >Have you looked into Rackspace Cloud > Servers at all? The smallest instance (256 M, but it runs Java/Equinox stuff > fine) is <$15 per month if you stay under 5GB of data in/out. How many machines > would be needed? Say 10. I don't expect that < 5GB of data in/out probably isn't feasible (for any regular testing of communication software). If you've got a maximum per-project amount in mind or dictated by the budget, why not just say what that is and we'll start from there? Also...if there's a fixed pot (as I expect there is), and it has to be split (for any given project like ECF) between this bug and bug 335475 (resources for student releng), I would *much* prefer that it go to 335475 rather than paying Amazon or Rackspace or whomever for hardware and bandwidth (i.e. this request). In my view, resources are better spent on students who would/will contribute to the project rather than to commercial hw and/or bw vendors. So if allocation to this bug reduces or eliminates our eligibility for bug 335475, then please prioritize this request beneath 335475.
(In reply to comment #15) > I wouldn't be comfortable with sponsoring a single project. If we end up > spending money on this, it should be accessible to other interested eclipse.org > projects as well, with some simple way of managing who can use it at what time. Doesn't this kind of contradict the idea behind FoE money handed out to individual projects? I mean bug #313479 asked for project level donations and FoE disbursements has been praised as an answer. But suddenly no money will go to individual projects %)
(In reply to comment #17) > LMGTFY: http://serverfault.com/questions/118243/multicast-in-rackspace-cloud Looking at the OpSource prices, they charge $500/mo for a quadcore 24/7 instance. For that amount of money we could by a new server nearly each month and have it hosted by OSU. At the end of the year, we would have a nice test infrastructure. %)
(In reply to comment #19) > Doesn't this kind of contradict the idea behind FoE money handed out to > individual projects? I mean bug #313479 asked for project level donations and > FoE disbursements has been praised as an answer. But suddenly no money will go > to individual projects %) I don't mind funding individual projects. The funds we have available, however are limited. This year, we have ~$15K available. There is no way that we can justify $1000/month = $12K to any single project. There's really just no way that we can fund anything that has a significant ongoing cost. Bug 337068 is also a lot of money, but will benefit all projects and--ultimately--the community. I have no trouble allocating money to fund student work along the lines of what GSoC does. i.e. well-defined proposal for the work with success criteria (concise, of course) with a specific individual in mind to do the work. Realistically, though, we don't have enough money to fund this at the same level as GSoC. Providing funds to facilitate a project team meeting is also on the board: a one-time cost in the <$500 range.
(In reply to comment #21) > (In reply to comment #19) > > Doesn't this kind of contradict the idea behind FoE money handed out to > > individual projects? I mean bug #313479 asked for project level donations and > > FoE disbursements has been praised as an answer. But suddenly no money will go > > to individual projects %) > > I don't mind funding individual projects. The funds we have available, however > are limited. This year, we have ~$15K available. There is no way that we can > justify $1000/month = $12K to any single project. There's really just no way > that we can fund anything that has a significant ongoing cost. Bug 337068 is > also a lot of money, but will benefit all projects and--ultimately--the > community. Jeez Wayne. Bug 337068 (Maven repos) is likely going to end up *costing* the small projects extra releng work/time/resources...as pointed out on that bug...since the foe money probably won't even cover the IT, hw, and sw costs of having all the projects create maven repos and maintain/support them. That is, instead of helping the small projects with FOE disbursements, you've hurt them by adding new releng requirements. So I would say that although bug 337068 *might* benefit some of the loudest in the Maven consumer community, it's not likely to do anything for small projects (which are putatively the projects that the FOE money is intended for). > > I have no trouble allocating money to fund student work along the lines of what > GSoC does. i.e. well-defined proposal for the work with success criteria > (concise, of course) with a specific individual in mind to do the work. > Realistically, though, we don't have enough money to fund this at the same > level as GSoC. Why wasn't the funding level made plain more than a month ago, when the FOE disbursement announcement was made? Otherwise things go like this (and that's what's happened on this bug): 1) We (ECF) request some resources/money...to support releng, testing...specifically the things our community is asking for, and we as a small project without Board representation have a harder time doing on our own than the projects owned by IBM, Oracle, and SAP. 2) You (EF) say: 'how much do you need?' (see comment 7 comment 15). 3) We pull a number out of our xxx that is of course too high...because we need far more than FOE could ever provide (see comment 8) 4) Everyone who knows how little is actually available says 'that's too high for one project' 5) We say: ok, how much is not too much? 6) You say: $0 And everybody's time is wasted...with net result that a project like ECF gets nothing (except more simultaneous release requirements from the EF)...as well as learning that it's actually futile to ask for things like FOE disbursements. > > Providing funds to facilitate a project team meeting is also on the board: a > one-time cost in the <$500 range. This bug should probably be closed as wontfix then...as if money comes to ECF for *anything*, I would rather have it come for the request associated with 335475. While your at it, perhaps you should close all the FOE disbursement requests as wontfix...in favor of Maven support...it would save everyone's time.
Jeez Scott, the amount of funds available where clearly posted on the wiki page referenced in our initial disclosure of the programme.
(In reply to comment #23) > Jeez Scott, the amount of funds available where clearly posted on the wiki page > referenced in our initial disclosure of the programme. Right...that discredits everything I said in comment 22. Why don't people listen to the actual criticism (i.e. of the process/the way things are done...which has net result of continuously starving out small projects from the EF) as opposed to discrediting and attacking for trivialities? Bravo.
(In reply to comment #24) > (In reply to comment #23) > > Jeez Scott, the amount of funds available where clearly posted on the wiki page > > referenced in our initial disclosure of the programme. > > Right...that discredits everything I said in comment 22. > > Why don't people listen to the actual criticism (i.e. of the process/the way > things are done...which has net result of continuously starving out small > projects from the EF) as opposed to discrediting and attacking for > trivialities? Bravo. Starting a comment with "Jeez Wayne..." is condescending. I don't deserve that. Neither do you, and I apologize for reciprocating. The EF does not "starve out" any projects. We (EF) do not provide releng, development, or testing resources to *any* project. (In reply to comment #22) > Jeez Wayne. Bug 337068 (Maven repos) is likely going to end up *costing* the > small projects extra releng work/time/resources...as pointed out on that > bug...since the foe money probably won't even cover the IT, hw, and sw costs of > having all the projects create maven repos and maintain/support them. That is, > instead of helping the small projects with FOE disbursements, you've hurt them > by adding new releng requirements. We haven't added anything. Maven support within Eclipse, like many other topics, is under discussion. You may have noticed that I've been trying to manage expectations over there implementing a Maven repository will require webmaster time and energy, which is in short supply. Also, there is no discussion of adding new requirements. The new repository, like the simultaneous release, is opt-in. The intent is that we will provide the infrastructure, and projects can choose to participate. > So I would say that although bug 337068 *might* benefit some of the loudest in > the Maven consumer community, it's not likely to do anything for small projects > (which are putatively the projects that the FOE money is intended for). Bug 337068 is not asking for any FoE money directly. The likelihood of being successful there does increase if Bug 336864 gets approved, but even that linkage is tenuous. One thing that holding up Bug 337068 is that we're still not sure about the benefit to the community. My sense is that having a Maven repository at Eclipse will open the runtime projects to a broader community of adopters and ultimately invite more participation and general goodness all around. But I really have no grasp on what the immediate benefit will be. Though, isn't it the case that since ECF is maintaining its own Maven repository anyway, that ECF would benefit at least in a minor way from having a central repository? > > I have no trouble allocating money to fund student work along the lines of what > > GSoC does. i.e. well-defined proposal for the work with success criteria > > (concise, of course) with a specific individual in mind to do the work. > > Realistically, though, we don't have enough money to fund this at the same > > level as GSoC. > > Why wasn't the funding level made plain more than a month ago, when the FOE > disbursement announcement was made? Otherwise things go like this (and that's > what's happened on this bug): It was posted on the wiki. > 1) We (ECF) request some resources/money...to support releng, > testing...specifically the things our community is asking for, and we as a > small project without Board representation have a harder time doing on our own > than the projects owned by IBM, Oracle, and SAP. > 2) You (EF) say: 'how much do you need?' (see comment 7 comment 15). I believe that this is a fair question. Your request was open-ended. I wanted to see if we could make it work. To do that, we needed to have at least a ballpark number so we could see if it was possible. Would you sign a blank cheque? > 3) We pull a number out of our xxx that is of course too high...because we need > far more than FOE could ever provide (see comment 8) > 4) Everyone who knows how little is actually available says 'that's too high > for one project' Because we assumed (perhaps incorrectly) that everybody had seen the numbers on the wiki. > 5) We say: ok, how much is not too much? > 6) You say: $0 > > And everybody's time is wasted...with net result that a project like ECF gets > nothing (except more simultaneous release requirements from the EF)...as well > as learning that it's actually futile to ask for things like FOE disbursements. You keep talking about more requirements for the simultaneous release. We haven't added any new requirements with this process, or the Maven discussion. AFAIK, the planning council hasn't added any new requirements for Indigo. > > > > Providing funds to facilitate a project team meeting is also on the board: a > > one-time cost in the <$500 range. > > This bug should probably be closed as wontfix then...as if money comes to ECF > for *anything*, I would rather have it come for the request associated with > 335475. > > While your at it, perhaps you should close all the FOE disbursement requests as > wontfix...in favor of Maven support...it would save everyone's time. That's easy. There are none.
(In reply to comment #21) > I don't mind funding individual projects. The funds we have available, however > are limited. This year, we have ~$15K available. There is no way that we can > justify $1000/month = $12K to any single project. There's really just no way > that we can fund anything that has a significant ongoing cost. Bug 337068 is > also a lot of money, but will benefit all projects and--ultimately--the > community. Darn it, I meant Bug 336864. This invalidates the final snarky comment in my previous response.
(In reply to comment #25) <stuff deleted> > Starting a comment with "Jeez Wayne..." is condescending. I don't deserve that. Sorry you consider it condescending, that was not my intent. > Neither do you, and I apologize for reciprocating. > > The EF does not "starve out" any projects. I disagree. The policy from your next sentence has/is having this effect as releng (and other) resources for all projects goes down (as I think is clear to most). We (EF) do not provide releng, > development, or testing resources to *any* project. Yeah, I think that's (more than) clear for those that have experience with the EF. <stuff deleted> > > instead of helping the small projects with FOE disbursements, you've hurt them > > by adding new releng requirements. > > We haven't added anything. Maven support within Eclipse, like many other > topics, is under discussion. You may have noticed that I've been trying to > manage expectations over there implementing a Maven repository will require > webmaster time and energy, which is in short supply. Also, there is no > discussion of adding new requirements. The new repository, like the > simultaneous release, is opt-in. The intent is that we will provide the > infrastructure, and projects can choose to participate. Right...the projects can 'choose to participate'. Or they can not have the resources to even make such a 'choice'. I'm not even talking primarily about ECF, as ECF already generates Maven repos...but even given that we already have the build infrastructure to create Maven repos, 'choosing to participate' is an additional resource commitment...in the same way that choosing to participate in the simultaneous release means work/time/resources above and beyond running PDE/P2 to build/create a p2 repo. > > > So I would say that although bug 337068 *might* benefit some of the loudest in > > the Maven consumer community, it's not likely to do anything for small projects > > (which are putatively the projects that the FOE money is intended for). > > Bug 337068 is not asking for any FoE money directly. The likelihood of being > successful there does increase if Bug 336864 gets approved, but even that > linkage is tenuous. > > One thing that holding up Bug 337068 is that we're still not sure about the > benefit to the community. My sense is that having a Maven repository at Eclipse > will open the runtime projects to a broader community of adopters and > ultimately invite more participation and general goodness all around. But I > really have no grasp on what the immediate benefit will be. Me neither. ECF consumers have asked for it, and that's why we gave it to them. > > Though, isn't it the case that since ECF is maintaining its own Maven > repository anyway, that ECF would benefit at least in a minor way from having a > central repository? Only if it had exactly zero cost to us in terms of releng, coordination, and support. And given how those things actually work in the real Eclipse releng world, I do not expect the cost to us to be zero. <stuff deleted> > > While your at it, perhaps you should close all the FOE disbursement requests as > > wontfix...in favor of Maven support...it would save everyone's time. > > That's easy. There are none. I was shocked to see that there are currently a total of 4 disbursement requests...two from us (ECF): https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=FoE%20Disbursements&product=Community&classification=Eclipse%20Foundation So...to be explicit about this request and bug 335475 (the other, more important FOE disbursement request from ECF): 1) If anything is available to ECF at all, then a disbursement for bug 335475 should be prioritized over this bug/request. 2) We will accept (and can use) anything more than $100/month. Less than that and it isn't enough to justify the time already spent arguing.
Closing this as WONTFIX on the basis that we are not structured to handle ongoing costs.
(In reply to comment #28) > Closing this as WONTFIX on the basis that we are not structured to handle > ongoing costs. Wow. You're not structured to handle ongoing costs (like hosting costs for build/testing). What costs are you structured to handle? Might have been a good idea to not advertise the availability of funds for such things if you're not structured to handle them. Otherwise, going through this is yet another time/resource cost on the projects that you putatively support.
