I'm that "someone else" - author of the PR.

You say that "If it ain't broke, don't fix it...". The problem is, it is broke and even the source code says it itself:
    // @TODO - source maps not currently working

https://github.com/apache/netbeans-website/blame/a808570c4425c11fa490573f97307325f73a2646/netbeans.apache.org/build.gradle#L49

Also the full Foundation framework is used and now it generates 131kb css file (!). And that mess cannot be debugged without source maps:

https://github.com/apache/netbeans-website/blame/a808570c4425c11fa490573f97307325f73a2646/netbeans.apache.org/src/content/scss/netbeans.scss#L28

Neil and Antonio commited that not working code into the repository, now they want to close the PR that fixes their code, and when Chris wants to help with fixing it too, he's being disrespected. Did I miss something?

The mentioned projects Apache Tamaya (Incubating) and Apache Incubator are not the best examples because they don't even use Sass and there are no frontend assets to compile. And Chris is right - with Gradle (or some other Java tool) we won't get too far with frontend assets.

Best regards,
Michael


On 15.07.2019 23:39, Geertjan Wielenga wrote:
On Mon, Jul 15, 2019 at 9:14 PM Christian Lenz <christian.l...@gmx.net>
wrote:

  So I’m for merge and there is someone else who wants to work on it, if
this changes.


You're for merging the PR and there is someone else who wants to work on
it, if this changes? If what changes? And who is "someone else"?

Gj





Cheers

Chris



Von: Antonio
Gesendet: Montag, 15. Juli 2019 20:59
An: dev@netbeans.apache.org
Betreff: Re: AW: website build system: moving to node/npm?

Thanks, Chris!

So let's await for those "frontend guys" with "> 10 years" of experience
to build a "common frontend stack" so they can "work on the page" with
"VuePress, Nuxt, Hugo or Hexo".

Meanwhile let's stick with the "guys working on that page" (no matter
whether backend or frontend) and let's close PR#375 [1].

As Geertjan suggested, "If it ain't broke, don't fix it...".

Thanks again & kind regards,
Antonio


[1]
https://github.com/apache/netbeans-website/pull/375


El 15/7/19 a las 15:30, Christian Lenz escribió:
We only need frontend guys working on that page and there are a lot of
frontend guys out there. There is Nothing half baked. Look at Github what
they have use a more common frontend stack. For me as a frontend developer
for > 10 Years, it is farly not Java or JBake or JVM whatever. This is not
a common frontend stack and the case why I didn’t work on the page is
exactly that using of the stack.
We don’t Need Java backend guys working on that page. Just a couple of
frontend guys and I guess david will aslo help here and me too.
My proposals are: VuePress, Nuxt, Hugo or Hexo. My 2 cents.


Cheers

Chris



Von: Neil C Smith
Gesendet: Montag, 15. Juli 2019 12:50
An: dev
Cc: Apache NetBeans
Betreff: Re: website build system: moving to node/npm?

On Mon, 15 Jul 2019 at 11:07, Geertjan Wielenga <geert...@apache.org>
wrote:
If it ain't broke, don't fix it...

And do we expect lots of people to work on the site just because we
switch
from Gradle to Gulp? Do we need lots of people working on the site,
especially since everything's working fine the way it is?
Switching to an equally bespoke and arcane build system in Gulp, no.
Moving to a popular static generator ( https://www.staticgen.com/ )
and using it in a somewhat standard fashion (which we're not with
JBake as I recall) might be a good move to reduce technical debt.

If we did stay JVM, then Orchid might be worth looking into, as it
claims both to support JBake configuration and the additional things
we're doing in the custom build process?!

If someone has a proposal for a JS (or other) SSG that can do the full
job of what we have now in a standard way then I think it's strongly
worth considering.  But it needs to be a complete plan.  At my old
company I did take a brief look at Gatsby, but in the end mostly made
use of Jekyll due to the better (at the time) client-side CMS options
- or in other words, there are always other considerations in play!
:-)

Best wishes,

Neil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists





--
Pozdrawiam,
Michał Dymecki


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



Reply via email to