I did a little experimenting, you can see the result here: https://issues.apache.org/jira/browse/XAP-345
If you go to "Manage Attachments" it says in red that the attachments are not intended for use and license is not granted. Whenever you upload an attachment there is a radio button you have to check that says: "Grant license to ASF for inclusion in ASF works (as per the Apache Software License ยง5) Contributions intended for inclusion in ASF products (eg. patches, code) must be licensed to ASF under the terms of the Apache Software License. Other attachments (eg. log dumps, test cases) need not be. " It is kind of annoying that it seems you can *only* see this info if you click on manage attachments, if you click on the attachment itself you you can't see it. I will ping you when the new patch comes in. I'll look at some older patches and make sure that radio button is checked for people without CLAs. James M -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Cooper Sent: Wednesday, March 21, 2007 8:44 PM To: [email protected] Subject: Re: Optmizations On 3/21/07, James Margaris <[EMAIL PROTECTED]> wrote: > > > Martin it can be very difficult to navigate the Apache policies > sometimes. I know. ;-( I looked at http://www.apache.org/foundation/how-it-works.html#roles and > it seems to me that Carlos and Michael M fall under "developers". Yes. However, you shouldn't read into the description of "committer" that those are the _only_ people who need to sign a CLA. The description of "developer" should probably say that they too may have to sign a CLA, depending on their specific contributions. If we > need CLAs for Jira patches I guess we can do that but I have in the > past checked in patches from people without CLAs. Again, it's a judgement call. Sometimes it's obvious: a multi-megabyte code contribution is going to need a CLA (and probably more than that); a one-line fix is not. Other times, though, it's not as clear cut. There's some checkbox thing in JIRA that I've heard about that explicitly grants rights or something. I don't know if that alleviates the legal concerns, and I'm not sure if it shows up for all projects, but it might be worth looking into. The actual code changes here are fairly small, although I am not > familiar with the exact scope it is stuff on the level of creating a > regular expression once and saving it rather than creating a new one > every time, or using "connectOnce" instead of "connect" to connect > events. I don't believe there are any new files or substantial blocks > of new code. > > I can hold off on comitting the changes. (I don't see that patch filed > yet anyway) Maybe you could look at the patch after it is filed and > help make the judgement call if it is signicant changes or simple bug fixes? I can try to do that if I can find some time. It would help if you could ping me directly when the patch shows up. I would like to get the perf improvements checked in without waiting for > a CLA if that is possible because the performance changes makes a > fairly large difference. It isn't a lot of code change but the effect > is rather large. Understood. -- Martin Cooper James M > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Martin Cooper > Sent: Wednesday, March 21, 2007 8:18 PM > To: [email protected] > Subject: Re: Optmizations > > On 3/21/07, James Margaris <[EMAIL PROTECTED]> wrote: > > > > He has submitted Jira patches in the past and this one will be > > submitted as well. > > > > I was under the impression that Jira patches did not need CLAs filed. > > Isn't the process supposed to be that people file patches and we > > patch > > > them into the repository? > > > > Michael Mikhaylov has submitted patches for: > > > > XAP-314 > > XAP-333 > > XAP-318 > > > Interesting. I wonder if there is a problem with JIRA. I searched for > his name in JIRA, and it came back with only XAP-314, which is the > only one Google finds too. Looking at the other issues you list does > show his name, so it's strange that a search doesn't find them. > > Carlos Sanchez recently submitted a Maven patch that I or someone else > > will hopefully take a look at and commit soon. Have you heard of > > Carlos Sanchez before? I haven't but I appreciate the work that he > did. > > > If it's the same Carlos Sanchez, I believe he is a committer on the > Maven project. > > More up-front communication about what people are working on would be > > good but I don't see why the lack of that would rule out patching in > > the code that they wrote and submitted to Jira. > > > > If I have some fundamental misunderstanding of how this works please > > let me know, but I thought that Jira contributors did not need CLAs > filed. > > > At some level, it becomes a judgement call, but the default should be > that a CLA is required. To quote from the CLA section on this page: > > http://www.apache.org/licenses/ > > "The ASF desires that all contributors of ideas, code, or > documentation to the Apache projects complete, sign, and submit [a CLA]" > > Many projects tend to let this slide for minor bug fixes and patches > (which is where the judgement call comes in), but for anything more > than that, we should really be getting a CLA, for legal protection > reasons. I brought it up here because you mentioned that 95% of what > seemed to me likely to be a significant commit was coming from someone > who has not previously file a CLA. > > -- > Martin Cooper > > > James M > > > > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > > Martin Cooper > > Sent: Wednesday, March 21, 2007 6:53 PM > > To: [email protected] > > Subject: Re: Optmizations > > > > On 3/21/07, James Margaris <[EMAIL PROTECTED]> wrote: > > > > > > Tonight I am going to check in some optimizations that Michael > > > Mikhaylov and I have been working on. (95% Michael, 5% me) > > > > > > Since 95% of this is coming from someone else, and he's not a > > committer, we're going to need him to file a CLA first. Please have > > him fax one in, and hold off on your commit until it has been > > received > > > by the ASF secretary. > > > > Who is this Michael Mikhaylov? I haven't seen his name in relation > > to XAP anywhere before. If he's working on XAP, he should be on the > > lists, and we should be seeing the discussions of the work he's > > doing right here on the xap-dev list. > > > > Remember, this is a community project, not a stealth development > > with a public face. > > > > -- > > Martin Cooper > > > > > > These optimizations are > > > geared around reducing startup time. The main optimization > > > involves some changes to our use of dojo.connectEvent - calling it > > > less frequently and changing the connect code itself a bit as well. > > > > > > Recently Michael Turyn checked in dojo 0.4, which also makes some > > > performance improvements as well as fixing the behavior of some > > > components. For example the tabbed pane response time is now a lot > > > snappier when clicking on various tabs, and some operations like > > > scrolling a large table inside of a tabbed pane are an order of > > > magnitude faster. > > > > > > So hopefully people will start seeing a fairly significant speedup. > > > > > > James Margaris > > > > > >
