intrigeri:
> sajolida wrote (07 Jun 2015 16:45:19 GMT) :
>> intrigeri:
>>> sajolida wrote (02 Jun 2015 10:36:30 GMT) :
>>>>> Code and Infra are only drafted, there are probably more to add.
>>>
>>>> I'd rather not duplicate what we already have written in release notes
>>>> and rather link to them.
>>>
>>> I'm a bit torn on this one. On the one hand, I realize that
>>> duplication is always a potential problem (in particular for
>>> translatable content, which is the case here).
>
>> On top of translation, let's not forget writing. I like writing the same
>> stuff twice.
>
> Sure (assuming there's a missing "don't" in that last sentence :)
Of course :)
>> Another option would be to copy-pasting stuff from the
>> release notes.
>
> Works for me. Kinda ugly, but we can still extract stuff and use an
> include directive... which I suspect we may want to do anyway once we
> build the release notes automatically from snippets, as discussed
> elsewhere. (And yay, it's still on my backlog to sum it up and create
> tickets -- sorry, please everyone feel free to be faster than me.)
>
>>> On the other hand:
>>>
>>> * one of the reasons why these reports are very useful is the fact
>>> they are self-contained => anyone who reads them, and doesn't read
>>> anything else, gets a good overview of what's going on in Tails
>>> world without having to click through more links. I'm thinking e.g.
>>> of LWN and tor-reports@ readers: it would feel strange to me if
>>> reading the report gave them details about all Tails activities...
>>> except actual "code" changes;
>
>> I suspect those people read the release notes as well [...]
>
> I'd like to come back to those who read our reports _and nothing
> else_; maybe they don't exist, as you're suspecting (FTR I have my
> doubts wrt. LWN readers), but they will never exist unless the
> report's content addresses this use case, so there might be some kind
> of self-fulfilling prophecy at play here.
>
> I personally would like to see us encourage this use-case, as a way
> for our project to communicate to observers from the greater free
> software "community" at large. I don't know if you're familiar with
> the LWN weekly edition, but for me personally it's a great way to keep
> vaguely updated about many projects without actively subscribing to
> anything specific. In that edition, every month there's a link to our
> report. Clicking on that link is one thing, but having to additionally
> click another link (report -> release notes) to know what changed
> inside Tails recently is another one. Having stated this use-case and
> why I feel it's important in more details this time, I trust it'll be
> taken into account, and I have no plans to argue endlessly in favour
> of it.
Understood now. I ignored the fact that our reports (and not our release
notes) where relayed by Linux Weekly News. I never published them there
myself. Then for me the way to go it to work on snippets and include
them in both places (once we actually do that). Because until now those
people get degraded and partial information (see our latest reports).
> Still, I realize that for the vast majority of readers of our reports,
> including release notes would totally be duplicate info, so there's
> a balance to find. I said I was torn, and I still am.
>
>>> * one could argue that 90% of what's in our reports is duplicate
>>> information that's already available somewhere else anyway, just in
>>> a digested, summed up and rephrased form, so taken in isolation,
>>> the duplication argument is a bit weak to fully convince me.
>
>> As you said, the value of both the release notes and reports is to
>> summarize and communicate to the outside world tons of little things
>> that otherwise happen on internal channels (Redmine, mailing lists).
>> So it's not duplicating them as such, it's summarizing and rephrasing
>> them for a different audience. And unless we find a rationale to
>> summarize and rephrase stuff differently in the report than in the
>> release notes, we're doing the same work twice and sending it to pretty
>> much the same audience. Against, maybe copy-pasting is the way to go.
>
> Absolutely.
>
>>> One way to do it would be to move past releases' changes (if we keep
>>> them) into the "Releases" section, and add an introduction sentence to
>>> the "Code" section that clarifies that it's about future releases.
>
>> I've done that in commits 49e1c00 and 883757d. Please have a look.
>
> Looks good :)
>
>> And feel free to bring back the work that was done for 1.4 in May
>> from the release notes into the release section of the report.
>
> Shall I go ahead with what I suggested above? (that is, extracting the
> release notes bits we need twice and [[!inline]] it from both places)
Yeap.
>>> Also, just a nit: I don't think it's necessary to go as far as
>>> mentioning which exact release each change is scheduled for. Instead,
>>> I would point to the relevant ticket, and those who are *really*
>>> interested in that topic will see up-to-date target version
>>> info there.
>
>> Ah, that's good as well. I already separated stuff for 1.4 and 1.5
>> before reading again your email. Feel free to merge them
>> to simplify.
>
> Done. One more argument in favour of merging them is that for some
> changes we don't know yet in which release they'll land (e.g.
> it's currently unclear if #5623 will end up in 1.5 or 1.4.1).
That's good.
--
sajolida
