Updating quickstarts documentation between releases
by Paul Robinson
Paul,
I think you are the right person for this, but I could be wrong…
On JBoss Developer we index quickstarts for each product and render some of the documentation (README.md, CONTRIBUTING.md, for example) on the site. Here’s an example:http://www.jboss.org/quickstarts/eap/contributing/ <http://www-stg.jboss.org/pr/714/build/1464/quickstarts/eap/contributing/>. We index the latest release of each quickstart from the related Quickstart repo in the JBoss Developer GitHub organisation. It’s important that we index the release, as we know it has been QA’d against the latest product GA on the site.
However, there are several cases where broken links exist in the documentation that we are indexing. Notice the ‘Fork’ link on http://www.jboss.org/quickstarts/eap/contributing/ <http://www.jboss.org/quickstarts/eap/contributing/>. This is due to a broken link in the source content: https://github.com/jboss-developer/jboss-eap-quickstarts/blob/6.3.0.GA/CO... <https://github.com/jboss-developer/jboss-eap-quickstarts/blob/6.3.0.GA/CO...>. This is easy to fix at source, but we would need to wait for the next quickstarts release (in this case EAP 6.4.0.GA) before JBoss Developer can consume the fix. Broken links are bad for user experience and adversely affect SEO, so we’d rather get them fixed sooner.
One solution would be to allow documentation only changes to be made to quickstarts between releases. In the example above, we would create a commit (fixing the broken link) on top of the 6.3.0.GA release (https://github.com/jboss-developer/jboss-eap-quickstarts/releases/tag/6.3... <https://github.com/jboss-developer/jboss-eap-quickstarts/releases/tag/6.3...>) and then tag it as a new release. I think we’d have to use some naming convention to indicate it was just docs that changed. JBoss Developer would then index the new tag in order to consume the fix.
Is this the right thing to do?
Paul.
--
Paul Robinson
JBoss Developer Team Lead (www.jboss.org)
Free/busy info: https://www.google.com/calendar/embed?src=probinso%40redhat.com&ctz=Europ...
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No. 03798903
Directors:Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Paul Hickey (Ireland)
8 years, 9 months
<repository /> definition in pom.xml for Quickstarts and Demos
by Rafael Benevides
Hi all,
I was thinking about the implementation of the repository definition in
pom.xml and I want to share my thoughts:
- Create a QSTools CHECKER to mark the lack of <repository /> as a
guideline violation if MavenCentralChecker is disabled.
- The violation message will instruct to use the new QSTools GOAL
that will be created
- Create another QSTools GOAL to setup the repositories.
- There will be a list of approved repositories and its IDs (redhat
techpreview, earlyacess, jboss developer temporary, etc)
- QSTools will remove all previous repositories from pom.xml and
prompt which repositories should be added.
- This will help Quickstarts and demos to be easily buildable from
development and production branches and will also allow this list to be
bulk updated to remove any previous development repository definition.
Please,
If you have any feedback on this, feel free to reply.
--
*Rafael Benevides | Senior Software Engineer*
JBoss Developer
M: +55-61-9269-6576
Red Hat
Better technology. Faster innovation. Powered by community collaboration.
See how it works at www.redhat.com <http://www.redhat.com/>
LinkedIn <http://www.linkedin.com/company/3258288> Youtube
<https://www.youtube.com/redhatlatam>
9 years, 1 month
[Proposal] One BOM for Wildfly/EAP 7
by Paul Gier
Hi Everyone,
I'd like to propose that we consolidate our current JBoss EAP BOMs into
a single BOM. We currently have several smallish BOMs with names like
"jboss-javaee-6.0-with-hibernate" and "jboss-javaee-6.0-with-security".
Instead I think we could make a single BOM which contains all public
API jar versions and is used throughout the quickstarts whenever an API
is needed.
The specs project would continue to provide a JavaEE specs BOM for
simple use cases. And the eap BOM project would provide the JavaEE APIs
and public EAP specific APIs. Note that using this BOM in a quickstart
would not cause the quickstart to download "all" the API jars, the BOM
only manages the versions of the jars which have already been added to
the dependency tree.
The advantage of this is easier maintenance and a simpler configuration
for users who currently use more than one of our current BOMs in their
application.
WDYT?
9 years, 2 months
Fwd: [Website] - Current state of forums - Neglect, spam and blocking genuine participation, can someone from .org team help? [nzpb2z-1py-jtgf]
by Max Rydahl Andersen
Jaikirian with a post with some good points about the spam levels at
jboss.org ;/
Mark N./jboss.org - are we really this powerless in fighting this ?
either by installing filters
or handing out moderation abilities to more users ?
Currently it seems most of what we do (maximum post rate on newcomer) is
hurting real newcomers ability to engage
rather than helping filtering spams..
I know its a loosing battle, but just interested to know if we are doing
or planning something beyond "manually deleting spam" ?
/max
http://about.me/maxandersen
Forwarded message:
> From: jaikiran pai <do-not-reply(a)jboss.com>
> To: Max Rydahl Andersen <manderse(a)redhat.com>
> Subject: [Website] - Current state of forums - Neglect, spam and
> blocking genuine participation, can someone from .org team help?
> [nzpb2z-1py-jtgf]
> Date: Sun, 12 Apr 2015 03:03:00 -0400
>
> jaikiran pai
> [https://developer.jboss.org/people/jaikiran?et=watches.email.thread]
> created the discussion
> "Current state of forums - Neglect, spam and blocking genuine
> participation, can someone from .org team help?"
>
> To view the discussion, visit:
> https://developer.jboss.org/message/924639?et=watches.email.thread#924639
>
> --------------------------------------------------------------
> This is not a new issue, but something that (sadly) has been around
> for a long while now. The forums hosted at developer.jboss.org have
> been constantly spammed and in general the forums themselves have been
> neglected. Genuine activity/participation in the forums has
> drastically decreased over the years. To give you an example of the
> kind of content (spam) that the forums currently attract, take a look
> at the attached screenshots which are from the "Recent discussions"
> and the "latest content" widget/pages. All spam (except a thread or
> two)!
>
> The more worrying sign is that there seems to be absolutely no one
> (other than community volunteers) with the right set of control (i.e.
> Jive admin related controls) from the .org team, who seem to monitor
> these forums and nip this spam in the bud. The community volunteers
> occasionally mark these threads as spam but one can't expect them to
> be able to handle this amount of spam on their own.
>
> In the past, when I was employed at Red Hat, I had raised this issue
> numerous times and the jboss.org was helpful enough to add a very
> basic spam filter to the forums. Unfortunately, that has helped only
> marginally and in fact on many occasions caused problems to genuine
> users (see these threads for what I mean
> https://developer.jboss.org/thread/248640 One post per hour
> https://developer.jboss.org/thread/240315 Disable Frequency Limit
> https://developer.jboss.org/thread/237908 Rate Limiting).
>
> If you look at the current bunch of spam, it's very clear that it's a
> scripted attack (take a look at the timing on the posts). I am a
> moderator in one other very popular Java forum on the internet and
> that one is fully driven by volunteers including managing the servers
> and the software. Yet, we have far better control on spam. In fact,
> you hardly find spam in those forums because we nip them in the bud
> with various tools and more importantly with the intention and
> dedication of keeping the forums active and lively with genuine
> participation. I find it hard to believe that these professional
> forums at jboss.org, overs these past years, have constantly allowed
> this kind of spam to continue, yet at the same time haven't addressed
> concerns where genuine participation has been blocked.
>
> Could someone from the .org team please take care of these issues and
> get rid of spam and at the same time allow genuine participation to
> continue? Hopefully someone from the team is allocated to keep a watch
> on activities like these on a ongoing basis instead of someone from
> the community constantly bringing this up every few weeks.
> --------------------------------------------------------------
>
> Reply to this message by replying to this email, or go to the
> discussion on JBoss Developer
> [https://developer.jboss.org/message/924639?et=watches.email.thread#924639]
>
> Start a new discussion in Website at JBoss Developer
> [https://developer.jboss.org/choose-container.jspa?contentType=1&container...]
>
>
>
> --end--
9 years, 2 months
