So the current management process in JIRA is a bit rusty, but is intended
to be (as in I used to do it that way but no reason why anyone else should):
New issue comes in (Version Unscheduled)
We assign it to a future version. We use 3.2 for 'yes, soon' and 3.x for
'later'.
It gets done with said f
These are all sitting in our pull request queue:
https://github.com/apache/commons-lang/pulls?direction=desc&page=1&sort=created&state=open
Not all are open, I know #1 is in the code but I don't know how to close
the requests.
On Sun, Oct 13, 2013 at 9:12 PM, Phil Steitz wrote:
>
>
> Could be I am misunderstanding the proposal. Do you mean a) RM is
> not obligated to do anything but tag a release and create tarballs
> or b) RM should just be trusted to "do the right thing" in getting
> stuff published and other other
On Sun, Oct 13, 2013 at 7:09 PM, Ted Dunning wrote:
> On Mon, Oct 14, 2013 at 2:55 AM, Henri Yandell wrote:
>
> > I propose release votes be simple revision based requests and involve no
> > artifact churn :)
> >
>
> Hen,
>
> This is a pretty good idea.
>
> But I still think that artifact churn
On 2013-10-14, sebb wrote:
> On 9 October 2013 05:43, Stefan Bodewig wrote:
>> why vote on Nexus staged artifacts if the tarball is fine? I'm not
>> talking about releasing to MC directly but rather about not pushing
>> anything to Nexus before the vote on the tarball has passed. This could
>>
I think enough issues have been identified to warrant a second RC.
I'll take care of the bad version number in the release notes as well as
the PMD warnings in the ARJ-Package. ArjArchiveEntry's test coverage
has already been increased in trunk.
We should talk about the Clirr report further and
On 10/13/13 9:05 PM, Stefan Bodewig wrote:
> On 2013-10-13, Phil Steitz wrote:
>
>> I am sorry. I forgot one other thing to verify. The clirr report
>> complains about dropping a field. Is this spurious / not really an
>> issue?
> Ah yes, I should have talked about that.
>
> It is a protected fi
On 10/13/13 6:55 PM, Henri Yandell wrote:
> On Tuesday, October 8, 2013, Benedikt Ritter wrote:
>
>> Hi,
>>
>> one of the points that seem to always come up once in a while is the
>> process of releasing components. I've never done it myself so I'm asking
>> people who have done it:
>
> I find myse
On 2013-10-13, Oliver Heger wrote:
> The artifacts look good, the build works fine with Java 1.7 on Windows
> 7. I tried to build with Java 1.5, but got:
> Tests in error:
> SevenZTestCase.testSevenZArchiveCreationUsingLZMA2:37->testSevenZArchiveCreati
> on:59 ╗ OutOfMemory
> XZTestCase.testXZ
On 2013-10-13, Phil Steitz wrote:
> I am sorry. I forgot one other thing to verify. The clirr report
> complains about dropping a field. Is this spurious / not really an
> issue?
Ah yes, I should have talked about that.
It is a protected field in the Tar*Stream classes which should have
never
On Mon, Oct 14, 2013 at 2:55 AM, Henri Yandell wrote:
> I propose release votes be simple revision based requests and involve no
> artifact churn :)
>
Hen,
This is a pretty good idea.
But I still think that artifact churn will be a necessary process in order
to get enough valid QA on the artif
On Tuesday, October 8, 2013, Benedikt Ritter wrote:
> Hi,
>
> one of the points that seem to always come up once in a while is the
> process of releasing components. I've never done it myself so I'm asking
> people who have done it:
I find myself wondering why a release vote is anything more tha
OK - sorry for misunderstanding you. It appears we are in agreement and my use
of "majority" in that sentence is incorrect. The wording I quoted from the
httpd page is much clearer (at least 3 +1 votes and no vetoes).
Ralph
On Oct 13, 2013, at 6:20 PM, Ted Dunning wrote:
> Ralph,
>
> I comp
On 10/13/13 3:51 PM, Ted Dunning wrote:
> Ralph,
>
> Majority votes at ASF almost never require a majority of all possible
> voters. Almost always the (plus > 3 && plus > minus) convention is used.
>
> As you can find in innumerable threads as well, consensus among the
> discussion participants is
On Oct 13, 2013, at 4:31 PM, sebb wrote:
> Recently, I found that the Maven project RMs don't bother removing these.
> So the files are released to Maven Central with the rest.
> I assume that the Maven Central administrators don't care about the
> extra space needed.
>
> Now ASF source releases
Ralph,
I completely agree that this vote wasn't consensus.
But where you say
As I understand this, consensus means that a majority must vote and there
> must not be any -1 votes among those who voted.
I disagree. The only quorum typically required for ASF consensus votes is
3 +1's, not a majo
Please re-read my message. James stated " We definitely have enough people
voting to be considered a consensus (consensus != unanimous)." My point was to
quote what Roy posted a few days ago that said while consensus isn't unanimous
it also isn't the simple majority vote either, so to state tha
On Sun, Oct 13, 2013 at 7:38 PM, sebb wrote:
> On 13 October 2013 20:43, Phil Steitz wrote:
>> On 10/13/13 12:39 PM, Phil Steitz wrote:
>>> On 10/12/13 10:31 PM, Stefan Bodewig wrote:
Hi
since Compress 1.5 we've fixed a few bugs but most notably added
read-only support for LZM
On Sun, Oct 13, 2013 at 7:51 PM, sebb wrote:
> On 12 October 2013 09:08, Olivier Lamy wrote:
>> why not having those files deployed?
>
> See my reply in another thread.
> The Maven project deploys these to Maven Central.
>
> The primary release channel for the bin and src tarballs must be the
> A
On Sun, Oct 13, 2013 at 2:49 PM, Mark Thomas wrote:
> On 13/10/2013 16:58, Gary Gregory wrote:
>> I can't use JIRA on my phone. Pages do not scroll and the mobile view
>> doesn't include attachments! WTF!
>
> I've never had any problems using Bugzilla on any mobile device. Fancy
> switching ;) ?
On 12 October 2013 09:08, Olivier Lamy wrote:
> why not having those files deployed?
See my reply in another thread.
The Maven project deploys these to Maven Central.
The primary release channel for the bin and src tarballs must be the
ASF mirror system, not Maven Central (MC).
Does this mean th
On 13 October 2013 20:26, Benedikt Ritter wrote:
> The problem I'm seeing with deploying the side as needed is, that the
> JavaDoc report will the so latest trunk and not the latest released API. In
> [LANG] we have the link to the latest realese JavaDoc. Compress for example
> has no such link. S
On 13 October 2013 20:43, Phil Steitz wrote:
> On 10/13/13 12:39 PM, Phil Steitz wrote:
>> On 10/12/13 10:31 PM, Stefan Bodewig wrote:
>>> Hi
>>>
>>> since Compress 1.5 we've fixed a few bugs but most notably added
>>> read-only support for LZMA standalone, uncompressed ARJ and full support
>>> fo
On 11 October 2013 10:23, Emmanuel Bourg wrote:
> Le 11/10/2013 01:35, Matt Benson a écrit :
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons. I think it would be immensely
>> helpful for those of us who have been at least p
James,
You succeeded in creating a second thread.
It is the first thread that had a reverted subject line. Ironically, it
was one of your posts that reverted the subject line ... likely related to
the confusion you had in the first place with gmail.
Check the archives. They show the subject li
There were two threads. As I explained, the first two DISCUSSION/VOTE
threads were getting mingled together in gmail, so I started another thread
for the VOTE hoping to avoid confusion (apparently I failed in that).
On Sunday, October 13, 2013, Ted Dunning wrote:
> Ralph,
>
> Majority votes at
On 11 October 2013 05:16, Stefan Bodewig wrote:
> On 2013-10-11, Matt Benson wrote:
>
>> We're all still talking about the release process, but in all honesty I've
>> not done it for several years at Commons. I think it would be immensely
>> helpful for those of us who have been at least part way
On 13 October 2013 20:47, Phil Steitz wrote:
> On 10/13/13 8:09 AM, James Carman wrote:
>> Well, it has been 72 hours, so let's tally up the votes. As I see it
>> (counting votes on both lists):
>>
>> +1s
>> James Carman
>> Romain Manni-Bucau
>> Matt Benson
>> Benedikt Ritter
>> Bruno Kinoshita
>
Ralph,
Majority votes at ASF almost never require a majority of all possible
voters. Almost always the (plus > 3 && plus > minus) convention is used.
As you can find in innumerable threads as well, consensus among the
discussion participants is preferable for big changes (like moving to git).
C
On 9 October 2013 14:06, Emmanuel Bourg wrote:
> Le 08/10/2013 21:25, sebb a écrit :
>
>> Note: we must update Javadoc plugin to the latest version to ensure
>> that the scripting bug is fixed.
>
> Done
>
>> I expect there are several parts of the main pom that can be removed
>> as the parent pom
On 9 October 2013 05:43, Stefan Bodewig wrote:
> On 2013-10-08, Benedikt Ritter wrote:
>
>> you are involved in other projects (like log4j2) how do they do it? Is
>> it easier to release log4j2 than it is to release for example [lang]?
>
> Over the past year I've cut releases at the ASF for Common
On 9 October 2013 05:14, Siegfried Goeschl wrote:
> Hi Gary,
>
> A new major release requires a new package name, site, build and so on -
> think of commons-lang v1,2,3
Huh?
A major release does not imply an API break, though the reverse is true.
> Cheers,
>
> Siegfried Goeschl
>
>> Am 08.10.2
IMO (and it is just my opinion), all commons projects should eventually move to
git. The problem is that commons is more a disjoint group of small, fairly
unrelated projects than a true umbrella project. As such, it might make more
sense for a few projects to move before moving everything.
I'
Actually, if you read Roy's post from a few days ago on Incubator General you
will find that consensus is != to majority or unanimity. See
http://mail-archives.apache.org/mod_mbox/incubator-general/201310.mbox/ajax/%3CC2FDB244-459D-4EC4-954A-7A7F6C4B179B%40gbiv.com%3E
from which I quote below:
Le 12/10/2013 10:07, Olivier Lamy a écrit :
> Why removing those files? It's is strictly forbidden by any Apache
> rules to have those?
No, but it just clutters Maven Central. The .asc file contains a signed
hash of the file, there is no need to have two additional hashes of a hash.
> why creat
On Sun, Oct 13, 2013 at 5:06 PM, Phil Steitz wrote:
>
> As I said, I am fine with experimenting and based on that experience
> seeing if we can actually get consensus. I stand by my statement
> above that the VOTE was premature and while "legal" from ASF
> perspective it is not a good practice to
On 10/13/13 1:52 PM, James Carman wrote:
> Phil,
>
> While I appreciate your concerns, the vote is a valid vote:
>
> "Votes on procedural issues follow the common format of majority rule
> unless otherwise stated. That is, if there are more favourable votes
> than unfavourable ones, the issue is co
+1
--
Olivier
On Oct 13, 2013 4:32 PM, "Stefan Bodewig" wrote:
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the current
--
Olivier
On Oct 14, 2013 6:39 AM, "Phil Steitz" wrote:
>
> On 10/12/13 10:31 PM, Stefan Bodewig wrote:
> > Hi
> >
> > since Compress 1.5 we've fixed a few bugs but most notably added
> > read-only support for LZMA standalone, uncompressed ARJ and full support
> > for 7z.
> >
> > I have not creat
Phil,
While I appreciate your concerns, the vote is a valid vote:
"Votes on procedural issues follow the common format of majority rule
unless otherwise stated. That is, if there are more favourable votes
than unfavourable ones, the issue is considered to have passed --
regardless of the number o
in the spirit of better late than never
+1 - yes, move to Git
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Am 13.10.2013 22:08, schrieb Benedikt Ritter:
> 2013/10/13 Oliver Heger
>
>> Am 11.10.2013 22:55, schrieb Benedikt Ritter:
>>> 2013/10/11 Oliver Heger
>>>
Am 11.10.2013 22:01, schrieb Benedikt Ritter:
> 2013/10/11 Oliver Heger
>
>> Am 11.10.2013 02:10, schrieb Phil Steitz:
2013/10/13 Oliver Heger
> Am 11.10.2013 22:55, schrieb Benedikt Ritter:
> > 2013/10/11 Oliver Heger
> >
> >> Am 11.10.2013 22:01, schrieb Benedikt Ritter:
> >>> 2013/10/11 Oliver Heger
> >>>
> Am 11.10.2013 02:10, schrieb Phil Steitz:
> >
> >
> >> On Oct 10, 2013, at 4:41 PM, O
Am 11.10.2013 22:55, schrieb Benedikt Ritter:
> 2013/10/11 Oliver Heger
>
>> Am 11.10.2013 22:01, schrieb Benedikt Ritter:
>>> 2013/10/11 Oliver Heger
>>>
Am 11.10.2013 02:10, schrieb Phil Steitz:
>
>
>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy wrote:
>>
>> Even I like
On 10/13/13 8:09 AM, James Carman wrote:
> Well, it has been 72 hours, so let's tally up the votes. As I see it
> (counting votes on both lists):
>
> +1s
> James Carman
> Romain Manni-Bucau
> Matt Benson
> Benedikt Ritter
> Bruno Kinoshita
> Gary Gregory
> Luc Maisonobe
> Oliver Heger
> Christian
On 10/13/13 12:39 PM, Phil Steitz wrote:
> On 10/12/13 10:31 PM, Stefan Bodewig wrote:
>> Hi
>>
>> since Compress 1.5 we've fixed a few bugs but most notably added
>> read-only support for LZMA standalone, uncompressed ARJ and full support
>> for 7z.
>>
>> I have not created a RC website as the onl
The artifacts look good, the build works fine with Java 1.7 on Windows
7. I tried to build with Java 1.5, but got:
Tests in error:
SevenZTestCase.testSevenZArchiveCreationUsingLZMA2:37->testSevenZArchiveCreati
on:59 ╗ OutOfMemory
XZTestCase.testXZCreation:44 ╗ OutOfMemory Java heap space
Tests
On 10/12/13 10:31 PM, Stefan Bodewig wrote:
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the current
> website would be the
The problem I'm seeing with deploying the side as needed is, that the
JavaDoc report will the so latest trunk and not the latest released API. In
[LANG] we have the link to the latest realese JavaDoc. Compress for example
has no such link. So a redeploy (for example to add some more
documentation)
Am 13.10.2013 20:51, schrieb Henri Yandell:
> On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe wrote:
>
>> Le 13/10/2013 17:35, Stefan Bodewig a écrit :
>>> Hi all
>>>
>>> in the recent release vote for Compress Gary and I had very different
>>> opinions on the importance of the site build for rele
On 10/13/13 11:51 AM, Henri Yandell wrote:
> On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe wrote:
>
>> Le 13/10/2013 17:35, Stefan Bodewig a écrit :
>>> Hi all
>>>
>>> in the recent release vote for Compress Gary and I had very different
>>> opinions on the importance of the site build for releas
I've the same problem on my iPad. Seems to be related to the new Jira
release that has been deployed the other day.
2013/10/13 Gary Gregory
> I can't use JIRA on my phone. Pages do not scroll and the mobile view
> doesn't include attachments! WTF!
>
>
> Sent via the Samsung Galaxy Note® 3, an A
On Sun, Oct 13, 2013 at 11:03 AM, Luc Maisonobe wrote:
> Le 13/10/2013 17:35, Stefan Bodewig a écrit :
> > Hi all
> >
> > in the recent release vote for Compress Gary and I had very different
> > opinions on the importance of the site build for release candidates.
> >
> > On 2013-10-13, Gary Grego
On 13/10/2013 16:58, Gary Gregory wrote:
> I can't use JIRA on my phone. Pages do not scroll and the mobile view doesn't
> include attachments! WTF!
I've never had any problems using Bugzilla on any mobile device. Fancy
switching ;) ?
Mark
--
Le 13/10/2013 17:35, Stefan Bodewig a écrit :
> Hi all
>
> in the recent release vote for Compress Gary and I had very different
> opinions on the importance of the site build for release candidates.
>
> On 2013-10-13, Gary Gregory wrote:
>
>> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig wro
Phil, I'm for whatever makes it easier. In the new release test project,
let's start "green field" and see what we come up with. If we see enough
boilerplate to merit a parent, then we will extract those bits and make
one. If not, then it's every component for themselves.
On Sunday, October 13,
I understand your frustration, Phil, particularly if you're the type who
has never liked the flavor of the Maven kool-aid... I know I struggled
fruitlessly for years against Maven! However, the biggest benefit I see to
the parent pom is the site management. I can't justify us propping up some
cust
On 10/11/13 3:53 AM, Gilles wrote:
> On Thu, 10 Oct 2013 18:35:07 -0500, Matt Benson wrote:
>> We're all still talking about the release process, but in all
>> honesty I've
>> not done it for several years at Commons. I think it would be
>> immensely
>> helpful for those of us who have been at lea
Group (shared) Maven 3 Build Definition (Java 1.6)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Continuum-Build-Host: vmbuild
X-Continuum-Project-Id: 64
X-Continuum-Project-Name: Commons Compress
Online report :
http://vmbuild.apache.org
JIRA created:
https://issues.apache.org/jira/browse/INFRA-6859
On Sun, Oct 13, 2013 at 4:17 AM, Siegfried Goeschl
wrote:
> +1 on that
>
> I did a few releases over the year and had ALWAYS issues - for me the
> biggest obstacles are
>
> * getting a positive vote on a RC (that's a different story
On 10/13/13 8:58 AM, Gary Gregory wrote:
> I can't use JIRA on my phone. Pages do not scroll and the mobile view doesn't
> include attachments! WTF!
I have the same problem with Eclipse - he he
Phil
>
>
> Sent via the Samsung Galaxy Note® 3, an AT&T 4G LTE smartphone
--
I can't use JIRA on my phone. Pages do not scroll and the mobile view doesn't
include attachments! WTF!
Sent via the Samsung Galaxy Note® 3, an AT&T 4G LTE smartphone
Hi all
in the recent release vote for Compress Gary and I had very different
opinions on the importance of the site build for release candidates.
On 2013-10-13, Gary Gregory wrote:
> On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig wrote:
>> I have not created a RC website as the only differenc
On 2013-10-13, Gary Gregory wrote:
> +1
Thanks.
> BUT the following are not blockers but should be improved if another RC is
> cut:
> - Low (27%) code coverage for the new class
> https://commons.apache.org/proper/commons-compress/cobertura/org.apache.commons.compress.archivers.arj.ArjArchiveEn
Well, it has been 72 hours, so let's tally up the votes. As I see it
(counting votes on both lists):
+1s
James Carman
Romain Manni-Bucau
Matt Benson
Benedikt Ritter
Bruno Kinoshita
Gary Gregory
Luc Maisonobe
Oliver Heger
Christian Grobmeier
Torsten Curdt
-1s
Mark Thomas
Thomas Vandahl
Damjan Jov
+1
Emmanuel Bourg
Le 13/10/2013 07:31, Stefan Bodewig a écrit :
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC website as the only difference to the curre
+1
BUT the following are not blockers but should be improved if another RC is cut:
- Low (27%) code coverage for the new class
https://commons.apache.org/proper/commons-compress/cobertura/org.apache.commons.compress.archivers.arj.ArjArchiveEntry.html
- PMD violations in new code, for example ArjAr
"Foo 1.2 RC1 is available for review" ? ;)
Gary
On Sun, Oct 13, 2013 at 1:31 AM, Stefan Bodewig wrote:
> Hi
>
> since Compress 1.5 we've fixed a few bugs but most notably added
> read-only support for LZMA standalone, uncompressed ARJ and full support
> for 7z.
>
> I have not created a RC websit
Website fixed :)
On Sat, Oct 12, 2013 at 10:22 AM, Henri Yandell wrote:
> I think this is the priority issue:
>
> https://issues.apache.org/jira/browse/LANG-894
>
> If we can't fix and deploy our website, having new code is largely
> pointless :)
>
> I'm guessing we're on some new (yeah I k
+1 on that
I did a few releases over the year and had ALWAYS issues - for me the
biggest obstacles are
* getting a positive vote on a RC (that's a different story)
* getting the release out of the door - a test project would help
immensely since I can blow it up without any consequences
Che
70 matches
Mail list logo
