Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [science-pmc] [CQ 12753] science.scanning

Hi Jonah,


On Feb 16, 2017, at 12:19 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

I would be happy to approve this CQ at the highlevel, i.e. it is an
expected IC for an approved project.

Please go ahead and approve it. IMHO, PMC approval for a CQ is intended to indicate that we agree with the intent of the submission and that it meets the goals of the project. It's not to ensure the contents meets legal or other requirements (at this stage). The IP team will address issues like missing copyright notices. It's a probably a good idea to take a look at the contents to see if it looks reasonable, but otherwise most things can be fixed once it's in the repo.


I am not clear on our (science-pmc) responsibilities here, the IP
poster (https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf)
does not say much, the technology-pmc's site says a bit more:
https://wiki.eclipse.org/Technology#Approve_Intellectual_Property_.28IP.29_Contribution_Questionnaires_.28CQ.29

This is something the PMC needs to decide! 


The technology.pmc's list has basically checking that
https://www.eclipse.org/legal/guidetolegaldoc2.php has been followed,
plus Try to reduce bloat. There are a lot of checkboxes on there and a
number of them haven't been met. But I assume that IP people have
tools that check this automatically.

For example, there is no about.html in every bundle and the
package-info.java files don't have copyright header.

I don't really want to do the check manually if there is automation later.

Additionally, "Author(s):      Self", I assume that other people at
DLS were involved in coding this :-)


side-bar I am not fond of this:
* There is no strict format for code, such as you must indent using a
tab rather than four spaces or your imports should be in a specific
order. Or a line limit other than the one Java suggests. If a reviewer
asks for this you should refer to this guideline!

but if you have that, I am glad you have:
* Avoid reformatting code just for 'readability' because it creates
false diffs. Better to tolerate the original developer's formatting.

Having worked on the 15 year old CDT project for a long time, it is an
absolute nuisance that random files are formatted in randomly
different ways. I am very fond of the growing number of projects that
enforce (via automation) strict code formatting rules. For example
py4j and PyDev are now in this situation and the code is easier to
work on because you can rely on the tools to help (like formatting).

I'd be happy to have Science Project formatter and clean-up profiles that we recommend projects adopt. PTP has developer guidelines we could use as a starting point: https://wiki.eclipse.org/PTP/policy/developer_guidelines as does CDT: https://wiki.eclipse.org/CDT/policy

I'd be wary of making this an absolute requirement, at least for existing projects. But it might be worth discussing with the project leads to see if they would be agreeable.

Regards,
Greg 


Back to the top