[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r36625 - in branches/1.6.x: . subversion/po subversion/svn

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Tue, 17 Mar 2009 23:13:19 -0500

First of all, thanks for helping keep the German translations up-to-
date. We could use such thorough translator effort on many more
languages.

However, on the issue of merging to the release branch, I must agree
with Brane and Greg. At this point in the cycle, the release branch
is sacred, and touching anything therein must be done with extreme
prudence. (Even after a .0 release, we're still pretty paranoid about
what goes in.) We aren't saying the change is invalid or wrong or
that it will never get released.

We are asking you to trust the rules of the community, and if there
are inefficiencies, to help us find and correct them. For instance,
would it be possible to script the merging of translations to the
release branch? If so, it is something the RM could do prior to each
release, thereby freeing translators to work on other things.

Anyway, I reverted r36625 on the release branch in r36647.

-Hyrum

On Mar 17, 2009, at 12:27 PM, Branko Cibej wrote:

> Jens,
>
> every rule we have is there for a reason. None were imposed without
> discussion and consent of the committers. You agreed to abide by these
> rules when you accepted partial-commit access. You are free to propose
> different rules, but you are not free to just ignore them when they're
> not convenient.
>
> Jens Seidel wrote:
>> Hi,
>>
>> Greg your points are true. I will be more carefully in the future.
>> Nevertheless no harm happened.
>>
>> On Tue, Mar 17, 2009 at 04:28:41PM +0100, Greg Stein wrote:
>>
>>> On Tue, Mar 17, 2009 at 15:57, Jens Seidel
>>> <jensseidel_at_users.sf.net> wrote:
>>>
>>>> On Tue, Mar 17, 2009 at 03:56:01PM +0100, Greg Stein wrote:
>>>>
>>>>> You touched a file in svn/main.c on the release branch. That is
>>>>> not
>>>>> allowed. Your commit area is limited to subversion/po/ only.
>>>>> *ESPECIALLY* when it comes to the *RELEASE BRANCH*.
>>>>>
>>>>> This is Bad.
>>>>>
>>>> I'm sorry, but why was the help message not updated before? I
>>>> reported it
>>>>
>>> It was updated on trunk, and there is an outstanding VOTE to
>>> update it
>>> on the branch.
>>>
>>
>> And once someone merges it the person forgets (as usual) to update
>> translations resulting in a very large help message which is again
>> untranslated.
>>
>>
>>>> All in all it's a minor change but I consider help messages
>>>> important and it
>>>> should not lie.
>>>>
>>> That is not your call to make. There is a VOTE for it. That is how
>>> things work. None of the committers (full or partial) are free to
>>> simply make changes in the release branch because they consider
>>> something "important".
>>>
>>
>> OK, but you are aware of the fact that many bugs could already be
>> fixed
>> in Subversion since years without such (sometimes useless) rules?
>> Just
>> ask people to follow common sense should be all rule required.
>>
>> (I once sent e.g. a trivial patch which removes the dependence on a
>> installed svn binary during build or install (don't remember). I'm
>> sure
>> it is still not applied. I will not repeat old discussions but you
>> have to
>> agree that not everything is optimal with Subversions development
>> model.)
>>
>>
>>> It is a minor change, but not *that* minor. How do I know that the
>>> new
>>> help output is correct? I can't just eyeball it. I have to set up a
>>>
>>
>> Yep, this is difficult. But I ensured that the old output is wrong by
>> searching the source for the old message and this didn't occurred.
>> But I
>> found the new string as expected (and as in trunk) in the tree
>> conflict
>> code.
>>
>>
>>> tree conflict somehow and then run "svn status" to see what the
>>> *actual* output is, and then compare it against what is being put
>>> into
>>> the help text. Thus, it is not an "obvious fix".
>>>
>>
>> This test happened already in trunk. I'm 100% sure that the old
>> code in
>> 1.6.x was wrong, I'm to 95% sure that the new code is OK. I'm to
>> 99% sure
>> it's better than the old string.
>>
>>
>>> As it stands, it was scheduled to be fixed in 1.6.1. Not in 1.6.0.
>>>
>>
>> I will not object any further. Do whatever you prefer ...
>>
>> Jens
>>
>>
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1342404

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1345110
Received on 2009-03-18 05:13:44 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.