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 > > 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.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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
