You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@yetus.apache.org by Allen Wittenauer <aw...@effectivemachines.com> on 2017/11/09 22:16:09 UTC

[DISCUSS] Reviewing YETUS-15

Hey gang!

	As some of you know, I’ve been working on YETUS-15 for the past few weeks.  I think I’m at the point that it’s probably time for others to start reviewing it.  Given that it’s such a big and impactful patch, I’d like to hear some input on how I can put forth something that’s actually reviewable.

	I’ve come up with two options.  If there is any preference or someone has another idea, I’m all ears. 

	1) One big patch that can be applied to the current master and reviewed locally from there. Let people play with the final product.

	2) Create, review and commit subsets of stuff, knowing that partial commits will leave either master or a branch to merge later partially working until everything is in place.

	For those curious what it currently looks like, I’ve got a branch on gitlab (https://gitlab.com/_a__w_/yetus , branch y15) that is composed of two patches:

		- YETUS-568, which does some pre-work to releasedocmaker’s output
		- YETUS-15, all of the rest of the build changes in one big patch and the beginnings of yetus-maven-plugin, to demonstrate one of the reasons why I went with maven [2]

	While this is basically two patches, there are definitely parts of YETUS-15 that could be separated out if need be.  It just won’t be fast. :)

	There are a few things missing that I’d prefer to avoid making a requirement since the patch is already pretty large:

		* asf-site is still built with middleman.  This is a project in and of itself if we want to make it built with mvn site. [2]
		* There are still no real tests anywhere and I haven’t built out bats support in mini maven plugin yet.  Getting a working build system is step #1 to start building out tests.

Thoughts?

Thanks!



1 - I’ve done a few prototypes with both docs-maven-skin and the devacfr version of reflow-maven-skin.  I think we’ll likely end up building our own skin if we want to replicate the current website.  This isn’t necessarily a bad thing and might even lead to others using it too.  Just be aware that there are some significant source repo layout vs. pom.xml gotchas.

2 - The other project I’ve currently got cooking is a Yetus Jenkins plugin in an attempt to replace custom build scripts.  The Jenkins provided plugin bits appear to be solidly built on maven.  At that point, we’ve got enough maven stuff happening that we might as well do everything with it.

Re: [DISCUSS] Reviewing YETUS-15

Posted by Allen Wittenauer <aw...@effectivemachines.com>.
> On Nov 9, 2017, at 6:17 PM, Sean Busbey <bu...@apache.org> wrote:
> 
> I'd personally like one big patch to look at.
> 
> This a blocker on a 0.7.0 release?


	It doesn’t have to be.  The patches in 0.7.0 already and the two blockers that are sitting in PA state are probably enough to roll another release because they are so (IMHO) important.  My hope would be that users would be none the wiser that the build system changed though. (Probably unavoidable, but…)

Re: [DISCUSS] Reviewing YETUS-15

Posted by Sean Busbey <bu...@apache.org>.
I'd personally like one big patch to look at.

This a blocker on a 0.7.0 release?

On Thu, Nov 9, 2017 at 4:16 PM, Allen Wittenauer
<aw...@effectivemachines.com> wrote:
>
> Hey gang!
>
>         As some of you know, I’ve been working on YETUS-15 for the past few weeks.  I think I’m at the point that it’s probably time for others to start reviewing it.  Given that it’s such a big and impactful patch, I’d like to hear some input on how I can put forth something that’s actually reviewable.
>
>         I’ve come up with two options.  If there is any preference or someone has another idea, I’m all ears.
>
>         1) One big patch that can be applied to the current master and reviewed locally from there. Let people play with the final product.
>
>         2) Create, review and commit subsets of stuff, knowing that partial commits will leave either master or a branch to merge later partially working until everything is in place.
>
>         For those curious what it currently looks like, I’ve got a branch on gitlab (https://gitlab.com/_a__w_/yetus , branch y15) that is composed of two patches:
>
>                 - YETUS-568, which does some pre-work to releasedocmaker’s output
>                 - YETUS-15, all of the rest of the build changes in one big patch and the beginnings of yetus-maven-plugin, to demonstrate one of the reasons why I went with maven [2]
>
>         While this is basically two patches, there are definitely parts of YETUS-15 that could be separated out if need be.  It just won’t be fast. :)
>
>         There are a few things missing that I’d prefer to avoid making a requirement since the patch is already pretty large:
>
>                 * asf-site is still built with middleman.  This is a project in and of itself if we want to make it built with mvn site. [2]
>                 * There are still no real tests anywhere and I haven’t built out bats support in mini maven plugin yet.  Getting a working build system is step #1 to start building out tests.
>
> Thoughts?
>
> Thanks!
>
>
>
> 1 - I’ve done a few prototypes with both docs-maven-skin and the devacfr version of reflow-maven-skin.  I think we’ll likely end up building our own skin if we want to replicate the current website.  This isn’t necessarily a bad thing and might even lead to others using it too.  Just be aware that there are some significant source repo layout vs. pom.xml gotchas.
>
> 2 - The other project I’ve currently got cooking is a Yetus Jenkins plugin in an attempt to replace custom build scripts.  The Jenkins provided plugin bits appear to be solidly built on maven.  At that point, we’ve got enough maven stuff happening that we might as well do everything with it.