[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stable branch will freeze.

From: Marius Vollmer
Subject: Re: Stable branch will freeze.
Date: 15 Mar 2002 20:54:44 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Thien-Thi Nguyen <address@hidden> writes:

>    From: Marius Vollmer <address@hidden>
>    Date: 15 Mar 2002 00:29:06 +0100
>    I just made the lonely decision to be more rigorous about the "stable"
>    branch_release-1-6 branch.
>     We need to be much more rigorous about really keeping the stable
>     branch stable.  From now on, only release critical, uncontroversial
>     fixes will be allowed.  I intend to be firm on this.  We are not
>     getting anywhere without restraining us from putting new stuff into
>     the stable branch.
>    Of course, it is already controversial exactly what is release
>    critical.  I'll just be deciding this. :)
> sorry, it sounds like you have some delusions of absolute control here.
> please get well soon (or demonstrate your position by removing my write
> privs so i can unsubscribe from guile development and use in good
> conscience -- TIA).

Please reconsider.  It would be sad to lose your contributions, but I
think we could manage.

>    Consequences: the guile-snarf changes need to be brought back to a
>    state where guile-snarf is completely compatible with the last
>    guile-snarf that has been installed.  It can add features, but must
>    not remove any.  Also it should define SCM_MAGIC_SNARFER in addition
>    to SCM_MAGIC_SNARF_INIT when pre-processing the C file.  The fact that
>    SCM_MAGIC_SNARFER is defined should be documented, while
>    SCM_MAGIC_SNARF_INIT should not be documented.  Thien-Thi, I can make
>    these changes if you want me to.  Please feel free to hack on
>    guile-snarf in the HEAD branch.  I really think your work on the
>    snarfer is important, please don't get me wrong.
> i don't want you to make these changes because the changes do not
> support encapsulation and robustness, but i suspect you'll make them
> anyway.

Yes.  I'm not sure that you have the same changes in mind as I do,
tho.  I would just be making sure that the default (without any -o) is
that the output is written to stdout.

> in the future someone will complain and someone will decide they
> need to be changed back.  will you do those changes then, too?

No, they will already be in 1.7. ;-)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]