Re: strings assignment fix

[Jaroslav Hajek]

On Wed, Oct 1, 2008 at 3:51 PM, Jaroslav Hajek <address@hidden> wrote:
> On Wed, Oct 1, 2008 at 3:26 PM, John W. Eaton <address@hidden> wrote:
>> On  1-Oct-2008, Jaroslav Hajek wrote:
>>
>> | Since my write access to savannah is now working, I've applied the
>> | changeset myself.
>>
>> Thanks, I just had not gotten to the point of applying the patch yet.
>>
>> But since I've been using the archive on savannah as a mirror of my
>> local archive, I wasn't actually expecting anyone else to write to it
>> so I'm glad I noticed this message from you before I tried pushing to
>> the archive or I would have been surprised to find that changes had
>> been made to it.
>>
>
> I hope I didn't do any damage; however, I think mercurial by default
> denies a push that would create multiple remote heads, just because of
> this danger.
>
>> However, I would like to move toward having multiple people writing to
>> the archive, but perhaps with several different privilege levels.  For
>> example, we may have some people who are savannah users who can only
>> commit to the web pages, others who can only commit to the sources
>> with approval, and others who can commit to certain portionns of the
>> source tree without needing approval, and others who have global write
>> access without needing approval.
>>
>> I don't think we can actually enforce rules like this other than by
>> simple agreement.
>>
>> Also, we need to have a policy for what to do in case there are
>> conflicts.  For example, I think that the series of changes in the
>> public archive should be a simple linear set of changes.  There should
>> never be more than one head in the archive, and, as much as possible,
>> no half-baked changes and false starts.  I think those are things that
>> belong in local archives on your development system, not in the public
>> archive.
>>
>> But before we open up commits to everyone who joins the Octave project
>> on savannah, I think we should discuss the policy here and then write
>> it up and put it on the Octave web pages.
>>
>
> I'm all for that. The two changesets I pushed today seemed quite
> harmless, so I decided to go ahead and maybe save you some work.
>
> So you have already set up rule 1:
>
> 1. Don't create multiple heads (Mercurial warns if you're about to. So
> don't use push --force)
>
> now, what about:
> 2. Always try make & make check with at least one configuration
> (trying multiple is of course out of most people's reach)
> 3. Small fixes may be pushed without approval; other fixes, extensions
> or other modifications should be posted to ML for discussion &
> approval.
> (We can leave "small" vague or define it somehow).
>

Another question is whether merge changesets are acceptable.
The mercurial book encourages developing using the
clone/pull-commit-merge-push cycle. However, we may instead require
any set of patches to be always rebased against the current tip before
pushed. This is achievable using mq, though not very convenient. Also,
if we settle on this, I'll be glad if we avoid folding patches; it
complicates transplanting to stable branches.

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz