I don't think anyone's arguing that a changelog is a bad idea. The question is just whether it's easier to make from fragments in the repository or from a new field on trac. Personally I think trac, though being able to edit fragments from previous tickets is appealing. Either way, there should be a way to see the in-progress auto-generated changelog.
On Jan 16, 2017 08:23, "Erik Bray" <erik.m.b...@gmail.com> wrote: > On Fri, Jan 13, 2017 at 4:54 PM, Dima Pasechnik <dimp...@gmail.com> wrote: > > > > > > On Friday, January 13, 2017 at 3:41:23 PM UTC, Erik Bray wrote: > >> > >> On Fri, Jan 13, 2017 at 4:32 PM, Dima Pasechnik <dim...@gmail.com> > wrote: > >> > > >> > > >> > On Friday, January 13, 2017 at 11:15:49 AM UTC, Erik Bray wrote: > >> >> > >> >> On Thu, Jan 12, 2017 at 9:48 PM, Kwankyu Lee <ekwa...@gmail.com> > wrote: > >> >> > > >> >> > > >> >> > On Thursday, January 12, 2017 at 8:10:54 PM UTC+1, Dima Pasechnik > >> >> > wrote: > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Thursday, January 12, 2017 at 6:01:55 PM UTC, Volker Braun > wrote: > >> >> >>> > >> >> >>> The whole point of NEWS would be to have coarser granularity than > >> >> >>> individual tickets. E.g. 7.4 -> 7.5 is over 300 tickets, and a > >> >> >>> 300-item list > >> >> >>> is never a good answer to the question "whats new in this > release". > >> >> >>> I > >> >> >>> would > >> >> >>> envision a list of, say, 10-20 highlights to have associated news > >> >> >>> fragments. > >> >> >> > >> >> >> > >> >> >> yes, right, so you'd tag these "interesting for NEWS" tickets on > >> >> >> trac, > >> >> >> using some kind of trac plugin. > >> >> > > >> >> > > >> >> > I guess Volker's idea is that the author of the ticket decides if > >> >> > his/her > >> >> > ticket is worth to be highlighted and provide a well-phrased blurb > >> >> > for > >> >> > general users. > >> >> > >> >> Yes, I support this. The idea is to have a high-level view that end > >> >> users can digest as to what changed as it impacts them. This > >> >> certainly *should* include bug fixes, but we're talking especially > >> >> runtime bugs that are fixed from one release to another (as opposed > to > >> >> bugs that only occur during development and which appear and are > >> >> subsequently fixed only during development). Sometimes also build > >> >> bugs are worth reporting if, for example, building on a particular > >> >> platform is fixed between two releases. And of course new features, > >> >> etc. > >> >> > >> >> If you autogenerate such a list just from ticket summaries or worse, > >> >> from the git changelog, it's not very digestible in that way. I'm > >> >> glad adding such a changelog is on the agenda. > >> > > >> > > >> > at least you're autogenerating from something that is visible and > >> > reviewed. > >> > Reviewed these extra pieces, as Volker proposes, to be written is an > >> > extra > >> > burden. > >> > >> You're basically saying that writing good documentation is an extra > >> burden. And of course that's true. But that's not an argument > >> against it. > > > > > > it's not really documentation, it is more of advertising! > > > > some kind of write-once read-never thing, many people won't be bothered. > > Except when they have a problem (and often even when they don't, such > as to check whether they can expect any problems with their code when > upgrading to a newer version--for example this is a place to announce > deprecations and API changes). I find it infuriating when projects > don't supply such a change log (especially if I do have a problem). > It's almost as infuriating when they don't timestamps in their > changelogs and there's no way to know when a version was released, > which is sometimes useful information. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.