On 8/12/10, Maciej (Matchek) Blizinski <[email protected]> wrote: > > True. There needs to be the distinction between the changelog which > has the "for the record" flavor, and important messages which are of > the "you need to read it or you will end up pulling your hair" kind. > > Implementation would have certain level of complexity: a central place > to hold all the messages and hold their read/unread state. > Preferably, with not much dependencies, which probably points us at > perl. >
Pffft. the task of DISPLAYING [whatever] is trivial. The tough part, is determining the policy, and location :) The policy is going to be the tricky part. For example, I can think of at least 3^H4 separate contexts where a packager might choose to display "something" to the user: a) Something Really Important about this specific release! b) Something good to know about this package in general c) "If you are upgrading from version xyz or previous, you need to do..." d) General csw "changelog" tedium, for really bored people who dont have enough to read :) and there's probably more :-/ But please note: in my opinion, an "upstream" software changelog, never belongs here. Only specific "here's a change that will break things for you" warnings. Oh I suppose if there are maintainers who reaaaally want to call that stuff out, we can make a facility for that sort of thing. But I for one, want a "i NEVER want to see that junk" option for it ;-) _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
