[
https://jira.codehaus.org/browse/MJS-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Hunt closed MJS-46.
---
Resolution: Not A Bug
I will be proposing a release today.
> Would it be possible to freeze a
[
https://jira.codehaus.org/browse/MJS-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Hunt closed MJS-45.
---
Resolution: Won't Fix
Issues re. m2e will hopefully be resolved as a separate task.
> Eclipse
[
https://jira.codehaus.org/browse/MJS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christopher Hunt closed MJS-48.
---
Resolution: Fixed
> The POM for org.codehaus.mojo:almond:js:${almond.version} and
> org.codehaus.mojo:jqu
[
https://jira.codehaus.org/browse/MJS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298966#comment-298966
]
Christopher Hunt commented on MJS-48:
-
It turns out that the particular problem you have should hav
Hi team,
I think it is worth clarifying here what a patch release is for. Perhaps I
didn't articulate this as well as I could of when I proposed the vote.
The use case of a patch release is where there are problems (bugs) with the
software. In this situation I often see a couple of things happ
[
https://jira.codehaus.org/browse/MJS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298962#comment-298962
]
Christopher Hunt commented on MJS-48:
-
I'm so sorry about that - I did some major re-work on MJS ye
On Thu, 17 May 2012 00:47:11 +0200
Olivier Lamy wrote:
> +1 for patch release faster. (less than 72H : 24H or 48h. rm must be
> able to have shorter time)
>
+1 for this idea, 72h is sometimes very long, ... when nobody else than
yourself is voting to the release you are doing :( which is very c
+1 for patch release faster. (less than 72H : 24H or 48h. rm must be
able to have shorter time)
2012/5/16 Christopher Hunt :
> Hi there,
>
> I propose that the Mojo project should not require votes for patch releases
> (see (1) for a comprehensive definition of a patch release). Voting requires
+1 for minor point releases, you shouldn't be adding new plugin
breaking functionality in a point release anyway
my 2c,
jesse
--
jesse mcconnell
jesse.mcconn...@gmail.com
On Wed, May 16, 2012 at 3:50 PM, Karl Heinz Marbaise wrote:
> Hi,
>
> -1 (binding), cause i'm the same opinion may be we ca
Hi,
-1 (binding), cause i'm the same opinion may be we can think about a
reduce of the voting time. But that's a different story.
[ ] +1
[ ] +0
[ ] -1
The vote is open for 72 hours and will succeed by lazy consensus.
Kind regards,
Christopher Hunt
(1) http://semver.org/
--
I am -1 on NOT requiring a vote, but the voting period can be shorter
for quick bug fixes ( we have done it before )
-Dan
On Wed, May 16, 2012 at 12:07 PM, Mirko Friedenhagen
wrote:
> -1 I agree with Javier that something shorter than 72h may lead to more bugs.
>
> Regards Mirko
>
> On Wed, May
-1 I agree with Javier that something shorter than 72h may lead to more bugs.
Regards Mirko
On Wed, May 16, 2012 at 6:56 PM, Javier Murciego
wrote:
> Hi all
>
> In my opinion, if it is very easy to publish new versions, you
> may, unintentionally,paying less attention to the software and to
> in
I'm -1 on not requiring a vote. I think that votes should be required
for all releases, even patch releases.
If we want to ease the process a little for patch releases, we can do so
in other ways as Stephen outlined. We can discuss that further in a new
thread, depending on how this vote goes.
On
[
https://jira.codehaus.org/browse/MRPM-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298937#comment-298937
]
Nicolas A. Barriga commented on MRPM-79:
Is anyone working on this? Or is this plugin dead?
Hi all
In my opinion, if it is very easy to publish new versions, you may,
unintentionally,paying less attention to the software and to increase the
number of bugs
+1 (binding):
+1: Chris
0:
-1: Javi
-1: Stephen
-1 (binding):
Where binding votes are votes by despots with their hats on.
On Wed,
[
https://jira.codehaus.org/browse/MJS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=298924#comment-298924
]
John Standard commented on MJS-48:
--
I found a work-around, just to get my code to compile and package.
John Standard created MJS-48:
Summary: The POM for org.codehaus.mojo:almond:js:${almond.version}
and org.codehaus.mojo:jquery-amd:js:${jquery.version} is missing
Key: MJS-48
URL: https://jira.codehaus.org/browse/MJS-4
On 16 May 2012 15:41, Olivier Lamy wrote:
> 2012/5/16 Jochen Wiedmann :
>> On Wed, May 16, 2012 at 10:18 AM, Stephen Connolly
>> wrote:
>>> -1 All releases require votes.
>>
>> That's established policy @Apache, right. We don't need to follow
>> necessarily, IMO.
>
> Perso, I tend to agree and li
2012/5/16 Jochen Wiedmann :
> On Wed, May 16, 2012 at 10:18 AM, Stephen Connolly
> wrote:
>> -1 All releases require votes.
>
> That's established policy @Apache, right. We don't need to follow
> necessarily, IMO.
Perso, I tend to agree and like to ease process here.
>
> Jochen
>
>
>
> --
> "Bil
On 16 May 2012 14:43, Jochen Wiedmann wrote:
> On Wed, May 16, 2012 at 10:18 AM, Stephen Connolly
> wrote:
>> -1 All releases require votes.
>
> That's established policy @Apache, right. We don't need to follow
> necessarily, IMO.
Correct, but I would prefer that we do, hence my vote (sans despo
On Wed, May 16, 2012 at 10:18 AM, Stephen Connolly
wrote:
> -1 All releases require votes.
That's established policy @Apache, right. We don't need to follow
necessarily, IMO.
Jochen
--
"Bildung kommt von Bildschirm und nicht von Buch, sonst hieße es ja Buchung."
Dieter Hildebrandt
-
On 16 May 2012 09:18, Stephen Connolly wrote:
> -1 All releases require votes.
Just to clarify, this -1 is *not* with my Despot hat on. If a majority
of the active mojo developers wish to vote +1 and none of the other
Despots vote -1 *with* their hat on, then I would be open to going
along with i
-1 All releases require votes.
If you want to have a shorter time period for a release I am fine with
that, but I think for anything less than 72h lazy consensus should not
apply, i.e. I have run votes in the past where the criteria was "3 x
+1 or 72h lazy consensus which ever comes first"
-Steph
23 matches
Mail list logo
