maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: RPMs for Maven 3?
Date Wed, 21 Mar 2012 00:23:00 GMT
On 20 March 2012 22:49, Benson Margulies <bimargulies@gmail.com> wrote:
> On Tue, Mar 20, 2012 at 4:45 PM, Jason Chaffee
> <Jason.Chaffee@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.connolly@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 <sochotnicky@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
>>>>>>><manfred@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 <sochotnicky@redhat.com>
>>>>>> Software Engineer - Base Operating Systems Brno
>>>>>>
>>>>>> PGP: 7B087241
>>>>>> Red Hat Inc.                               http://cz.redhat.com
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@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 <sochotnicky@redhat.com>
>>>> Software Engineer - Base Operating Systems Brno
>>>>
>>>> PGP: 7B087241
>>>> Red Hat Inc.                               http://cz.redhat.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message