On 3/20/12 5:23 PM, "Stephen Connolly" <stephen.alan.conno...@gmail.com> wrote:
>On 20 March 2012 22:49, Benson Margulies <bimargul...@gmail.com> wrote: >> On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee >> <jason.chaf...@betfair.com> wrote: >>> Just a suggestion. >>> >>> If you can find some people who are not currently commuters and are >>> interested in do thing just this very thing, could they be a partial >>> committer, only working on the RPM's and not the other parts of maven? >>> >>> In my opinion, this is the spirit of open source software. I know >>> everywhere I have been my IT/OPS wanted RPM's for maven. >>> >>> Jason >> >> It's actually simpler than this. If someone posts a reasonable patch >> -- where reasonable means (in my opinion), "could be part of the >> automated Jenkins builds, doesn't inordinately inconvenience people >> building the core on Windows", then some committer might commit it. >> *I* might commit it. > >I might commit it too, but I ain't going to have time to test it, and >I would only commit it in a separate module in a separate tree so that >it could be released separately, but others may have a different >view... I don't see myself raising veto on RPM builds I agree that they should be separate modules, I would expect some type of integration tests that would be written with the modules. However, that is problematic unless maven has a CI environment that could ramp up VM's quickly for the different distributions and test them. Anyway, I would love to see RPM's, but I am not really interested myself in doing them either. Hopefully, someone else can find a good solution and do this work and we can get it added, but I do see the challenges. > >> >> If one of my fellow PMC members found it bottomlessly horrible, they >> could exercise their post-commit review powers and tell me to yank it >> until we had a formal vote. >> >> Once it was in place, then the next question would be, "Would any >> release manager take responsibility for including the results in a >> vote?" >> >> Now, keep in mind that Apache releases are SOURCE releases. The >> binaries are for convenience only. Still, I agree with Stephen C. that >> it would be bad form to put RPMs on /dist that hadn't been supervised >> by the PMC. >> >> The final question, then, as Stephen has pointed out, would be, "would >> a sufficiency of PMC members vote +1 and not -1 for a release with >> them." So far, no PMC member has expressed any enthusiasm for that >> step. >> > >Actually -1 votes don't count. You cannot veto releases, you only >need 3 x +1... so we could have 3 x +1 and 21 x -1 and the release >manager is still allowed to proceed with the release! [It would be bad >form to proceed from my PoV, but the rules allow it] > >-Stephen > >> >> >>> >>> On 3/20/12 7:47 AM, "Stephen Connolly" >>><stephen.alan.conno...@gmail.com> >>> wrote: >>> >>>>To get the RPMs released, you are going to have to find 3xPMC members >>>>willing to vote +1 for each time you run the release. >>>> >>>>Your best option is to have the RPMs as a separate module that depends >>>>on org.apache.maven:apache-maven and repackages that producing just an >>>>RPM. >>>> >>>>Do not try to integrate it into the core build of Maven, as you will >>>>have too few PMC members willing to vote on the RPM being in the core >>>>dist. >>>> >>>>Profiles would be evil for this case... separate module outside of the >>>>main build is fine. >>>> >>>>-Stephen >>>> >>>>P.S. in case it was not clear from my previous mail, I will not be >>>>using what little time I have to vote on RPM releases. There are >>>>currently 24 people on the PMC list. If you cannot find at least 3 of >>>>them willing to consider voting +1 on RPM releases, then you are SooL >>>> >>>>On 20 March 2012 14:19, Stanislav Ochotnicky <sochotni...@redhat.com> >>>>wrote: >>>>> >>>>> I would *really* like for maven to produce RPMs as alternative dist >>>>> output, but I understand your position. I had a quick look into >>>>> rpm-maven-plugin and I believe a reasonable RPM output could be >>>>>achieved >>>>> by using it in with non-default profile. That should also prevent any >>>>> problems with building for Windows users (or all that don't really >>>>>care >>>>> about rpm output). Or do you consider even this approach unviable? >>>>>It's >>>>> OK if you do, just want to know if I should keep looking for some >>>>> compromise or if it's really out of the question. >>>>> >>>>> One way or the other I created a simple spec/srpm based on binary >>>>>maven >>>>> release: >>>>> >>>>> Spec URL: http://sochotni.fedorapeople.org/packages/maven.spec >>>>> SRPM URL: >>>>>http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.src.rpm >>>>> BINRPM URL: >>>>>http://sochotni.fedorapeople.org/packages/maven-3.0.4-1.fc16.noarch.rp >>>>>m >>>>> >>>>> I should note that I don't really intend to support this solution. >>>>>But I >>>>> might update this together with maven releases since I assume it >>>>>should >>>>> be fairly easy. >>>>> >>>>> Another request: would you consider adding bash-completion[1] to >>>>>maven >>>>>sources >>>>> someplace? We have a slightly modified version in Fedora. >>>>> >>>>> [1] http://sochotni.fedorapeople.org/packages/maven-bash-completion >>>>> >>>>> Quoting Jason van Zyl (2012-03-20 13:33:32) >>>>>>Stanislav, >>>>>> >>>>>>If you're going to attempt something do it as an external action that >>>>>>takes the output of the primary build. Don't make something that >>>>>>augments the standard build process. That's invasive and for people >>>>>>building on Windows if problems arise they can't really fix it. If >>>>>>you >>>>>>make an entirely separate build that can consume the output of the >>>>>>standard build then people who are interested can take a look, those >>>>>>who don't care aren't affected. I don't want any specific >>>>>>modifications >>>>>>made to the existing build process to accommodate RPMs. I think a >>>>>>separate build would be more useful as it will be specific to the >>>>>>task >>>>>>at hand and people can use it as they like to produce RPMs for >>>>>>themselves if they so choose. >>>>>> >>>>>>On Mar 20, 2012, at 5:25 AM, Stanislav Ochotnicky wrote: >>>>>> >>>>>>> >>>>>>> Quoting Jos Backus (2012-03-19 23:40:43) >>>>>>>> Hi Manfred, >>>>>>>> >>>>>>>> On Mon, Mar 19, 2012 at 3:32 PM, Manfred Moser >>>>>>>><manf...@mosabuam.com> wrote: >>>>>>>>> Jos, >>>>>>>>> >>>>>>>>> I agree with you in the sense that any open source project that >>>>>>>>>cares about >>>>>>>>> a wide user base should try to provide packages of its software >>>>>>>>>that are >>>>>>>>> useful to as many people as possible. >>>>>>>> >>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> Therefore e.g. the Jenkins effort to offer all sorts of installs >>>>>>>>>is >>>>>>>>>laudible >>>>>>>>> imho. >>>>>>>> >>>>>>>> Yes. It increases adoption by lowering the threshold to >>>>>>>>install/manage >>>>>>>> the software. >>>>>>>> >>>>>>>>> However for Maven this is clearly not going to happen from the >>>>>>>>>current team. >>>>>>>>> There is just too much bad experience with old Maven packages >>>>>>>>>supplied by >>>>>>>>> various parties. >>>>>>>> >>>>>>>> That's too bad, really, as it will cause people like me to >>>>>>>>reinvent >>>>>>>> the wheel. But I understand the perspective and it's not my place >>>>>>>>to >>>>>>>> tell people how to spend their time. >>>>>>> >>>>>>> Well let's see if we can change this. I'll try to prepare patch for >>>>>>> maven to generate rpms during build that would both work, and not >>>>>>>make >>>>>>> FHS proponents get angry (too much). If it gets commited: woot. If >>>>>>>not >>>>>>> at least I can tell my future kids I tried :-) That said I >>>>>>>understand >>>>>>> what would additional dist target entail for Maven devs. No hard >>>>>>> feelings either way >>>>>>> >>>>>>> >>>>>>>>> At this stage I would suggest to make the package yourself the >>>>>>>>>way >>>>>>>>>you want >>>>>>>>> and host it on your own yum repo. Then you can do what you want >>>>>>>>>and >>>>>>>>>provide >>>>>>>>> it to other people as well. >>>>>>>> >>>>>>>> Indeed. >>>>>>> >>>>>>> If you disregard a bit of common sense of Linux distribution wrt >>>>>>>FHS >>>>>>>and >>>>>>> similar things you could create rpm by using binary maven tarball. >>>>>>>It >>>>>>> is definitely easier than adding rpm output to Maven and >>>>>>>supporting it >>>>>>> on different distributions :-) >>>>>>> >>>>>>>>> You could try to push it to rpm repositories outside Fedora/Red >>>>>>>>>Hat >>>>>>>>>in case >>>>>>>>> any one is interested but it all depends on the effort you want >>>>>>>>>to >>>>>>>>>spend. >>>>>>>>> Most people want to be sure they have an Apache quality package >>>>>>>>>and >>>>>>>>>that is >>>>>>>>> only availalble in tar gz or zip with the well known >>>>>>>>>disadvantages.. >>>>>>>> >>>>>>>> Yes, that's why it's desirable that the software producer produces >>>>>>>>the packages. >>>>>>>> >>>>>>>>> In fact imho the slow uptake of new versions e.g. Maven 3 vs >>>>>>>>>Maven >>>>>>>>>2 is in >>>>>>>>> part due to the fact that no binaries for the various OS are >>>>>>>>>available that >>>>>>>>> would get automatically updates as part of regular updates.. >>>>>>>> >>>>>>>> Yes, I think so, too. Not providing packages hampers adoption of >>>>>>>>newer >>>>>>>> versions because people will stick with the old versions that >>>>>>>>tends >>>>>>>>to >>>>>>>> ship with their distro if there's no easy way to upgrade. That is >>>>>>>>why >>>>>>>> I would think that the Maven folks would be interested in this, >>>>>>>>but >>>>>>>>it >>>>>>>> sounds like it's not a priority. >>>>>>>> >>>>>>>> Thanks for your response, Manfred, and for everyone else's input >>>>>>>>in >>>>>>>>this thread. >>>>>>> >>>>>>> I like your approach. Kudos for handling this conversation in a >>>>>>> civilized manner even though you were (more-less) turned down. >>>>>>>Let's >>>>>>>see >>>>>>> if we can ease your pain a little bit... >>>>>>> >>>>>>> -- >>>>>>> Stanislav Ochotnicky <sochotni...@redhat.com> >>>>>>> Software Engineer - Base Operating Systems Brno >>>>>>> >>>>>>> PGP: 7B087241 >>>>>>> Red Hat Inc. http://cz.redhat.com >>>>>>> >>>>>>> >>>>>>>-------------------------------------------------------------------- >>>>>>>- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>> >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Jason >>>>>> >>>>>>---------------------------------------------------------- >>>>>>Jason van Zyl >>>>>>Founder, Apache Maven >>>>>>http://twitter.com/jvanzyl >>>>>>--------------------------------------------------------- >>>>>> >>>>>>A party which is not afraid of letting culture, >>>>>>business, and welfare go to ruin completely can >>>>>>be omnipotent for a while. >>>>>> >>>>>> -- Jakob Burckhardt >>>>> >>>>> -- >>>>> Stanislav Ochotnicky <sochotni...@redhat.com> >>>>> Software Engineer - Base Operating Systems Brno >>>>> >>>>> PGP: 7B087241 >>>>> Red Hat Inc. http://cz.redhat.com >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> >>> >>>________________________________________________________________________ >>> In order to protect our email recipients, Betfair Group use SkyScan >>>from >>> MessageLabs to scan all Incoming and Outgoing mail for viruses. >>> >>> >>>________________________________________________________________________ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >For additional commands, e-mail: dev-h...@maven.apache.org > ________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses. ________________________________________________________________________ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
