>
> On Feb 19, 2008, at 7:38 PM, Sahoo wrote:
>
>> Harsha,
>>
>> Release Engineering is a specialized role, just like development is.
>> Some persons are exceptionally skilled to do both the jobs very
>> well, but typically the same person does not (and should not) take
>> up RE's responsibilities as well as developer's. When they do take
>> up both the responsibilities, then they must distinguish between
>> their roles. This does not scale well and is error prone. I expect
>> environment used by RE to be much more controlled than developers'.
>
Sahoo, I agree with what is said above. No debate on RE's roles :-)
>>
>> Every module in your example is a separate maven artifact. I want RE
>> to build and upload binaries for every module to maven repository
>> - be it nightly, promoted or milestone builds.
>
I disagree with that. Why? It's impractical and highly inefficient,
Also note that, this is only initial groundwork to embrace maven into
v3. Once, we've at least a few initial repos in place, a parallel
development effort could take place. After this stage, one can always
pick and choose which version of an artifact a developer wants to in
their dev. cycle. During that time, we will have clearly established,
nightly/latest, promoted, released artifacts in place provided by RE.
>> They can automate that process. I don't want to use a binary that is
>> not produced by RE during my day to day development, let alone
>> using such binary in the final product.
>
To automate the process we need code in place. That code is being
developed now.. by developers :-) later used by RE to psuh. One
most important task for RE is to track the versions of various artifacts
for a release, nightly and then promoted bits.
In addition... I completely agree with what Ken has said here- A highly
efficient approach.
I think, we've discussed enough on this, so that, 'best-practices'
team will take this topic further to their meetings, to come with a
streamlined approach.
thanks,
Harsha
>>
>>
>
> There are cases where two or more modules will be evolving
> simultaneously.
> This can be awkward to deal with in a central repository - single
> maven repository
> system. Here the better solution is to use hg: the developers
> involved in the
> concurrently evolving modules can share a parent workspace that is a
> child of the
> master workspace, and each can get updates as needed. But this only
> works
> for modules in the same workspace, and this may not always be the case.
>
> In more complex cases, developers will likely have a need for
> obtaining binary
> modules that are not ready for RE checkin to the main repository.
> How will
> we manage this? I don't want every such case to go through RE.
> Maven can certainly support local and remote repositories,
> and there are a number of repository managers that support maven. It
> seems that
> we may at times require complicated sharing arrangements for multi-
> module
> development. In such cases, a developer may wish to publish an artifact
> to an intermediate repository (not the master), and this is probably
> best done
> exactly the same way RE promotes an artifact to the master repository.
>
> I also want to think about how much of REs role can be automated.
> Many of us are
> planning to automate as much as possible of our testing using Hudson,
> and this
> includes SQE and CTS tests. Once a module is known to pass all
> required tests, it is
> ultimately the developer that decides when a module needs to be updated.
> The developer then works with the RE process to make sure that the
> module
> is updated, archived, and properly published to the appropriate
> repository.
> Other teams in Sun do this with hierarchical gate keeper
> arrangements, so that
> related modules are integrated at one level, producing artifacts that
> may then be
> pushed up the tree to a larger integration. The main things that RE
> needs to do
> is to make sure that all artifacts are properly tracked, and that all
> artifacts in any
> version can always be traced back to the exact source used to create
> them.
> In mercurial, this corresponds to the changeset ID in the mercurial
> repository
> used to create the artifact.
>
> Ken.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>