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. 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. > > 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.rpm >>> >>> 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
