I (Julian Foad) wrote:
>>> There are 19 defects currently tagged 1.9.0-consider. [...]
None are left in 1.9-consider, but there are now many issues in '1.10-consider'
:-)
For the record...
> #4467 "blame youngest to oldest needs to handle SVN_INVALID_REVNUM"
That's fixed.
> #4506 "reintegrat
Branko Čibej wrote:
> On 17.02.2015 16:11, Julian Foad wrote:
>> On 2015-02-16 Branko Čibej wrote:
>>> These are defects tagged 1.9.0-consider: http://s.apache.org/Nft
>>> I'd appreciate getting some help with these; some are probably already
>>> fixed, a few may be release blockers.
>>
>> There a
On 17.02.2015 16:11, Julian Foad wrote:
> On 2015-02-16 Branko Čibej wrote:
>> On 12.02.2015 11:12, Branko Čibej wrote:
>>> Looks like we're on track for branching around the beginning of next week.
> [...]
>>> If there are no further objections, and the pin-externals branch gets
>>> merged s
On 2015-02-16 Branko Čibej wrote:
> On 12.02.2015 11:12, Branko Čibej wrote:
>> Looks like we're on track for branching around the beginning of next week.
[...]
>> If there are no further objections, and the pin-externals branch gets
>> merged soon-ish, I intend to create the 1.9 release branch
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: dinsdag 17 februari 2015 10:51
> To: dev@subversion.apache.org
> Subject: Re: svn info --detail [was: Time to branch 1.9]
>
> On 17.02.2015 10:29, Julian Foad wrote:
> > Ben Reser
On 17.02.2015 10:29, Julian Foad wrote:
> Ben Reser wrote:
>> On 2/16/15 3:57 AM, Branko Čibej wrote:
>>> At first I thought I'd just lowercase the untranslated keys that 'svn
>>> info' displays, replacing spaces with dashes. But there's a strong case
>>> for using the same names as the --xml outpu
Ben Reser wrote:
> On 2/16/15 3:57 AM, Branko Čibej wrote:
>> At first I thought I'd just lowercase the untranslated keys that 'svn
>> info' displays, replacing spaces with dashes. But there's a strong case
>> for using the same names as the --xml output; not because it's easier to
>> implement, bu
On 2/16/15 3:57 AM, Branko Čibej wrote:
> At first I thought I'd just lowercase the untranslated keys that 'svn
> info' displays, replacing spaces with dashes. But there's a strong case
> for using the same names as the --xml output; not because it's easier to
> implement, but because it's at least
On 2/15/15 6:29 PM, Branko Čibej wrote:
> * 4502 Remove FSFS7 disk format changes
> We've had this discussion several times. AIUI Ivan still believes we
> should remove log addressing, even though all of the points he
> raised have been addressed. I propose we close this issue.
I've
Op 16-feb.-2015 12:57 schreef "Branko Čibej" :
>
> On 16.02.2015 12:07, Julian Foad wrote:
> > Branko Čibej wrote:
> >>> * 4556 Replace 'svn youngest' with another UI
> >>> Not much discussion here. I propose we do either option 2
('svnmucc
> >>> youngest'), or rip out the subcommand en
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: maandag 16 februari 2015 03:29
> To: Subversion Development
> Subject: Re: Time to branch 1.9
> * 4558, 4559, 4560: These are all about pin-externals. They shouldn't
> take
On 16.02.2015 12:07, Julian Foad wrote:
> Branko Čibej wrote:
>>> * 4556 Replace 'svn youngest' with another UI
>>> Not much discussion here. I propose we do either option 2 ('svnmucc
>>> youngest'), or rip out the subcommand entirely since there are lots
>>> of ways to the info.
>
Branko Čibej wrote:
>> * 4556 Replace 'svn youngest' with another UI
>> Not much discussion here. I propose we do either option 2 ('svnmucc
>> youngest'), or rip out the subcommand entirely since there are lots
>> of ways to the info.
>
> I'm going to have a go at an alternative solu
On 16.02.2015 10:27, Bert Huijben wrote:
>
>> -Original Message-
>> From: Branko Čibej [mailto:br...@wandisco.com]
>> Sent: maandag 16 februari 2015 03:14
>> To: 'Subversion Development'
>> Subject: Re: Time to branch 1.9
>>
>> On 15.
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: maandag 16 februari 2015 03:14
> To: 'Subversion Development'
> Subject: Re: Time to branch 1.9
>
> On 15.02.2015 14:24, Branko Čibej wrote:
> > On 15.02.2015 01:03, Be
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: maandag 16 februari 2015 03:29
> To: Subversion Development
> Subject: Re: Time to branch 1.9
>
> On 12.02.2015 11:12, Branko Čibej wrote:
> > On 16.01.2015 11:06, Branko Čibej wrote
On 16.02.2015 03:29, Branko Čibej wrote:
> * 4556 Replace 'svn youngest' with another UI
> Not much discussion here. I propose we do either option 2 ('svnmucc
> youngest'), or rip out the subcommand entirely since there are lots
> of ways to the info.
I'm going to have a go at an alt
On 12.02.2015 11:12, Branko Čibej wrote:
> On 16.01.2015 11:06, Branko Čibej wrote:
>> A couple months down the line, and I'd like to make another call for
>> creating the 1.9 release branch. AFAICS the x509 branch still needs
>> merging if we want it in 1.9 (which I think we do, since IIUC trunk
>
On 15.02.2015 14:24, Branko Čibej wrote:
> On 15.02.2015 01:03, Bert Huijben wrote:
>>> -Original Message-
>>> From: Branko Čibej [mailto:br...@wandisco.com]
>>> Sent: donderdag 12 februari 2015 11:13
>>> To: Subversion Development
>>> Subje
On 15.02.2015 01:03, Bert Huijben wrote:
>
>> -Original Message-
>> From: Branko Čibej [mailto:br...@wandisco.com]
>> Sent: donderdag 12 februari 2015 11:13
>> To: Subversion Development
>> Subject: Re: Time to branch 1.9
>>
>> On 16.01.2015 1
> -Original Message-
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: donderdag 12 februari 2015 11:13
> To: Subversion Development
> Subject: Re: Time to branch 1.9
>
> On 16.01.2015 11:06, Branko Čibej wrote:
> > A couple months down the line, and I&
On 16.01.2015 11:06, Branko Čibej wrote:
> A couple months down the line, and I'd like to make another call for
> creating the 1.9 release branch. AFAICS the x509 branch still needs
> merging if we want it in 1.9 (which I think we do, since IIUC trunk
> currently does not handle all certs correctly
On 09.02.2015 16:44, Julian Foad wrote:
> Branko Čibej wrote:
>> All right, it's been three weeks. During this time some massive code
>> churn has happened on trunk, and a couple branches (pin-externals and
>> reuse-ra-session) are assumed to be merge candidates for this release.
>>
>> None of the
Branko Čibej wrote:
> All right, it's been three weeks. During this time some massive code
> churn has happened on trunk, and a couple branches (pin-externals and
> reuse-ra-session) are assumed to be merge candidates for this release.
>
> None of the above is really necessary for a 1.9 release, b
Philip Martin writes:
> Branko Čibej writes:
>
>> The latest last-minute changes introduced a heisencrash in ra-test, and
>> made some C tests run via DAV look for global credentials (e.g., the
>> keychain on the Mac). I haven't tracked these down yet, but surely we
>> can keep trunk more stable
On 09.02.2015 11:11, Philip Martin wrote:
> Branko Čibej writes:
>
>> The latest last-minute changes introduced a heisencrash in ra-test, and
>> made some C tests run via DAV look for global credentials (e.g., the
>> keychain on the Mac). I haven't tracked these down yet, but surely we
>> can keep
Branko Čibej writes:
> The latest last-minute changes introduced a heisencrash in ra-test, and
> made some C tests run via DAV look for global credentials (e.g., the
> keychain on the Mac). I haven't tracked these down yet, but surely we
> can keep trunk more stable than that.
Does the ra-test c
On 16.01.2015 11:06, Branko Čibej wrote:
> A couple months down the line, and I'd like to make another call for
> creating the 1.9 release branch. AFAICS the x509 branch still needs
> merging if we want it in 1.9 (which I think we do, since IIUC trunk
> currently does not handle all certs correctly
On Fri, Jan 16, 2015 at 11:06 AM, Branko Čibej wrote:
> A couple months down the line, and I'd like to make another call for
> creating the 1.9 release branch. AFAICS the x509 branch still needs
> merging if we want it in 1.9 (which I think we do, since IIUC trunk
> currently does not handle all
Branko Čibej wrote:
> A couple months down the line, and I'd like to make another call for
> creating the 1.9 release branch. AFAICS the x509 branch still needs
> merging if we want it in 1.9 (which I think we do, since IIUC trunk
> currently does not handle all certs correctly).
>
> Anything else
A couple months down the line, and I'd like to make another call for
creating the 1.9 release branch. AFAICS the x509 branch still needs
merging if we want it in 1.9 (which I think we do, since IIUC trunk
currently does not handle all certs correctly).
Anything else?
I'd like to propose that we c
On Mon, Nov 17, 2014 at 11:50 AM, Ivan Zhakov wrote:
> On 15 November 2014 04:27, Greg Stein wrote:
>
...
> Second part: vetoes may be applied at any time before a release, on any
> > change going into that release. It does matter whether the change was
> > applied yesterday, or six months ago.
On 15 November 2014 04:27, Greg Stein wrote:
> On Fri, Nov 7, 2014 at 7:07 AM, Ivan Zhakov wrote:
>>
>> On 7 November 2014 03:00, Greg Stein wrote:
>
> ...
>>
>> > In my mind, we have code. Start the release process. If it gets (3) +1
>> > votes
>> > for release, then it goes out the door. Prett
On Fri, Nov 7, 2014 at 7:07 AM, Ivan Zhakov wrote:
> On 7 November 2014 03:00, Greg Stein wrote:
...
> > In my mind, we have code. Start the release process. If it gets (3) +1
> votes
> > for release, then it goes out the door. Pretty simple. Is it just that
> some
> > people don't want Featur
On Fri, Nov 07, 2014 at 11:18:03PM +0100, Johan Corveleyn wrote:
> This long standoff is unfortunate and costly (time consuming), and
> it's quite painful for the community. But what really saddens me is to
> see that there is no longer a constructive chemistry between the two
> of you.
+1
On Fri, Nov 7, 2014 at 7:00 PM, Stefan Fuhrmann
wrote:
>
>
> On Fri, Nov 7, 2014 at 5:49 PM, Ivan Zhakov wrote:
>>
>> On 7 November 2014 17:57, Stefan Fuhrmann
>> wrote:
>> > On Fri, Nov 7, 2014 at 2:07 PM, Ivan Zhakov wrote:
>> >>
>> >> On 7 November 2014 03:00, Greg Stein wrote:
>> >> > Forw
On 07.11.2014 17:46, Mark Phippard wrote:
>> On Nov 7, 2014, at 8:30 AM, Branko Čibej wrote:
>>
>> On 07.11.2014 16:02, Mark Phippard wrote:
On Nov 7, 2014, at 6:46 AM, Branko Čibej wrote:
> On 07.11.2014 14:07, Ivan Zhakov wrote:
> Actually, I have used my veto on the log addre
On Fri, Nov 7, 2014 at 6:04 PM, Evgeny Kotkov
wrote:
> Stefan Fuhrmann writes:
>
> > Let's not repeat the revprop caching debacle. In Berlin this year, you
> > told us that you had identified issues with it and decided to disable it
> > in VisualSVN. Had you told us before 1.8, we might have fou
On Fri, Nov 7, 2014 at 5:49 PM, Ivan Zhakov wrote:
> On 7 November 2014 17:57, Stefan Fuhrmann
> wrote:
> > On Fri, Nov 7, 2014 at 2:07 PM, Ivan Zhakov wrote:
> >>
> >> On 7 November 2014 03:00, Greg Stein wrote:
> >> > Forward progress is the goal. To *hold back* change, then you must
> veto.
On Nov 7, 2014, at 6:57 AM, Stefan Fuhrmann
wrote:
>
>
> My side of the bargain has been trying to think of unnecessary
> restrictions that FSFSv7 might have and then to fix them. It
> started with performance in "unmanaged" setups, continued
> with support for heterogeneous clusters and curren
Stefan Fuhrmann writes:
> Let's not repeat the revprop caching debacle. In Berlin this year, you
> told us that you had identified issues with it and decided to disable it
> in VisualSVN. Had you told us before 1.8, we might have found that the
> underlying infrastructure is too restrictive. If n
On 7 November 2014 17:57, Stefan Fuhrmann wrote:
> On Fri, Nov 7, 2014 at 2:07 PM, Ivan Zhakov wrote:
>>
>> On 7 November 2014 03:00, Greg Stein wrote:
>> > Forward progress is the goal. To *hold back* change, then you must veto.
>> >
>> I agree with that goal but not at the cost of possible mas
> On Nov 7, 2014, at 8:30 AM, Branko Čibej wrote:
>
> On 07.11.2014 16:02, Mark Phippard wrote:
>>> On Nov 7, 2014, at 6:46 AM, Branko Čibej wrote:
>>>
On 07.11.2014 14:07, Ivan Zhakov wrote:
Actually, I have used my veto on the log addressing feature two months
ago [1].
>>> How
On 07.11.2014 16:02, Mark Phippard wrote:
>> On Nov 7, 2014, at 6:46 AM, Branko Čibej wrote:
>>
>>> On 07.11.2014 14:07, Ivan Zhakov wrote:
>>> Actually, I have used my veto on the log addressing feature two months
>>> ago [1].
>> How many times do how many people have to explain that saying "-1"
> On Nov 7, 2014, at 6:46 AM, Branko Čibej wrote:
>
>> On 07.11.2014 14:07, Ivan Zhakov wrote:
>> Actually, I have used my veto on the log addressing feature two months
>> ago [1].
>
> How many times do how many people have to explain that saying "-1"
> without substantiating that with technica
On Fri, Nov 7, 2014 at 2:07 PM, Ivan Zhakov wrote:
> On 7 November 2014 03:00, Greg Stein wrote:
> > Forward progress is the goal. To *hold back* change, then you must veto.
> >
> I agree with that goal but not at the cost of possible massive data
> corruptions in upgraded repositories. "There w
On 07.11.2014 14:07, Ivan Zhakov wrote:
> Actually, I have used my veto on the log addressing feature two months
> ago [1].
How many times do how many people have to explain that saying "-1"
without substantiating that with technical reasons is not a valid veto?
-- Brane
On 7 November 2014 03:00, Greg Stein wrote:
> On Thu, Nov 6, 2014 at 2:07 PM, Ben Reser wrote:
>>
>> On 11/6/14 8:44 AM, Greg Stein wrote:
[...]
>> That said, given the ambiguity of our policy situation here I'm not
>> inclined to
>> try and "fix" any sort of failure on our part to follow such a
On Thu, Nov 6, 2014 at 2:07 PM, Ben Reser wrote:
> On 11/6/14 8:44 AM, Greg Stein wrote:
> > That is no "decision" because it didn't occur here on the list.
>
> It certainly was discussed on this list:
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201306.mbox/%3C51B9C8AB.9090203%40c
On 11/6/14 8:44 AM, Greg Stein wrote:
> That is no "decision" because it didn't occur here on the list.
It certainly was discussed on this list:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201306.mbox/%3C51B9C8AB.9090203%40collab.net%3E
A number of us have been operating under the ass
Hi Greg,
I'm really happy to see you joined to the log-addressing discussion.
> That is no "decision" because it didn't occur here on the list.
Personally, I think that most of the new features should be developed
incrementally in trunk.
But the log addressing feature was already developed in a
On Tue, Nov 4, 2014 at 8:40 AM, Ivan Zhakov wrote:
> On 3 November 2014 18:15, Branko Čibej wrote:
> > There was some talk in the past about "voting" to keep log-addressing on
> > trunk. To put it bluntly: we don't do that, we've never done that, and I
> > don't want to create a precedent that t
On 06.11.2014 00:03, Daniel Shahaf wrote:
> Branko Čibej wrote on Wed, Nov 05, 2014 at 06:32:25 +0100:
>> On 04.11.2014 17:58, Branko Čibej wrote:
>>> You still have, and always will have, the option to raise a veto. With
>>> arguments. About specific problems in the code. I've asked you to do
>>>
Branko Čibej wrote on Wed, Nov 05, 2014 at 06:32:25 +0100:
> On 04.11.2014 17:58, Branko Čibej wrote:
> > You still have, and always will have, the option to raise a veto. With
> > arguments. About specific problems in the code. I've asked you to do
> > that uncountable times. So now please don't t
On 04.11.2014 17:58, Branko Čibej wrote:
> You still have, and always will have, the option to raise a veto. With
> arguments. About specific problems in the code. I've asked you to do
> that uncountable times. So now please don't try to hide behind
> community decisions and raise that veto already
On 04.11.2014 15:40, Ivan Zhakov wrote:
> On 3 November 2014 18:15, Branko Čibej wrote:
>> There was some talk in the past about "voting" to keep log-addressing on
>> trunk. To put it bluntly: we don't do that, we've never done that, and I
>> don't want to create a precedent that turns our consens
On Tue, Nov 4, 2014 at 3:40 PM, Ivan Zhakov wrote:
> On 3 November 2014 18:15, Branko Čibej wrote:
> > There was some talk in the past about "voting" to keep log-addressing on
> > trunk. To put it bluntly: we don't do that, we've never done that, and I
> > don't want to create a precedent that t
On 3 November 2014 18:15, Branko Čibej wrote:
> There was some talk in the past about "voting" to keep log-addressing on
> trunk. To put it bluntly: we don't do that, we've never done that, and I
> don't want to create a precedent that turns our consensus-based process
> into a sham.
I think we s
I've been looking at current activity on trunk, and reviewing the latest
changes in FSFS.
I think it's finally time to bite the bullet and create the 1.9 release
branch. AFAIR, there are two outstanding issues:
* Review and merge of the X509 branch.
* A resolution of the FSFSv7 conundrum.
Un
59 matches
Mail list logo
