[VOTE] Release commons-sandbox-parent 1

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[VOTE] Release commons-sandbox-parent 1

Dennis Lundberg-2
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.

This vote is for revision 550041, which will have its version number
changed to 1 when the release is done. A SNAPSHOT has been deployed to
the Apache snapshot repo if you want to take it for a spin.

[ ] +1
[ ] =0
[ ] -1

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Rahul Akolkar
On 6/23/07, Dennis Lundberg <[hidden email]> 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.

-Rahul


> This vote is for revision 550041, which will have its version number
> changed to 1 when the release is done. A SNAPSHOT has been deployed to
> the Apache snapshot repo if you want to take it for a spin.
>
> [ ] +1
> [ ] =0
> [ ] -1
>
> --
> Dennis Lundberg
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Wendy Smoak
In reply to this post by Dennis Lundberg-2
On 6/23/07, Dennis Lundberg <[hidden email]> wrote:

> This will be the first release and is important because it enables
> reproducible builds and site generation for the sandbox components.

Since you have a policy against releasing sandbox components, why not
just deploy snapshots of the sandbox parent pom, and advance to the
next snapshot version (without a release) when there is a change?

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Phil Steitz
In reply to this post by Rahul Akolkar
On 6/23/07, Rahul Akolkar <[hidden email]> wrote:

> On 6/23/07, Dennis Lundberg <[hidden email]> 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.

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.

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.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Phil Steitz
In reply to this post by Wendy Smoak
On 6/23/07, Wendy Smoak <[hidden email]> wrote:
> On 6/23/07, Dennis Lundberg <[hidden email]> wrote:
>
> > This will be the first release and is important because it enables
> > reproducible builds and site generation for the sandbox components.
>
> Since you have a policy against releasing sandbox components, why not
> just deploy snapshots of the sandbox parent pom, and advance to the
> next snapshot version (without a release) when there is a change?
>

I guess the issue there is that you then have to add the snapshot repo
explicitly just to *build* a sandbox component or generate its web
site.  We want to force people to do that if they *depend* on sandbox
jars, but just building a sandbox component should not require it IMO.

As I said above, I see the sandbox parent pom as a commons release,
not a sandbox release, since it is part of the infrastructure of
commons.  What Dennis wants to release is not a snapshot, but a stable
release of this part of commons infrastructure, just like the
commons-parent pom.

Phil
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Dennis Lundberg-2
In reply to this post by Phil Steitz
Phil Steitz wrote:

> On 6/23/07, Rahul Akolkar <[hidden email]> wrote:
>> On 6/23/07, Dennis Lundberg <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Rahul Akolkar
In reply to this post by Rahul Akolkar
On 6/23/07, Phil Steitz <[hidden email]> wrote:

> On 6/23/07, Rahul Akolkar <[hidden email]> wrote:
> > <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.
>
<snip/>

I appreciate you taking the time to elaborate. I am not impressed by
any of these benefits (I'm not trying to be curt, I don't know how
else to put it). Moreover, I agree about the negatives.

I see this as being distilled, and worse -- recurring, busy work.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Rahul Akolkar
In reply to this post by Phil Steitz
On 6/23/07, Phil Steitz <[hidden email]> wrote:

> On 6/23/07, Wendy Smoak <[hidden email]> wrote:
> > On 6/23/07, Dennis Lundberg <[hidden email]> wrote:
> >
> > > This will be the first release and is important because it enables
> > > reproducible builds and site generation for the sandbox components.
> >
> > Since you have a policy against releasing sandbox components, why not
> > just deploy snapshots of the sandbox parent pom, and advance to the
> > next snapshot version (without a release) when there is a change?
> >
>
> I guess the issue there is that you then have to add the snapshot repo
> explicitly just to *build* a sandbox component or generate its web
> site.  We want to force people to do that if they *depend* on sandbox
> jars, but just building a sandbox component should not require it IMO.
>
<snip/>

And it doesn't require that to build either -- install the parent.

I suspect anyone who has used m2 even minimally is aware of the
bootstrapping problems with development builds and how to solve them.
For everyone else (and I'm sure we will get questions), the sandbox
components should have 'install parent pom' as step 0 of their
'building' pages.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Dennis Lundberg-2
In reply to this post by Rahul Akolkar
Rahul Akolkar wrote:

> On 6/23/07, Phil Steitz <[hidden email]> wrote:
>> On 6/23/07, Rahul Akolkar <[hidden email]> wrote:
>> > <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.
>>
> <snip/>
>
> I appreciate you taking the time to elaborate. I am not impressed by
> any of these benefits (I'm not trying to be curt, I don't know how
> else to put it). Moreover, I agree about the negatives.

So what are the negatives here? I have not seen anyone put forward any
arguments yet as to why releasing the sandbox parent pom would be bad.
We are *not* talking about releasing sandbox components! Please,
enlighten me.

> I see this as being distilled, and worse -- recurring, busy work.

Well, Carlos asked for a release of the pom. I imagine that he has a
good reason for this. So I stepped up to do the release. If I don't mind
doing the job - why should you care?

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Carlos Sanchez-4
On 6/24/07, Dennis Lundberg <[hidden email]> wrote:

> Rahul Akolkar wrote:
> > On 6/23/07, Phil Steitz <[hidden email]> wrote:
> >> On 6/23/07, Rahul Akolkar <[hidden email]> wrote:
> >> > <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.
> >>
> > <snip/>
> >
> > I appreciate you taking the time to elaborate. I am not impressed by
> > any of these benefits (I'm not trying to be curt, I don't know how
> > else to put it). Moreover, I agree about the negatives.
>
> So what are the negatives here? I have not seen anyone put forward any
> arguments yet as to why releasing the sandbox parent pom would be bad.
> We are *not* talking about releasing sandbox components! Please,
> enlighten me.
>
> > I see this as being distilled, and worse -- recurring, busy work.
>
> Well, Carlos asked for a release of the pom. I imagine that he has a
> good reason for this. So I stepped up to do the release. If I don't mind
> doing the job - why should you care?

the problem is that if you try to check out and build one of the
sandbox components it won't work, you'd need to checkout the whole
sandbox just for one of them just to get the parent. I think is not a
big deal and will make the life of people trying the sandbox
components easier

>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Phil Steitz
In reply to this post by Rahul Akolkar
On 6/23/07, Rahul Akolkar <[hidden email]> wrote:

> On 6/23/07, Phil Steitz <[hidden email]> wrote:
> > On 6/23/07, Wendy Smoak <[hidden email]> wrote:
> > > On 6/23/07, Dennis Lundberg <[hidden email]> wrote:
> > >
> > > > This will be the first release and is important because it enables
> > > > reproducible builds and site generation for the sandbox components.
> > >
> > > Since you have a policy against releasing sandbox components, why not
> > > just deploy snapshots of the sandbox parent pom, and advance to the
> > > next snapshot version (without a release) when there is a change?
> > >
> >
> > I guess the issue there is that you then have to add the snapshot repo
> > explicitly just to *build* a sandbox component or generate its web
> > site.  We want to force people to do that if they *depend* on sandbox
> > jars, but just building a sandbox component should not require it IMO.
> >
> <snip/>
>
> And it doesn't require that to build either -- install the parent.
>
> I suspect anyone who has used m2 even minimally is aware of the
> bootstrapping problems with development builds and how to solve them.
> For everyone else (and I'm sure we will get questions), the sandbox
> components should have 'install parent pom' as step 0 of their
> 'building' pages.
>

I guess that's what I see as the problem.  IMO we should strive to
make our components as easy to build as possible and this should apply
to the sandbox as well as proper.  Having to separately download,
build and install the parent (correct me if I am wrong here, though if
I am it sort of illustrates my point ;-) is a needless PITA for those
trying to build a sandbox m2 component from source.  Maven is supposed
to make building easier and admittedly sometimes it does not.  This is
a case where needless futzing to get a build to work could be avoided
by just publishing the parent so a straight build from the checked out
sandbox component source can work.   It is a maven pet peeve of mine
that in some cases special local incantations have to be performed to
get a build to work.  I like to do everything possible to eliminate
that.

The site is also an issue.  For better or for worse, site
extensibility is tied to pom inheritance (again, correct me if I am
wrong), so having a stable and consistent sandbox site build depends
on having the sandbox parent POM available.  Again, local
build-and-install can workaround this, but why force people to do that
and why give up consistency (whatever random svn grab is used will
determine what shows up)?

I guess I also agree with Dennis that I fail to see the negatives.
Regarding the "recurring busy work" this is a do-ocracy and Dennis is
stepping up to do this release.  I will also help out as needed to
maintain this POM.

Phil


> -Rahul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Rahul Akolkar
In reply to this post by Dennis Lundberg-2
On 6/24/07, Dennis Lundberg <[hidden email]> wrote:

> Rahul Akolkar wrote:
> > On 6/23/07, Phil Steitz <[hidden email]> wrote:
> >> On 6/23/07, Rahul Akolkar <[hidden email]> wrote:
> >> > <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.
> >>
> > <snip/>
> >
> > I appreciate you taking the time to elaborate. I am not impressed by
> > any of these benefits (I'm not trying to be curt, I don't know how
> > else to put it). Moreover, I agree about the negatives.
>
> So what are the negatives here? I have not seen anyone put forward any
> arguments yet as to why releasing the sandbox parent pom would be bad.
> We are *not* talking about releasing sandbox components! Please,
> enlighten me.
>
<snip/>

See line below, and less importantly, some comments above.


> > I see this as being distilled, and worse -- recurring, busy work.
>
> Well, Carlos asked for a release of the pom. I imagine that he has a
> good reason for this.
<snap/>

imagine? I can only go by reasons stated in this thread (Carlos' and
Phil's subsequent posts do not have a new reason IMO).


> So I stepped up to do the release. If I don't mind
> doing the job - why should you care?
>
<snap/>

Because this is a Commons release.

Because (as a more general statement beyond the ASF workings) I
believe that merely having someone available to do something, does not
by itself, make doing that thing worthwhile.

Because (in terms of the ASF workings) do-ocracies do not imply that
others should not care about what you are doing when its about
releasing artifacts.

Because we will have to:
 * Release periodically
    - Needs process cycles: RMs, votes (thanks for your cycles on this one)
    - Who knows how often this will have to happen (lesser the better)
 * Update all sandbox component POMs to keep parent versions in sync etc.

I vote:

-0 (non-binding)

-Rahul



> --
> Dennis Lundberg
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Dennis Lundberg-2
Rahul Akolkar wrote:

> On 6/24/07, Dennis Lundberg <[hidden email]> wrote:
>> Rahul Akolkar wrote:
>> > On 6/23/07, Phil Steitz <[hidden email]> wrote:
>> >> On 6/23/07, Rahul Akolkar <[hidden email]> wrote:
>> >> > <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.
>> >>
>> > <snip/>
>> >
>> > I appreciate you taking the time to elaborate. I am not impressed by
>> > any of these benefits (I'm not trying to be curt, I don't know how
>> > else to put it). Moreover, I agree about the negatives.
>>
>> So what are the negatives here? I have not seen anyone put forward any
>> arguments yet as to why releasing the sandbox parent pom would be bad.
>> We are *not* talking about releasing sandbox components! Please,
>> enlighten me.
>>
> <snip/>
>
> See line below, and less importantly, some comments above.
>
>
>> > I see this as being distilled, and worse -- recurring, busy work.
>>
>> Well, Carlos asked for a release of the pom. I imagine that he has a
>> good reason for this.
> <snap/>
>
> imagine? I can only go by reasons stated in this thread (Carlos' and
> Phil's subsequent posts do not have a new reason IMO).

Here is the message that made me start this thread.
http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200706.mbox/%3c1a5b6c410706212116j237232c6t2d126013f303588@...%3e

Apparently he is working on commons CSV, so if releasing this pom can
help him do that then it's a Good Thing TM. It might even help CSV to
get promoted out of the sandbox.

>> So I stepped up to do the release. If I don't mind
>> doing the job - why should you care?
>>
> <snap/>
>
> Because this is a Commons release.
>
> Because (as a more general statement beyond the ASF workings) I
> believe that merely having someone available to do something, does not
> by itself, make doing that thing worthwhile.
>
> Because (in terms of the ASF workings) do-ocracies do not imply that
> others should not care about what you are doing when its about
> releasing artifacts.

You misread my previous comment. I was not talking about *what* is being
done, but *who* is doing it. You said that releasing the sandbox pom
will require work, meaning someone has to do it. I then said that I'll
do it. Can we just leave it at that.

If we focus on *what* is being done instead. Can you tell me what is
wrong with releasing the sandbox parent? Besides the fact that it
requires someone has to do the actual work.

> Because we will have to:
> * Release periodically

Not necessarily. The consensus when we started with Maven 2 poms was
that we try to keep the parent(s) stable. Try something out in a
component first and it's deemed good for all, then we'll move it to the
parent. In my opinion the parent defines the common build process that
all components should use. And that should not change that often.

>    - Needs process cycles: RMs, votes (thanks for your cycles on this one)

Like I said I'm volunteering to be RM for this release. If you don't
have the cycles to check the release, you are perfectly entitled to
refrain from voting.

>    - Who knows how often this will have to happen (lesser the better)

Agreed.

> * Update all sandbox component POMs to keep parent versions in sync etc.

Again this doesn't have to be a lot of work. Once we get the first
release of the sandbox pom out, it is necessary to update the poms of
all sandbox components at least once. Again I'm volunteering here.

> I vote:
>
> -0 (non-binding)
>
> -Rahul
>
>
>
>> --
>> Dennis Lundberg


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Torsten Curdt
In reply to this post by Rahul Akolkar

On 23.06.2007, at 18:59, Rahul Akolkar wrote:

> On 6/23/07, Dennis Lundberg <[hidden email]> 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.

IMO that's not very pragmatic. I think we would want to lower the  
barrier and get people involved. Providing a POM will make builds  
easier for the people that we want to attract.

What I am failing to understand is what the fuzz is about. It's a  
POM ...it's metadata - not an artifact. No code!

So here is my +1 for the release.

cheers
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Niall Pemberton
On 6/24/07, Torsten Curdt <[hidden email]> wrote:

>
> On 23.06.2007, at 18:59, Rahul Akolkar wrote:
>
> > On 6/23/07, Dennis Lundberg <[hidden email]> 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.
>
> IMO that's not very pragmatic. I think we would want to lower the
> barrier and get people involved. Providing a POM will make builds
> easier for the people that we want to attract.
>
> What I am failing to understand is what the fuzz is about. It's a
> POM ...it's metadata - not an artifact. No code!
>
> So here is my +1 for the release.

+1 to what Torsten says and +1 to the release

Niall

> cheers
> --
> Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] Release commons-sandbox-parent 1

Dennis Lundberg-2
In reply to this post by Dennis Lundberg-2
+1 from me

Dennis Lundberg 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.
>
> This vote is for revision 550041, which will have its version number
> changed to 1 when the release is done. A SNAPSHOT has been deployed to
> the Apache snapshot repo if you want to take it for a spin.
>
> [ ] +1
> [ ] =0
> [ ] -1
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[RESULT] [VOTE] Release commons-sandbox-parent 1

Dennis Lundberg-2
In reply to this post by Dennis Lundberg-2
The results are in:

+1
Dennis Lundberg
Torsten Curdt
Niall Pemberton

-0
Rahul Akolkar


I will proceed with the release.


Dennis Lundberg 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.
>
> This vote is for revision 550041, which will have its version number
> changed to 1 when the release is done. A SNAPSHOT has been deployed to
> the Apache snapshot repo if you want to take it for a spin.
>
> [ ] +1
> [ ] =0
> [ ] -1
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RESULT] [VOTE] Release commons-sandbox-parent 1

Martin van den Bemt-3
This is not a Jakarta thing anymore :)

Mvgr,
Martin

Dennis Lundberg wrote:

> The results are in:
>
> +1
> Dennis Lundberg
> Torsten Curdt
> Niall Pemberton
>
> -0
> Rahul Akolkar
>
>
> I will proceed with the release.
>
>
> Dennis Lundberg 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.
>>
>> This vote is for revision 550041, which will have its version number
>> changed to 1 when the release is done. A SNAPSHOT has been deployed to
>> the Apache snapshot repo if you want to take it for a spin.
>>
>> [ ] +1
>> [ ] =0
>> [ ] -1
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RESULT] [VOTE] Release commons-sandbox-parent 1

Dennis Lundberg-2
In reply to this post by Dennis Lundberg-2
Hmm, it seems that I spoke too soon. We need a place in subversion to
put the tagged release. Since the pom is currently in sandbox-trunks
there simply is no tags directory to put the release in.

I propose that we move the sandbox parent out of sandbox-trunks and into
a commons-sandbox-parent directory in commons proper. That would make it
a sibling to commons-parent.

The only thing left in sandbox-trunks then would be the site for the
sandbox, which consists of one (1) page. That could easily be moved down
into a sandbox-site directory, that would be a sibling to the sandbox
components.

Thoughts?

Dennis Lundberg wrote:

> The results are in:
>
> +1
> Dennis Lundberg
> Torsten Curdt
> Niall Pemberton
>
> -0
> Rahul Akolkar
>
>
> I will proceed with the release.
>
>
> Dennis Lundberg 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.
>>
>> This vote is for revision 550041, which will have its version number
>> changed to 1 when the release is done. A SNAPSHOT has been deployed to
>> the Apache snapshot repo if you want to take it for a spin.
>>
>> [ ] +1
>> [ ] =0
>> [ ] -1
>>
>
>


--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RESULT] [VOTE] Release commons-sandbox-parent 1

Phil Steitz
+1 - need to do this anyway.

On 6/29/07, Dennis Lundberg <[hidden email]> wrote:

> Hmm, it seems that I spoke too soon. We need a place in subversion to
> put the tagged release. Since the pom is currently in sandbox-trunks
> there simply is no tags directory to put the release in.
>
> I propose that we move the sandbox parent out of sandbox-trunks and into
> a commons-sandbox-parent directory in commons proper. That would make it
> a sibling to commons-parent.
>
> The only thing left in sandbox-trunks then would be the site for the
> sandbox, which consists of one (1) page. That could easily be moved down
> into a sandbox-site directory, that would be a sibling to the sandbox
> components.
>
> Thoughts?
>
> Dennis Lundberg wrote:
> > The results are in:
> >
> > +1
> > Dennis Lundberg
> > Torsten Curdt
> > Niall Pemberton
> >
> > -0
> > Rahul Akolkar
> >
> >
> > I will proceed with the release.
> >
> >
> > Dennis Lundberg 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.
> >>
> >> This vote is for revision 550041, which will have its version number
> >> changed to 1 when the release is done. A SNAPSHOT has been deployed to
> >> the Apache snapshot repo if you want to take it for a spin.
> >>
> >> [ ] +1
> >> [ ] =0
> >> [ ] -1
> >>
> >
> >
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12