[En-Nut-Discussion] Update-Flood over now?

[Harald Kipp]

Hi Ulrich,


On 6/14/2011 11:59 PM, Ulrich Prinz wrote:
> No that doesn't bother me, but what makes me a bit upset is, that there
> again had been multiple files just been touched by _adding_ whitespace
> at line endings...

Some time ago I used an editor plug-in, but that one removed extra
whitespace automatically, mixing cosmetic commits with fixes. So I
removed that tool again, trying to be as careful as possible not to
introduce new trailing spaces. If that failed, I'm very, very sorry.
Yeah, I know, I could change the editor...but...man is a creature of
habit. (Correct translation?)

I further agreed with Michael to apply his enhancements to the trunk, as
they are targeted on application samples and some network stuff, which
shouldn't collide with the cm3 branch. Did we overlook something?


> Ok, I'll add some improvcements to eeprom and at24c driver and add a new
> driver for the SHT21 temperature and hummidity device from Sensirion.
> SDP pressure sensor will follow.

Most useful, we do have hardware based on LPC1768 (Cortex-M3) and SHT21.


> But I need to split the work a bit cause actually there is project
> pressure and then I'll have some vacation time... really, I need it :)

Same situation here, I'm busy on other projects as well. I've updated a
few crtinits and linker scripts, but haven't been able to check them
all. At least some of the AT91SAM7 inits contain minor bugs.

I'm aware, that too many modifications will introduce merge problems. So
I delayed any global changes like replacing CONST with const (after
stopping support for v6 of ICCAVR).

Due to my other tasks, I'm not sure, how much time it will take to apply
some final fixes. One idea is to create a branch for the next stable
_now_ and apply the missing fixes to that branch and the trunk
concurrently later. Actually no big deal, because only a very few
changes are waiting for the next stable. That would immediately allow us
to merge the current branches back into the trunk. I think we should do
so. Any objections?

Regarding version numbers: Although a large number of changes had been
applied, I still prefer using 4.10 for the next stable, reserving the
major revision 5 for the next one, which will definitely have more
impact on existing applications.

Regards,

Harald