RE: Your stewardship(s)

> Let's be honest here: The "steward" _will_ be the maintainer of some
> package. Even though Daniel (I think it was him) wrote up that nice memo
> that the steward is simply a person with expertise in some area, I believe
> that the formal act of declaring someone to be the steward effectively makes
> that person the maintainer. After all, this person seems to have declared
> himself the manager of some particular area of the system, so who else would
> you go to?
The note I wrote lays out some reasonable expectations about people that
take care of certain packages. The main point of the note, the first
clause is - "The steward is nobodys bitch". It was there because I
observed sometimes a habit for people to think of themselves as
"consumers" that have a "right" to something or other from the
"provider" of some package. This works at various levels, from the
Guides to maintainers of a specific package.

I think the most important thing to remember here is that everyone's
here for fun, and the people that contribute are most used to seeing
this as active fun. So the question is not "can we call them something
formal so we can make various demands of them", but rather, "how can we
make things more comfortable for them, so they'll continue to play in
this sandbox".

Which is an important reason why I wrote that note to clarify
expectations, so Stewards don't need to constantly do so. Which is also
an important reason I didn't make a link between stewardship and
specific people - it should be a role people decide to slip into and out
of, not something to make a fuss about. 

I think what Hannes and co are really trying to do is a. document who
the wise men are, so that someone new has a way to find them. b. give
control to those that earned it.

But control is also a burden, so be gentle about it. Or don't do it at
all, just let it emerge (Do we need to declare Anthony steward of the
compiler? I think that might just screw it up. He's doing wonderful work
without any such prodding).

[Expectations from package maintainers]
I think you present a very specific scenario for the "centralized
maintainer". Someone other than the main maintainer can easily be the
one to run regressions. Yet another can make the first cut about
proposed fixes. The scenario you describe later, of work distributed
among a group, with one "wise old man" sound much healthier to me.

Daniel

Andreas Raab <[email protected]> wrote:
> Hi Hannes,
> 
> [Note: I've cross-posted this message to the SqF list (original message is
> quoted below) since some of the aspects in this message relate to the larger
> picture of stewards. Also, I might be wrong on various accounts and in this
> case a clarification might be helpful]
> 
> > What do you think? 
> 
> I think that before I would agree to any such thing I need to have a _much_
> clearer perspective on what the job of a steward entails. I barely withheld
> a heated reply to the threads involved, since to me, this looks very much
> like forcing people who have not agreed to do so into a position they may
> not want to be in. 
> 
> Let's be honest here: The "steward" _will_ be the maintainer of some
> package. Even though Daniel (I think it was him) wrote up that nice memo
> that the steward is simply a person with expertise in some area, I believe
> that the formal act of declaring someone to be the steward effectively makes
> that person the maintainer. After all, this person seems to have declared
> himself the manager of some particular area of the system, so who else would
> you go to?
> 
> Not that I necessarily mind this, but a key issue is what we expect the
> steward to do in a world of decentralized packages. The way I see it, we'd
> probably want the steward to harvest fixes, goodies, enhancements along the
> way. We probably expect him to run tests if everything works allright in
> version XYZ of Squeak. We probably expect him to update packages regularly.
> All very good things - if you have the time for it. And the short answer is:
> I don't. I simply do not have the time to scan the postings at Squeak-Dev, I
> don't have the time to run regression tests, to test each and every
> individual part. At least not for the stuff you were proposing, and
> definitely not in an age of "montly releases".
> 
> An important aspect in the maintenance debate is that Squeak does not lend
> itself easily to the style of decentralized development we're anticipating.
> Most problematic at this point is that there is no API for any of the
> package that a client can rely on, no dependencies, versions etc. In the
> days of the monolithic image that wasn't as big a problem as you could
> simply browse all the senders of some class/message to see where it's used.
> With SM, we need a more declarative style that tells both, clients and
> framework developers which methods can be relied upon and which can't.
> Without this, maintaining a package simply becomes a nightmare.
> 
> Personally, I simply _use_ all of the packages you were referring to. My
> only interested at this point in maintenance is for the very lowest level of
> Balloon3D in which I would like to stay compatible between what's currently
> in Squeak and what is in Croquet (note: I did the Balloon3D and removal
> packages as a service to the community, not for myself; I don't need them to
> be removed, in fact I need them hardly at all). Other than that, I might
> post a fix, goodie, whatever to any of the other areas but fundamentally I
> am not interested in maintaining this or any further aspect at this point.
> 
> So as far as the maintenance aspect is involved, my answer is "no" at this
> point. I simply cannot imagine spending enough time in any of these areas
> with a decentralized model of development. As far as being the "wise man"
> for some particular area is involved, there is simply no need to declare me
> the formal steward, because it wouldn't change anything - after all, if I
> see some question that I find the time to answer, I'll do this anyways.
> Given that, what would be the point in declaring me the "steward"? You get
> everything that I can handle already, and formally declaring me to be the
> "steward" can only mean that you want to assign new tasks to me, tasks for
> which I cannot guarantee that I can or want to handle them.
> 
> Given the above, can you see any reason whatsoever why I should (or even
> want to) be declared a steward for the areas you are proposing?!
> 
> <off-topic>
> Perhaps as some additional food for thoughts, if I think about the form in
> which I could imagine to be a steward/maintainer for some aspect of Squeak
> it immediately comes to my mind that the first and faremost issue is that of
> enabling _others_ to be able to work on that same package. Since all of us
> have only a limited amount of time I think it is critical that more than one
> person is responsible for a particular package. One way in which I could
> imagine this, is by essentially giving each package its own update stream
> which is used for the developers of some package. In this case, any of the
> developers would be able to post and review changes that are done in this
> area, and "releases" mean only that the incremental updates are merged and
> put out as package at SM.
> 
> Of course, this requires trust in the developers working in a particular
> area, but this could then be the primary task of the Steward - to identify
> developers both interested and capable of working in this area. The
> essential model would be that the community (represented by the guides)
> hands their trust into the Steward and the Steward hands this trust to the
> group of developers involved. Whether the Steward herself hacks along with
> the developers is quite a different matter; she would simply be the person
> ultimately responsible for some package. So that feature requests, bug
> fixes, blames would rightfully go to the Steward and from there be relayed
> to the developers involved. Conceptually, SourceForge is not a bad model for
> this - it allows registered developers to participate in projects for which
> they need blessing by one of the admins of that project. In Squeak terms,
> the initial admin for one of these projects (packages) would be the steward
> and from there, more people could join in.
> </off-topic>
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----
> > From: Hannes Hirzel [mailto:[email protected]] 
> > Sent: Saturday, March 08, 2003 5:02 PM
> > To: Andreas Raab
> > Cc: Doug Clapp; Brent Vukmer
> > Subject: Your stewardship(s)
> > 
> > 
> > 
> > Dear Andreas
> > 
> > May I draw your attention to the page 
> >   Stewards for Packages
> >   http://minnow.cc.gatech.edu/squeak/3088
> > 
> > Is it OK that we put you on the list as the
> > steward for Balloon and Balloon3D. I think
> > that no discussion on the list is needed 
> > because as the original author of this you 
> > actually *are* the steward as well
> > unless you want to change that.
> > The same might apply for other "Squeak estates",
> > FFI for example.
> > 
> > What do you think? 
> > 
> > Regards
> > Hannes
> > 
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
From [email protected] Sun Mar 09 06:07:35 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 13469 invoked from network); 9 Mar 2003 06:07:35 -0000
Received: from mxout2.netvision.net.il (194.90.9.21)
  by mail.theinternetone.net with SMTP; 9 Mar 2003 06:07:35 -0000
Received: from [80.178.100.74] ([80.178.100.74]) by mxout2.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with SMTPA id <[email protected]> for
 [email protected]; Sun,
 09 Mar 2003 08:07:35 +0200 (IST)
Date: Sun, 09 Mar 2003 08:02:51 +0300
From: Daniel Vainsencher <[email protected]>
Subject: Re: [Squeakfoundation]3.5 release timing (was Re: Outstanding 3.4
 bugs?)
To: Discussing the Squeak Foundation
 <[email protected]>
Message-id: <[email protected]>
X-Mailer: Celeste 2.0.5108
Content-transfer-encoding: 7BIT
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2003 06:07:37 -0000

The reason I see Accufonts as a step forward is that Apple is currently
the only player we're concerned about. Doug Easterbrook isn't. He's easy
to please and doesn't have a legal interest in Squeak. Since is
simplifies things for Apple, Accufonts is an improvement. 

Long term, I agree with you.

Daniel

Cees de Groot <[email protected]> wrote:
> 
> --Boundary_(ID_l363gpxol2YRQ4TbPQ5Egg)
> Content-type: multipart/signed; boundary="=-N3o9iVnCCoxuLNAOBGSN";
>  protocol="application/pgp-signature"; micalg=pgp-sha1
> 
> 
> --=-N3o9iVnCCoxuLNAOBGSN
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
> 
> On Sat, 2003-03-08 at 08:08, Daniel Vainsencher wrote:
> > I agree with everything you said. About Accufonts, I think it depends on
> > what Cees/Andrew can tell us about any discussions with Apple.=20
> I haven't heard anything back yet.=20
> 
> Just to make it abundantly clear: Accufonts replacements would be a
> token gesture to Apple, it wouldn't do anything to make Squeak more free
> because the Accufonts license has exactly the same problem as the Apple
> fonts license.
> 
> > I would really love to know that Andrew and Cees are talking, and we're
> > getting Andrew's best (non-official) advice about how to go about this.
> >=20
> I've given up mailing to Andrew (and Dan) on SqF/Licensing issues last
> summer, after never getting responses from either one on repeated
> requests. So I'm at the moment 'singlehandedly' tackling discussions
> with Apple.
> 
> 
> --=-N3o9iVnCCoxuLNAOBGSN
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> 
> iD8DBQA+aftT8wOTf+CYnosRAkAvAJ9zAEk9imHaz09MWPRdCu3Qww0YsQCgqKqq
> bCwwDWOtz2bvk3F7jcBkGAQ=
> =Vxia
> -----END PGP SIGNATURE-----
> 
> --=-N3o9iVnCCoxuLNAOBGSN--
> 
> 
> --Boundary_(ID_l363gpxol2YRQ4TbPQ5Egg)
> MIME-version: 1.0
> Content-type: text/plain; charset=us-ascii
> Content-transfer-encoding: 7BIT
> 
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
> 
> --Boundary_(ID_l363gpxol2YRQ4TbPQ5Egg)--
From [email protected] Sun Mar 09 18:43:49 2003
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: (qmail 5126 invoked from network); 9 Mar 2003 18:43:49 -0000
Received: from mail.gmx.net (213.165.65.60)
  by mail.theinternetone.net with SMTP; 9 Mar 2003 18:43:49 -0000
Received: (qmail 23069 invoked by uid 0); 9 Mar 2003 18:43:47 -0000
Received: from p508831C5.dip.t-dialin.net (HELO atlantis) (80.136.49.197)
  by mail.gmx.net (mp003-rz3) with SMTP; 9 Mar 2003 18:43:47 -0000
From: "Andreas Raab" <[email protected]>
To: "'Discussing the Squeak Foundation'"
	<[email protected]>
Subject: RE: [Squeakfoundation]RE: Your stewardship(s)
Date: Sun, 9 Mar 2003 19:43:24 +0100
Message-ID: <004001c2e66b$c4ad8330$8ef7fea9@atlantis>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[email protected]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
cc: 'Hannes Hirzel' <[email protected]>
X-BeenThere: [email protected]
X-Mailman-Version: 2.1
Precedence: list
Reply-To: Discussing the Squeak Foundation
	<[email protected]>
List-Id: Discussing the Squeak Foundation
 <squeakfoundation.lists.squeakfoundation.org>
List-Unsubscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lnx-12.ams-2.theinternetone.net/pipermail/squeakfoundation>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.squeakfoundation.org/listinfo/squeakfoundation>,
	<mailto:[email protected]?subject=subscribe>
X-List-Received-Date: Sun, 09 Mar 2003 18:43:50 -0000

Hi Daniel,

> [Expectations from package maintainers]
> I think you present a very specific scenario for the "centralized
> maintainer". 

You are right. This is why I said I would need a much clearer understanding
about it before I would be willing to join in. I have tried to look at it
from both sides - namely from the side of what someone might naively expect
from a steward and from the side in which I would feel comfortable with
those expectations. As you surely noticed the latter half of my message did
not take back anything from the expectactions but rather described an
environment in which people with limited resources might be able to handle
those.

> I think the most important thing to remember here is that everyone's
> here for fun, and the people that contribute are most used to seeing
> this as active fun. So the question is not "can we call them something
> formal so we can make various demands of them", but rather, 
> "how can we make things more comfortable for them, so they'll continue
> to play in this sandbox".

Thanks. In this case I won't be any steward for a foreseeable time - after
all I feel much more comfortable without any such name tag.

Cheers,
  - Andreas

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] 
> On Behalf Of Daniel Vainsencher
> Sent: Sunday, March 09, 2003 5:33 AM
> To: Discussing the Squeak Foundation
> Subject: [Squeakfoundation]RE: Your stewardship(s)
> 
> 
> > Let's be honest here: The "steward" _will_ be the maintainer of some
> > package. Even though Daniel (I think it was him) wrote up 
> that nice memo
> > that the steward is simply a person with expertise in some 
> area, I believe
> > that the formal act of declaring someone to be the steward 
> effectively makes
> > that person the maintainer. After all, this person seems to 
> have declared
> > himself the manager of some particular area of the system, 
> so who else would
> > you go to?
> The note I wrote lays out some reasonable expectations about 
> people that
> take care of certain packages. The main point of the note, the first
> clause is - "The steward is nobodys bitch". It was there because I
> observed sometimes a habit for people to think of themselves as
> "consumers" that have a "right" to something or other from the
> "provider" of some package. This works at various levels, from the
> Guides to maintainers of a specific package.
> 
> I think the most important thing to remember here is that everyone's
> here for fun, and the people that contribute are most used to seeing
> this as active fun. So the question is not "can we call them something
> formal so we can make various demands of them", but rather, 
> "how can we
> make things more comfortable for them, so they'll continue to play in
> this sandbox".
> 
> Which is an important reason why I wrote that note to clarify
> expectations, so Stewards don't need to constantly do so. 
> Which is also
> an important reason I didn't make a link between stewardship and
> specific people - it should be a role people decide to slip 
> into and out
> of, not something to make a fuss about. 
> 
> I think what Hannes and co are really trying to do is a. document who
> the wise men are, so that someone new has a way to find them. b. give
> control to those that earned it.
> 
> But control is also a burden, so be gentle about it. Or don't do it at
> all, just let it emerge (Do we need to declare Anthony steward of the
> compiler? I think that might just screw it up. He's doing 
> wonderful work
> without any such prodding).
> 
> [Expectations from package maintainers]
> I think you present a very specific scenario for the "centralized
> maintainer". Someone other than the main maintainer can easily be the
> one to run regressions. Yet another can make the first cut about
> proposed fixes. The scenario you describe later, of work distributed
> among a group, with one "wise old man" sound much healthier to me.
> 
> Daniel
> 
> Andreas Raab <[email protected]> wrote:
> > Hi Hannes,
> > 
> > [Note: I've cross-posted this message to the SqF list 
> (original message is
> > quoted below) since some of the aspects in this message 
> relate to the larger
> > picture of stewards. Also, I might be wrong on various 
> accounts and in this
> > case a clarification might be helpful]
> > 
> > > What do you think? 
> > 
> > I think that before I would agree to any such thing I need 
> to have a _much_
> > clearer perspective on what the job of a steward entails. I 
> barely withheld
> > a heated reply to the threads involved, since to me, this 
> looks very much
> > like forcing people who have not agreed to do so into a 
> position they may
> > not want to be in. 
> > 
> > Let's be honest here: The "steward" _will_ be the maintainer of some
> > package. Even though Daniel (I think it was him) wrote up 
> that nice memo
> > that the steward is simply a person with expertise in some 
> area, I believe
> > that the formal act of declaring someone to be the steward 
> effectively makes
> > that person the maintainer. After all, this person seems to 
> have declared
> > himself the manager of some particular area of the system, 
> so who else would
> > you go to?
> > 
> > Not that I necessarily mind this, but a key issue is what 
> we expect the
> > steward to do in a world of decentralized packages. The way 
> I see it, we'd
> > probably want the steward to harvest fixes, goodies, 
> enhancements along the
> > way. We probably expect him to run tests if everything 
> works allright in
> > version XYZ of Squeak. We probably expect him to update 
> packages regularly.
> > All very good things - if you have the time for it. And the 
> short answer is:
> > I don't. I simply do not have the time to scan the postings 
> at Squeak-Dev, I
> > don't have the time to run regression tests, to test each and every
> > individual part. At least not for the stuff you were proposing, and
> > definitely not in an age of "montly releases".
> > 
> > An important aspect in the maintenance debate is that 
> Squeak does not lend
> > itself easily to the style of decentralized development 
> we're anticipating.
> > Most problematic at this point is that there is no API for 
> any of the
> > package that a client can rely on, no dependencies, 
> versions etc. In the
> > days of the monolithic image that wasn't as big a problem 
> as you could
> > simply browse all the senders of some class/message to see 
> where it's used.
> > With SM, we need a more declarative style that tells both, 
> clients and
> > framework developers which methods can be relied upon and 
> which can't.
> > Without this, maintaining a package simply becomes a nightmare.
> > 
> > Personally, I simply _use_ all of the packages you were 
> referring to. My
> > only interested at this point in maintenance is for the 
> very lowest level of
> > Balloon3D in which I would like to stay compatible between 
> what's currently
> > in Squeak and what is in Croquet (note: I did the Balloon3D 
> and removal
> > packages as a service to the community, not for myself; I 
> don't need them to
> > be removed, in fact I need them hardly at all). Other than 
> that, I might
> > post a fix, goodie, whatever to any of the other areas but 
> fundamentally I
> > am not interested in maintaining this or any further aspect 
> at this point.
> > 
> > So as far as the maintenance aspect is involved, my answer 
> is "no" at this
> > point. I simply cannot imagine spending enough time in any 
> of these areas
> > with a decentralized model of development. As far as being 
> the "wise man"
> > for some particular area is involved, there is simply no 
> need to declare me
> > the formal steward, because it wouldn't change anything - 
> after all, if I
> > see some question that I find the time to answer, I'll do 
> this anyways.
> > Given that, what would be the point in declaring me the 
> "steward"? You get
> > everything that I can handle already, and formally 
> declaring me to be the
> > "steward" can only mean that you want to assign new tasks 
> to me, tasks for
> > which I cannot guarantee that I can or want to handle them.
> > 
> > Given the above, can you see any reason whatsoever why I 
> should (or even
> > want to) be declared a steward for the areas you are proposing?!
> > 
> > <off-topic>
> > Perhaps as some additional food for thoughts, if I think 
> about the form in
> > which I could imagine to be a steward/maintainer for some 
> aspect of Squeak
> > it immediately comes to my mind that the first and faremost 
> issue is that of
> > enabling _others_ to be able to work on that same package. 
> Since all of us
> > have only a limited amount of time I think it is critical 
> that more than one
> > person is responsible for a particular package. One way in 
> which I could
> > imagine this, is by essentially giving each package its own 
> update stream
> > which is used for the developers of some package. In this 
> case, any of the
> > developers would be able to post and review changes that 
> are done in this
> > area, and "releases" mean only that the incremental updates 
> are merged and
> > put out as package at SM.
> > 
> > Of course, this requires trust in the developers working in 
> a particular
> > area, but this could then be the primary task of the 
> Steward - to identify
> > developers both interested and capable of working in this area. The
> > essential model would be that the community (represented by 
> the guides)
> > hands their trust into the Steward and the Steward hands 
> this trust to the
> > group of developers involved. Whether the Steward herself 
> hacks along with
> > the developers is quite a different matter; she would 
> simply be the person
> > ultimately responsible for some package. So that feature 
> requests, bug
> > fixes, blames would rightfully go to the Steward and from 
> there be relayed
> > to the developers involved. Conceptually, SourceForge is 
> not a bad model for
> > this - it allows registered developers to participate in 
> projects for which
> > they need blessing by one of the admins of that project. In 
> Squeak terms,
> > the initial admin for one of these projects (packages) 
> would be the steward
> > and from there, more people could join in.
> > </off-topic>
> > 
> > Cheers,
> >   - Andreas
> > 
> > > -----Original Message-----
> > > From: Hannes Hirzel [mailto:[email protected]] 
> > > Sent: Saturday, March 08, 2003 5:02 PM
> > > To: Andreas Raab
> > > Cc: Doug Clapp; Brent Vukmer
> > > Subject: Your stewardship(s)
> > > 
> > > 
> > > 
> > > Dear Andreas
> > > 
> > > May I draw your attention to the page 
> > >   Stewards for Packages
> > >   http://minnow.cc.gatech.edu/squeak/3088
> > > 
> > > Is it OK that we put you on the list as the
> > > steward for Balloon and Balloon3D. I think
> > > that no discussion on the list is needed 
> > > because as the original author of this you 
> > > actually *are* the steward as well
> > > unless you want to change that.
> > > The same might apply for other "Squeak estates",
> > > FFI for example.
> > > 
> > > What do you think? 
> > > 
> > > Regards
> > > Hannes
> > > 
> > 
> > _______________________________________________
> > Squeakfoundation mailing list
> > [email protected]
> > http://lists.squeakfoundation.org/listinfo/squeakfoundation
> _______________________________________________
> Squeakfoundation mailing list
> [email protected]
> http://lists.squeakfoundation.org/listinfo/squeakfoundation
>