Re: recent changes to org files

[David Kastrup <dak@gnu.org>]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Well, checking in a patch with changes would not lead to a conflict
> in an area that I have not modified.

It will lead to a successful merge.  Nobody said that synchronization
requires no diligence at all.

> So just checking in patches will not remove a bug that has (clearly
> by accident) been introduced in one of those clean-up operations
> where many files are are modified in order to implement a rule like
> "don't use next-line in lisp programs".  These changes typically
> affect many files, and it is impossible for the developer who does
> the change to be sure in all cases that he has done the right thing.

And it is pretty impossible for the developer to figure out
maintainers for every single file, mail them all, keep book of who
replies within what time frame, and then react accordingly.

> The only way to make sure is to run these changes by the maintainer.

And the most reliable way to do this is to check them in, with a
proper log entry.

> In that past, that has happened sometimes: I get an email with
> proposed changes, with the request to check them before they are
> committed. For example, Stefan has been doing things like this, and
> I appreciate his comments and additions, and the way he handles it,
> a lot.

Single-line purported bugfixes are not really additions or comments.

>> If some code is in violation of the Emacs development guidelines,
>> the reason should be documented so that people _know_ about it and
>> leave it alone.  Silently reverting the change in a manner that
>> looks like an accident will not achieve this.
>
> Yes.  Of course I only reverted the change "by accident" without an
> accompanying change log.  Still, I am maintaining that the copy I
> work on every day is the most reliable one, and that any significant
> changes should be run by me.

That means that improvements by several people must not be combined,
and that the results of uncombined changes have to compete on overall
reliability.  I can't see this.  There is no competition going on.
Instead, every contributor strives to improve reliability in the code
he is overseeing.

>> Basically you are asking that nothing, including bug fixes, may be
>> committed to org-mode except by yourself.
>
> No, this is not correct.  I request that I changes are run by me
> first,

Which means that they must not be committed.  So my description _is_
correct.  Whether you yourself do the actual work of committing or
someone does it on your request is a technical detail.  The sum of it
all is that you don't accept anybody else to take responsibility for
committing anything to org-mode.  And that means that there is no
sense in org-mode being maintained inside of Emacs' CVS if no changes
must ever be introduced that don't simultaneously are checked into
your personal CVS.

>> Being a maintainer does not mean that nobody else may do work on
>> the code.  It means that people in general respect you having the
>> last word.  But it is the last, not the only word.
>
> Exactly my words.

Your words don't match your proposed way of working.  Emacs
maintainance quite often means bulk changes: new interfaces and
semantics are introduced, and things like the multitty changes and the
unicode changes necessitate global work (as do added bytecompiler
warnings).  It is not feasible to do the update work only after
figuring out prospective maintainers for every file.  The only hope to
get things like this done is to do the changes and let the maintainers
check for them.  And merge time is certainly an important point of
time for checking it (though regularly checking for diffs in that area
is not amiss either for a maintainer actually interested in his code).

If your workflow does not permit fixes to be applied to Emacs CVS, the
only sane solution short of adjusting your workflow is to remove
org-mode from Emacs CVS.  Only in that manner can it be assured that
bug fixes and interface changes and other things can actually persist.

-- 
David Kastrup