Stable branch will freeze.

Stable branch will freeze.

[Marius Vollmer]

Hi,

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. :)


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.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Neil Jerram]

>>>>> "Marius" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    Marius> Hi,
    Marius> I just made the lonely decision to be more rigorous about the "stable"
    Marius> branch_release-1-6 branch.

    Marius>  We need to be much more rigorous about really keeping the stable
    Marius>  branch stable.  From now on, only release critical, uncontroversial
    Marius>  fixes will be allowed.  I intend to be firm on this.  We are not
    Marius>  getting anywhere without restraining us from putting new stuff into
    Marius>  the stable branch.

D'oh!  I just prepared a load of doc fixes and was about to commit
them, when I saw your email.

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> D'oh!  I just prepared a load of doc fixes and was about to commit
> them, when I saw your email.

Unless Marius says otherwise, doc fixes are fine.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> D'oh!  I just prepared a load of doc fixes and was about to commit
> them, when I saw your email.

I'm planning a new release before Tues (probably release Mon).

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   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).

   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.  in the future someone will complain and someone will decide
they need to be changed back.  will you do those changes then, too?

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Neil Jerram]

>>>>> "thi" == Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

    thi> sorry, it sounds like you have some delusions of absolute control here.
    thi> please get well soon (or demonstrate your position by removing my write
    thi> privs so i can unsubscribe from guile development and use in good
    thi> conscience -- TIA).

I think that's rather harsh, thi.  A small amount of focus and control
to get a release out is hardly dictatorship.

The real problem here is that we don't have a shared view of what is
release critical.  We used to, but I think that sense was blown off
course by the volume of bugs that have been reported recently.

        Neil


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Thien-Thi Nguyen]

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 15 Mar 2002 09:24:06 +0000

   I think that's rather harsh, thi.  A small amount of focus and control
   to get a release out is hardly dictatorship.

true, but focus and control were not demonstrated, only intimated.  the
reality is no one here controls anyone but themselves (and obviously in
my case i can't even do that very well ;-).  why make noise otherwise?

wrt focus, this looks promising:

   The real problem here is that we don't have a shared view of what is
   release critical.  We used to, but I think that sense was blown off
   course by the volume of bugs that have been reported recently.

so how do we go about (re-)nailing down this shared view?  more
precisely, what is the path under devel/ where you propose to check in
the release-critical shared view?

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Thien-Thi Nguyen]

   From: Neil Jerram <neil@ossau.uklinux.net>
   Date: 15 Mar 2002 09:24:06 +0000

   The real problem here is that we don't have a shared view of what is
   release critical.  We used to, but I think that sense was blown off
   course by the volume of bugs that have been reported recently.

another problem is prescriptive (as opposed to descriptive) branching --
we created branch_release-1-6 w/o release-related criteria on when to
branch.  this creates an expectation of "stableness" w/o anyone really
being able to define that state, and the expectation is self-fulfilling:
when things are broken it's easy to rationalize leaving them be so as
not to disturb the stableness.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
> 
> > D'oh!  I just prepared a load of doc fixes and was about to commit
> > them, when I saw your email.
> 
> Unless Marius says otherwise, doc fixes are fine.

Yes, they are fine.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    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. ;-)

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 15 Mar 2002 20:54:44 +0100

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

of course everyone can manage (to varying degrees), that's not the
point.  the point is that declarations of power are not as constructive
as recording (somewhere): your policy, your plan, your work-in-progress,
your requests for help or collaboration (if needed), and your general
openness to feedback.  some of these can be informally recorded (like in
mailing list archives), some are more useful when detailed in a special
place that encourages review and update.

this allows people to develop trust in your Way, and consequently You
(the one who Practices).  it is a joy to follow such a leader because
people can also practice along w/ you (if your methods are easy to
adopt), help themselves develop personally as they help you tune it, and
Get Things Done transparently w/o mystery.  (bonus, too: the more power
you spread the more you get.)

when a collaborator, instead, makes declarations of unilateral power
bereft of these groundwork activities, it reminds me exactly of how i
made these kinds of declarations when in a provisional leadership
position (and fucked up big time); i feel miserable remembering what it
was that drove me to do that and doubly miserable deconstructing why
"drove me to do that" is not quite right -- it's always a decision.

this misery is compounded when i think of the people to whom i made
these declarations, who (predictably) lost -- more likely, never built
up -- trust in my leadership abilities, and called into question (very
frequently) my technical abilities, as well.  it was the beginnings of a
royally dysfunctional work relationship, classic stuff (if you believe
those organizational behavior books ;-), and the project suffered from
the extra overhead incurred.

although i'm a pedant, i will now restrain from trying to imply my
experiences have relevance here.  i am open to learning new styles (if
they are effective).

if anyone has read this far, they might be wondering, what is the point
asking for write privs removal?  well, the nature of guile (and any free
software) collaborative effort is that there is really no such thing as
removing write privs to the source (people just snarf the repo and hack
local source).  the question was an attempt to determine your policy and
maturity level, so as to be able to fine-tune my trust model and plan
for your actions.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Marius Vollmer]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

>    From: Marius Vollmer <mvo@zagadka.ping.de>
>    Date: 15 Mar 2002 20:54:44 +0100
> 
>    Please reconsider.  It would be sad to lose your contributions, but I
>    think we could manage.
> 
> of course everyone can manage (to varying degrees), that's not the
> point.  the point is that declarations of power [...]

My motivation was not to demonstrate or gain power but to take more
responsibility.  I should have explained myself better when announcing
the decision.

I can now see that the way I announced my decision to really, finally
and utterly freeze the 1.6 branch pissed off the people who were
actively improving it.  I didn't intent this, of course, and I'm sorry
about that.  For me, it was a technical decision that should clarify
the status of the 1.6 branch and help it to fulfill its intended
purpose.

Maybe we should have discussed it first, but I knew from the way the
1.6 branch has developed that we would need to be really strict about
the freeze if it should have a chance of succeeding.  So I just went
ahead and demonstrated my willingness to be strict by just announcing
that the branch is now frozen, period.

> are not as constructive as recording (somewhere): your policy, your
> plan, your work-in-progress, your requests for help or collaboration
> (if needed), and your general openness to feedback.  some of these
> can be informally recorded (like in mailing list archives), some are
> more useful when detailed in a special place that encourages review
> and update.

Sometimes it helps just to do things instead of talking about them.

> if anyone has read this far, they might be wondering, what is the point
> asking for write privs removal?  well, the nature of guile (and any free
> software) collaborative effort is that there is really no such thing as
> removing write privs to the source (people just snarf the repo and hack
> local source).  the question was an attempt to determine your policy and
> maturity level, so as to be able to fine-tune my trust model and plan
> for your actions.

Thanks for letting me know.  What did you deduce from my response?

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Thien-Thi Nguyen]

   From: Marius Vollmer <mvo@zagadka.ping.de>
   Date: 16 Mar 2002 01:08:15 +0100

   For me, it was a technical decision that should clarify the status of
   the 1.6 branch and help it to fulfill its intended purpose.

it is the inputs to the decision that clarify the decision.

   Maybe we should have discussed it first, but I knew from the way the
   1.6 branch has developed that we would need to be really strict about
   the freeze if it should have a chance of succeeding.  So I just went
   ahead and demonstrated my willingness to be strict by just announcing
   that the branch is now frozen, period.

strictness/rigor/etc is fine if you understand that being strict means
holding yourself to some principle.  if the principle is not expressed
no one even knows you're being strict, and those who may benefit from
the presumably well-chosen principle, benefit by chance only.

   What did you deduce from my response?

that you have less gray hairs than me, and i should go hack emacs for
rms (indentation/filling for variable width fonts -- something i would
never deign to impugn my personal emacs w/, btw), now.

happy hacking,
thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Evan Prodromou]

>>>>> "MV" == Marius Vollmer <mvo@zagadka.ping.de> writes:

    MV>  We need to be much more rigorous about really keeping the
    MV> stable branch stable.  From now on, only release critical,
    MV> uncontroversial fixes will be allowed.  I intend to be firm on
    MV> this.  We are not getting anywhere without restraining us from
    MV> putting new stuff into the stable branch.

    MV> Of course, it is already controversial exactly what is release
    MV> critical.  I'll just be deciding this. :)

So, ummm... I definitely agree that Guile 1.5.x is at a time when it's
really important to hit a release, and that feature enhancements need
to stop.

However, I kind of agree with Thi that there's some process that needs
some work here. I'd recommend that you maybe ask one of the people
who've been concentrating on this release to mark the BUGS file -- or
another file, or a daturbase or whatever -- with a criticality level.
Make sure that all important and reported bugs are in there, and that
all bugs are marked, and that *you* agree with the criticality.

Having a document means that everyone can see what needs to be worked
on, what hasn't been identified yet, etc. People can see the release
coming closer as the list of bugs in the document gets smaller. And,
finally, when the RC bugs in the list are gone, people have some
warm-fuzzy feelings that perhaps they haven't rushed the release out
the door.

SO, to reiterate: delegate bug-tracking duties to release managers,
and use a document to back up the tracking.

~ESP

-- 
Evan Prodromou
evan@glug.org

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Rob Browning]

Evan Prodromou <evan@glug.org> writes:

> However, I kind of agree with Thi that there's some process that needs
> some work here. I'd recommend that you maybe ask one of the people
> who've been concentrating on this release to mark the BUGS file -- or
> another file, or a daturbase or whatever -- with a criticality level.

Ok, as I mentioned before, would anyone be opposed to placing
references to the relevant release critical bugs in the TODO from now
on?  i.e.

  === Before releasing 1.6.0:

  - Resolve Bug#751: make sure the frob whizzes.

etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Evan Prodromou <evan@glug.org> writes:
> 
> > However, I kind of agree with Thi that there's some process that needs
> > some work here. I'd recommend that you maybe ask one of the people
> > who've been concentrating on this release to mark the BUGS file -- or
> > another file, or a daturbase or whatever -- with a criticality level.
> 
> Ok, as I mentioned before, would anyone be opposed to placing
> references to the relevant release critical bugs in the TODO from now
> on?  i.e.
> 
>   === Before releasing 1.6.0:
> 
>   - Resolve Bug#751: make sure the frob whizzes.
> 
> etc.

That sounds good to me.

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Fri, 15 Mar 2002 10:43:29 -0600

   Agreed, and without having some kind of say about what does and
   doesn't go into the stable branch I certainly won't be able to
   effectively manage a release.

   [release management requirements]

do you mind if i add these to workbook/build/stability.text (or
"release-management-requirements.text" or wherever)?  probably a lot of
discussion would be better grounded if we record these items.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Thien-Thi Nguyen]

   From: Evan Prodromou <evan@glug.org>
   Date: Sat, 16 Mar 2002 12:12:05 -0600

   SO, to reiterate: delegate bug-tracking duties to release managers,
   and use a document to back up the tracking.

well this means that Rob and you need to get tight w/ the bugs rendering
(how's that going, btw?), and release criteria need to be added to the
workbook notes.  i'll take a first stab at the latter tonight, gathering
material mostly from these posts.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> do you mind if i add these to workbook/build/stability.text (or
> "release-management-requirements.text" or wherever)?  probably a lot of
> discussion would be better grounded if we record these items.

That's fine with me -- and I think we should revisit this text in the
not too distant future with an eye to how we might better handle
things as we improve our BUGS system.  i.e. perhaps the protocol would
be: submit bug, ask on list about RC status for the bug, update the
bug headers accordingly when a decision has been made, etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Stable branch will freeze.

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> well this means that Rob and you need to get tight w/ the bugs
> rendering (how's that going, btw?), and release criteria need to be
> added to the workbook notes.  i'll take a first stab at the latter
> tonight, gathering material mostly from these posts.

As we integrate the bugs system into some kind of web display, I'd
like to see RC bugs in a separate RC section so it's obvious what's
going on wrt the release.

Eventually we should probably have a page, or section of a page
dedicated to each release that has cross-links to the pending bugs,
important migration issues, etc., but for now, perhaps we should start
small and work our way up :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel