We've got a Code Style we try to follow. You can find more in the Wiki: http://wiki.eclipse.org/Virgo/Committers/Coding
If the actual formatting in the repository does not match the rules we defined in the Eclipse settings mentioned in the Wiki I propose we
fix this mismatch as soon as possible in a separate commit.
Once the code in the repository is in line with the defined settings I think the auto format save action is a good thing.
Does this make sense to you?
I know for personal experience that messing up with the formatting of a project can make history very difficult to read.
If reformatting is desirable then I would egoistically prefer to do it immediately, because this code base is new to me: should I need to understand something from history, I'll look at the history before my changes. But of course I don't want to make other committers angry :-)
If we agree to make a full reformat of the code base, I would first make sure that the formatting preferences comply with the coding style documented in the Wiki, and maybe enable also a number of additional save actions (for example, to add @Override where missing) and then run a full "Source -> Clean UP..." on all projects.
Also, I remember that some Eclipse projects use static code analysis also to verify that source code is properly formatted (I remember Gerrit refusing a patch of mine because the formatting did not comply with some formatting rules). Is there anything like that in place for Virgo?
It would be great to see more consistency with other Eclipse editors. Please give it a try.
> Am I correct to assume that whatever change should be tracked by a bugzilla entry? Is the "ENHANCEMENT" severity the field to be used to denote that the entry is not for a fix but rather a new feature/requirement implementation?
Yes and yes.
As soon as I get full committer grants once my paperwork is processed I'll create an enhancement for the multi selection in the artefact order section (because that is something I already did).
Then if we agree to reformat, the reformatting will follow (should this be tracked in bugzilla?) and then I'll start changing the editor behaviour as discussed.
A future goal could be merging into the code base my personal project for working with Virgo Tools + PDE. That would solve the long standing request https://bugs.eclipse.org/bugs/show_bug.cgi?id=329198
But to make a proper implementation it should be better integrated with the tools than my personal project, so this will take quite some time (e.g. I think it should automatically setup a PDE target platform from the Virgo repository configuration files).