Re: RFC - cleaning up /etc

[David Kastrup]

Lars Magne Ingebrigtsen <address@hidden> writes:

> Uhm -- I thought we were in a feature freeze.  I.e., we should
> concentrate on fixing bugs, and not do lots of non-bug-related changes.
>
> Removing things from etc might be nice, but it doesn't seem to have
> anything to do with fixing bugs.

Yes, that sounds like after-release material.  Also quite unrelated to
the git move, so it might make sense for Eric to take it off his
post-release work list.  He can still return to it when Git and VC have
stopped biting him.

> Stefan, please clarify.
>
> As for moving to git, I'm for it, even though git is inferior to bzr in
> a few ways (no bound branches, totally icky sha revisions instead of
> human-parseable revnos,

Well, for a _distributed_ version control system, I prefer icky.
"human-parseable" is not compatible with "automatically unique without
requiring coordination".

> a `C-x v g' that's so slow it's unusable (but David is fixing that),

Will still take a year to trickle down to typical users.  Man, my fix
better be good with everybody taking its efficacy for granted.

> worse vc-mode support).

That sounds more like a hen-and-egg problem than anything else.  I mean,
the hen-and-egg situation was a main motivator for moving Emacs to bzr
at a time when it was actually painful to do so.

> But isn't all this also taking all focus from doing meaningful bug
> work?  How about waiting until the next feature period opens?

It's one of the sad realities of software development that alternating
"stabilization" and "feature" periods mean that if you only start
working on features when the "feature" period is there, you won't finish
before "stabilization" sets in.  The "feature" period is when _prepared_
features get committed.

-- 
David Kastrup