Re: [RESULT] [VOTE] Release commons-sandbox-parent 1
Phil Steitz wrote: +1 - need to do this anyway. On 6/29/07, Dennis Lundberg <[EMAIL PROTECTED]> 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. Done. I also deployed the pom. There is one glitch with the release process for it though. When you do "mvn release:perform" the default goals for the deploy plugin is "deploy, deploy:site". This means that it deployed the site for the sandbox-parent, which doesn't really exist. Anyway, I managed to copy the correct page from the production server before the site was synced from people. Just something to remember if we ever do another release of the sandbox 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release commons-sandbox-parent 1
+1 - need to do this anyway. On 6/29/07, Dennis Lundberg <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release commons-sandbox-parent 1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT] [VOTE] Release commons-sandbox-parent 1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT] [VOTE] Release commons-sandbox-parent 1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
+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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/24/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: On 23.06.2007, at 18:59, Rahul Akolkar wrote: > On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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. >> > > > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 23.06.2007, at 18:59, Rahul Akolkar wrote: On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
Rahul Akolkar wrote: On 6/24/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Rahul Akolkar wrote: > On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: >> On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: >> > >> > >> > 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 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. 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. 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/[EMAIL PROTECTED] 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? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/24/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Rahul Akolkar wrote: > On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: >> On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: >> > >> > >> > 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 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. 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. 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? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: > On 6/23/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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. > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/24/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote: Rahul Akolkar wrote: > On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: >> On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: >> > >> > >> > 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
Rahul Akolkar wrote: On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 6/23/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Phil Steitz <[EMAIL PROTECTED]> wrote: On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: > > > 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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
Phil Steitz wrote: On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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. > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Wendy Smoak <[EMAIL PROTECTED]> wrote: On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Rahul Akolkar <[EMAIL PROTECTED]> wrote: On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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. > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release commons-sandbox-parent 1
On 6/23/07, Dennis Lundberg <[EMAIL PROTECTED]> 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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release commons-sandbox-parent 1
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
