commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [VOTE] Release commons-sandbox-parent 1
Date Sat, 23 Jun 2007 17:56:41 GMT
Phil Steitz wrote:
> On 6/23/07, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>> On 6/23/07, Dennis Lundberg <dennisl@apache.org> wrote:
>> > Hi,
>> >
>> > It is time to release version 1 of the commons-sandbox-parent. The
>> > latest changes includes updating the parent to commons-parent-3 and
>> > locking down the versions for plugins. Note that I have changed the
>> > artifactId to commons-sandbox-parent, to have a consistent naming 
>> scheme
>> > (compare it to commons-parent).
>> >
>> > This will be the first release and is important because it enables
>> > reproducible builds and site generation for the sandbox components.
>> >
>> <snip/>
>>
>> I haven't yet understood why we need to release anything from the
>> sandbox at all. Sure, reproducibility is a good thing, but I doubt the
>> builds are radically irreproducible without this release; and more
>> importantly, I believe if people are interested in the sandbox
>> components and their reproducibility, they should help get a release
>> out instead.
>>
> 
> I think you have a good point there, Rahul, but I would see this as a
> commons release, not a commons-sandbox release and I personally see
> the benefit (consistent builds, easier to get a sandbox component to
> build when jumping in) as outweighing the negatives (increasing
> likelihood people depend on sandbox components, making the sandbox
> more "comfortable"), especially given that we are *not* releasing any
> sandbox jars.

Yes, I agree. A stable sandbox-parent will make it easier for components 
to move out of the sandbox and into commons proper.

> I have a couple of comments on the pom itself before adding my +1, though.
> 
> Sorry if I missed this before, but I don't see why we should include
> the reports that are added to the sandbox POM.  The ones in the parent
> are the only ones that I see as *always* needed.  I have thought about
> suggesting that we drop the RAT report from there.  At different
> stages of development, different reports make sense and I personally
> prefer to maintain the list per component, other than things like
> javadoc that you are never going to want to turn off.

When I started working on the M2 poms I tried to find a least common 
denominator of the reports that were on the M1 sites.

Some reports are valid for all components while others might only be of 
interest to some. Out aim should be to establish which plugins are 
mandatory (goes into the parent) and which are voluntary (goes into a 
component's pom).

The 3 reports that are in the sandbox parent seems like good candidates 
for the sandbox parent to me:

- Taglist - helps track things that are left to do before a release
- Cobertura - makes sure the tests coverage is good enough
   (this one might move to commons-parent)
- PMD - checks that the code doesn't smell bad
   (this one might also move to commons-parent)

> Another minor comment is that it might be better to move the pom and
> site into a sandbox-parent in svn.  This obviously has nothing to do
> with the release vote.

Yes, that was on my todo-list earlier, but I couldn't find enough time 
back then. I might have a go at that after this release.

> Phil
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message