https://bugzilla.novell.com/show_bug.cgi?id=324134

User [EMAIL PROTECTED] added comment
https://bugzilla.novell.com/show_bug.cgi?id=324134#c40





--- Comment #40 from Andreas Färber <[EMAIL PROTECTED]>  2008-10-26 02:50:09 
MDT ---
Paolo, are you sure you're looking at the right thing? You had commented on a
private working copy diff in 2007 and since then not cared to comment. There
are no more indenting changes in ppc-codegen.h for many months already, and -
in agreement with Geoff - split it up into mutiple Git branches.

Apart from Mark this summer (inserting casts that I did, too), no one has
touched that file in SVN since 2006, so it is unlikely to break people's work.
I do not consider these changes irrelevant and neither did Miguel - he was in
favor of merging Christopher's copyright section into a standard Mono file
header when I started the port. Apart from that, as I have already explained
and asked about multiple times in vain, the changes I am proposing are ordering
instructions alphabetically and grouping them by instruction.

I have suggested adding newlines because then the patch is _least_ intrusive as
opposed to changing functional lines. I am suggesting ordering the macros
alphabetically because the manuals are ordered that way and it thus facilitates
maintainance, especially checking for missing ones. The large
Christopher-section is already ordered that way.

My ppc64 additions and changes were clearly visible in the patch 3/3 or, now,
by `git diff ppc64-functional..ppc64 -- mono/arch/ppc/ppc-codegen.h`.

The checks for ppc64 are there for a reason - some instructions are illegal and
must not be used on ppc64 or ppc(32) respectively. There is no strict
separation between ppc and ppc64 btw, just multiple revisions and different
levels of support.

As someone working on this file I would very much welcome a solution that is
easy to work with - doing two preparatory commits seemed like the best way to
separate functional and non-functional changes and keep the changes reviewable.
Please be constructive and don't just say no.


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
_______________________________________________
mono-bugs maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/mono-bugs

Reply via email to