[wildfly-dev] Making More Use of wildfly-proposals

[Kabir Khan]

> On 5 Sep 2018, at 09:50, Darran Lofthouse <darran.lofthouse at 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 at 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 at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev