[
https://issues.apache.org/jira/browse/HADOOP-14162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907560#comment-15907560
]
Allen Wittenauer commented on HADOOP-14162:
-------------------------------------------
One of the key virtues of a build system is to get things built the exact same
way every time. The single most important build is the release build. It needs
to work the same every where, every time. This is the reason why
create-release doesn't allow for REs to add or replace steps. The most it
should do is allow for certain environmental changes based upon the
platform.... and that's about it.
The other thing to keep in mind is that very very few people actually
understand what is happening in our build process. This includes the vast
majority of committers. The more complex the release process gets or allows,
the more likely there are going to be huge problems down the road. (A great
example of this is the complete disaster that is hdfs-client. See other JIRAs
elsewhere on how, year+ later, that's still being cleaned up.)
To make these points more concrete, right now your sample could potentially
allow for someone to run multiple cleans over the source tree in between
phases. This would mean that someone could sign different versions of bits
that don't correspond with each other. That's super bad.
> Improve release scripts to automate missing steps
> -------------------------------------------------
>
> Key: HADOOP-14162
> URL: https://issues.apache.org/jira/browse/HADOOP-14162
> Project: Hadoop Common
> Issue Type: Improvement
> Components: build
> Reporter: Elek, Marton
> Assignee: Elek, Marton
>
> According to the conversation on the dev mailing list one pain point of the
> release making is that even with the latest create-release script a lot of
> steps are not automated.
> This Jira is about creating a script which guides the release manager throw
> the proces:
> Goals:
> * It would work even without the apache infrastructure: with custom
> configuration (forked repositories/alternative nexus), it would be possible
> to test the scripts even by a non-commiter.
> * every step which could be automated should be scripted (create git
> branches, build,...). if something could be not automated there an
> explanation could be printed out, and wait for confirmation
> * Before dangerous steps (eg. bulk jira update) we can ask for confirmation
> and explain the
> * The run should be idempontent (and there should be an option to continue
> the release from any steps).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
