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'.
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. 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.
Thanks,
Sahoo
Harsha Godugu wrote:
> Sahoo wrote:
>> Harsha,
>>
>> Can you give some examples of what is the scenario that demands
>> engineers to upload binaries to java.net maven repo? And why can't
>> that be done by RE?
> Hi Sahoo,
>
> There is no such scenario where one (engineer) can do but the other
> can not.. :-)
>
> As far as RE's role is concerned, RE will do the publishing/promoting
> of Qualified bits. By qualified, I mean, bits that are tested with
> the regular QA cycle.
>
> Perhaps the scenario that I can refer here is, say module 'A' does
> not depend on any other module. But, other modules X,Y depend on A.
> Developers of X & Y will create dependency rules of their modules on
> A. Now, there is another module Z that depends on Y. Now,
> developers of module Z, look for repositories of A, Y. In order to
> compile and test during dev. cycles there is a need to have A in the
> first place somewhere. Isn't it. Well there can be a workaround to
> include these missing bits of A, somewhere in the classpath during
> development of Z. But, thats not what we wanted; What's wanted is
> seamless maven access of A and other dependencies of Z, for module Z
> in this case.
>
> Thanks,
> Harsha
>
>
>>
>> Thanks,
>> Sahoo
>>
>> Harsha Godugu wrote:
>>> Sahoo wrote:
>>>> Dinesh Patil wrote:
>>>>> Shreedhar Ganapathy wrote:
>>>>>
>>>>>> In addition control wrt sources corresponding to these binaries
>>>>>> will be better with a release engineering process involved.
>>>>>>
>>>>>> Sahoo wrote:
>>>>>>
>>>>>>> Dinesh,
>>>>>>>
>>>>>>> Thanks for documenting this, but I hope we are *not* allowing
>>>>>>> every developer to build binaries in their environment and push
>>>>>>> it into global maven repo, are we? I understand Java removes a
>>>>>>> lot of release engineering issues that are typically associated
>>>>>>> C/C++ world, but that does not mean we allow developers to
>>>>>>> create binaries and push it into maven repo. Binaries that are
>>>>>>> used to build production systems like GlassFish *must* be built
>>>>>>> in controlled environment using processes that are reproducible.
>>>>>>> Why can't binaries be pushed by release engineering team? Then
>>>>>>> they can take care of issues like tagging the workspace, using
>>>>>>> the right compiler version, right flags (e.g. debug/optimize) to
>>>>>>> compile, etc.
>>>>>>
>>>>> I didn't see this email in my inbox yet, may be some mail-client
>>>>> issue.
>>>>>
>>>>> We have a RE process, and tagging/releases will happen from the
>>>>> controlled env. Terena is working on setting up the lab env for V3.
>>>>>
>>>>> This is just a option for developers who are asking for automated
>>>>> process/rules to independently publish their artifacts by the owners!
>>>> Who ensures that those binaries are *not* used by GlassFish?
>>> Just my thoughts..
>>>
>>> There are 2 different scenarios being discussed in this email
>>> thread. one) for the developers and the other) for the so called
>>> release vehicle (production quality GF).
>>>
>>> When GF is released it's released by RE. Not by developers :-)
>>> There is no way during GF bundle installation of binary bits (not
>>> source) will goto maven repository and bring jars
>>> to the Users (Cu's) desktop. If it happens that's error in the
>>> installer.
>>>
>>> All this publishing is ONLY to prepare the ground work for v3
>>> modularization. (Splitting the appserv-rt.jar into various jars and
>>> define dependency on each other jar).
>>>
>>>> Secondly, the Wikipage contains information that can only be used
>>>> by Sun engineers (the m/c is sfbay m/c).Why does a Sun engineer
>>>> have to publish their own binary to maven?
>>> This is interesting question. Today, in v3, if a MODULE owner needs
>>> to define and test a dependency rule, for his/her module, we need
>>> something like maven repository in place. (due to modularization
>>> requirement for v3). This repository could be internal (file based ,
>>> within swan) or it could be external. Looks like we chose external
>>> on the web. That's also, due to open-source reason. Please note
>>> that, only those modules that have a subproject under Glassfish are
>>> on the maven repository for the binary bits. Only those modules are
>>> being published. Rest of the jars (modules ) which are dependent on
>>> the primary jars are/should NOT (be) published. All this is, to
>>> start at some place in Glassfish v3 development.
>>>
>>> Please disregard the part of the URL that was mentioned here to
>>> upload a Jar / whatever bits to a repository. That should not be
>>> the case. Only a module that has a primary dependency on the rest of
>>> the modules in glassfish need to go there. Only modules owners can
>>> decide which jar needs to be on the repository. (or doesn't have to
>>> be ) . And the other condition for the module is, to be a
>>> sub-project of Glassfish. Only a publisher with an access can publish.
>>>
>>> Once a particular module is finished development, the regular
>>> process is followed, which is, RE will pick those particular
>>> versions of Jars for each module, (which is basically, version
>>> number changes..) and then release product for QA.
>>>
>>>
>>> thanks,
>>> Harsha
>>>
>>>>
>>>> Thanks,
>>>> Sahoo
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>