[Bug 1983] cpukit/libnetworking/libc/gethostbyht.c:226:12: warning: ordered comparison of pointer with integer zero

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1983

--- Comment #6 from Joel Sherrill <joel.sherrill at oarcorp.com> 2011-12-08 08:51:50 CST ---
I have asked everyone who committed to the branches to do this. I just double
check it at release time.

Reconstructing what happened and why was a real pain in the ^%$ as part of the
release process. Many hands doing light incremental work saves a lot of work
doing forensic analysis to figure out what changed.

No it isn't written down. But there aren't many committers and most bugs fixed
on branches have been committed by me. Where should it be written down?

Any developer who views adding one line to a Wiki page to documenting changes
along a release branch as an unnecessary burden needs to go work on a project
with serious CM. Many of our users have CM processes that require some serious
paperwork to make a change after a code freeze. We are a serious project for
serious applications.  We need to treat release branches in a professional
manner and follow best, but light weight, practices.

(In reply to comment #5)
> (In reply to comment #4)
> > When you apply a patch or any change to a release branch after a .0 release, it
> > needs to be noted in the release notes for the next release.  The "next release
> > notes" grow and are a factor in deciding when to cut them.
> 
> Well, I don't recall such a regulation has ever existed since RTEMS exists nor
> do I recall such a proposal having been decided upon by the SC.
> 
> ... I recall you (the release manager) to have collected them around release
> times.
> 
> > http://www.rtems.org/wiki/index.php/4.9_Release_Notes#Release_4.9.7_Changes
> > http://www.rtems.org/wiki/index.php/4.10_Release_Notes#Release_4.10.2_Changes
> > 
> > FWIW any new features or compatibility changes should be noted in the "next
> > major release" page which is
> > http://www.rtems.org/wiki/index.php/4.11_Release_Notes
> > 
> > By writing these as we go, it really removes what used to be a burden at
> > release time.
> 
> Well, I guess, I don't need to mention that such regulations/bureaucracy
> encourages contributors to apply a differnent strategy: Not to fix bugs in
> release branches.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.