On Thu, Nov 2, 2017, at 04:05 PM, Matthew Miller wrote:
> On Wed, Nov 01, 2017 at 02:11:39PM -0700, Adam Williamson wrote:
> > I have one argument in favour of keeping the actual release notes
> > together with the distribution itself: future accessibility. In my
> > experience, the availability of ancillary bits that were *originally*
> > provided alongside some piece of software in some way is far less
> > reliable than the availability of the software itself. You can often
> > find the actual tarball (or whatever) of some random F/OSS release from
> > 2005, or 1995. It's much less likely that you'll find the associated
>
> Yeah, I guess this is a pretty compelling argument. On the other hand,
> I don't want to keep slipping releases for it,
I think we are back on track for building with the new tooling. Where we struggle is content, imho. We’ve got more people focused on writing which is good. We are also going to do a retrospective on the process to find improvements.
Lastly, I talked to jkurik and it sounds like the next change process modification will include having change tickets opened in the Release Notes repo by the change owners after the change is approved at the beginning of the cycle. This and a measure of the content in the ticket will be included in the consideration PgM makes when determining if changes are complete. Jkurik is working on the details for us to all review.
> and I don't want the
> documentation at release time to be seen as frozen, like in-print
> books.
+100. However there will always be the “initially shipped package.” There should be enough time between beta freeze and GA freeze to finish, but late changes or late removed changes will remain a small challenge.
> Perhaps we can have a process where the package is automatically
> updated from any changes to the doc site? A "bots do the work" kind of
> thing.
I’ve been thinking about this as I start working in CentOS CI. I need input from someone who knows our build system better to find out how we can automatically kick off a new package build. Is it as simple as tagging a release? What if we have a series of commits one after the other? Etc.
Regards,
bex
>
>
> --
> Matthew Miller
> <mattdm@xxxxxxxxxxxxxxxxx>
> Fedora Project Leader
> _______________________________________________
> docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ docs mailing list -- docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to docs-leave@xxxxxxxxxxxxxxxxxxxxxxx
