On 5 Sep 2018, at 09:50, Darran Lofthouse
<darran.lofthouse(a)redhat.com> wrote:
I was thinking the cross reference page would likely need to live in the proposals repo
so any links can be added with the proposal.
If this repo was also tagged at the same time as the WildFly release that would also have
the benefit of allowing us to diff between two releases to double check all additions are
cross referenced.
Tagging is a bit hard to do fix once done (we sometimes forget to
merge the analysis documents), but perhaps that isn't too big a deal.
Another thing is to do a JQL query of the EAP7 issues resolved for a particular CD, and
include the Analysis Document column in the query results. Those generally link to pull
requests though, so something would need to be done to pull out the relevant files.
I realise the use of EAP7 isn't strictly 'community', but once I get some
cycles to get back on the Kanban tooling, the plan is to move/duplicate this information
in the WFLY/WFCORE feature requests.
I think this project would need a pom adding to define the build like we do for the
WildFly docs.
Then for location I suppose we could either be with the WildFly docs - of if not just
publish the resulting html via GitHub using the same repo.
On Tue, 4 Sep 2018 at 17:37 Brian Stansberry <brian.stansberry(a)redhat.com> wrote:
This is a really good idea. Where would the cross-ref page live, how would publication
work, etc?
On Thu, Aug 30, 2018 at 12:01 PM, Darran Lofthouse <darran.lofthouse(a)redhat.com>
wrote:
At the moment we have a lot of effort going into populating the wildfly-proposals
repository with the proposals for new features as they are added to the application server
- but at the end other than them sitting in the repository we don't really do anything
with them.
I was wondering if we could maybe do something to add a table of contents per WildFly
release cross referencing the proposals added in that release and at the end we could
generate publishable documentation.
This could give us some quite detailed release notes without a huge amount of additional
effort taking advantage of the effort that goes into writing these in the first place.
Regards,
Darran Lofthouse.
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev