3dot11?

Hi all,

It is now July.

While 3dot10 has not yet wrapped it is definitely in
beta. So it is time to ask where and how is the 3dot11
team being assembled?

Yours in curiosity and service, --Jerome Peace


       
____________________________________________________________________________________
Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 

2007/7/2, Jerome Peace <[hidden email]>:
> While 3dot10 has not yet wrapped it is definitely in
> beta. So it is time to ask where and how is the 3dot11
> team being assembled?

What about a 100% free access to the official repository? Everyone
would be able to commit directly using monticello on the
squeakfoundation repository. This would help small commits like
comments one, small refactorings... Using monticello, people would be
able to see what other commited and correct things.

--
Damien Cassou

Damien Cassou wrote:

> What about a 100% free access to the official repository? Everyone

Oh, you mean software development by anarchy?

Great idea...

Michael

2007/7/2, Michael Rueger <[hidden email]>:
> Damien Cassou wrote:
>
> > What about a 100% free access to the official repository? Everyone
>
> Oh, you mean software development by anarchy?
>
> Great idea...

Yeah, works pretty well for Seaside. A Squeak package several people
make a living of.

Philippe

Il giorno lun, 02/07/2007 alle 19.19 +0200, Philippe Marschall ha
scritto:
As Philippe is saying, the idea isn't as bad as it may sound.

Obviously this doens't mean that anyone can create "official" updates
and releases - only someone from the release team would be allowed to do
that.
Many open source projects allow people to commit to the repository, but
the official packages get created by the project manager/owner.

We could also agree to a compromise and allow access to the repos to a
larger group of developers, without moving to 100% free access.

Having a more open approach could streamline the bug fixing/harvesting
process: instead of attaching a patch file to a mantis bug, reporters
and developers could just point to a package in the repository.

        Giovanni

Il giorno dom, 01/07/2007 alle 19.46 -0700, Jerome Peace ha scritto:
> Hi all,
>
> It is now July.
>
> While 3dot10 has not yet wrapped it is definitely in
> beta. So it is time to ask where and how is the 3dot11
> team being assembled?

I'd like to propose that instead of having another team replace the
current one, we just add a two or thre more people to the current team
(if Ralph and Edgar agree to stay on, of course).

This would have some advantages:
1) managing the image with Monticello is difficult at best. Having a new
release team for every version means that the team always has to relearn
the same tricks before it can start working proficiently on the new
release.
2) having a larger team would allow specialization in the release team.
One release team member could specialize in, say, devel tools, while
another one could specialize on file and network, etc.
3) having the release team serve for more than a single release
iteration would allow planning on a longer timespan and creating a
proper roadmap.

In light of point 3, I'd also like to suggest that when we start
planning for 3.11, we also start thinking about the release after 3.11
(3.12? 4.0?). As an example, the plan for 3.11 would include stuff that
it's likely we could add to the stable image in a single release
timeframe, while all the other stuff would be punted to 3.12 .

        Ciao,

                Giovanni

On Mon, 2007-07-02 at 19:19 +0200, Philippe Marschall wrote: Sorry, phillipe, I don't agree. I like the open source way of doing
things (I'm doing it for over 10 years now) but there are problems.
Taking seaside as an example is not a good comparsion. There are
3 to 4 developers in average which contribute to the repository with
one unofficial leader which is Lukas. That is more the way a project
is organized from the top. As long as very few people are contributing
and one which is reviewing the changes and integrates them into the
trunk everything is fine. Furthermore the seaside developers are more
open to change seaside the way they like.
I think you need just a few more developers changing code slightly
more often that code reviewing and integration is rendered impossible.
This leads very quick to a situation where code reviewing is fulltime
job and I doubt anyone is willing to take it. If there is nobody which
does this work it leads to a situation where each developer is his
own branch including from others only what he needs/likes.

And we have a lot of squeak branches right now.

Just my 2 cents,

Norbert

2007/7/3, Norbert Hartl <[hidden email]>:
On which part? That it can work? That it works well for Seaside? That
it would work well for Squeak? That it is one size fits all? I only
claimed the second.

> I like the open source way of doing
> things (I'm doing it for over 10 years now) but there are problems.
> Taking seaside as an example is not a good comparsion. There are
> 3 to 4 developers in average which contribute to the repository with
> one unofficial leader which is Lukas. That is more the way a project
> is organized from the top. As long as very few people are contributing
> and one which is reviewing the changes and integrates them into the
> trunk everything is fine. Furthermore the seaside developers are more
> open to change seaside the way they like.

Well very few people are actually expressing concrete ways in which
they would have Seaside changed. There are some general "grand ideas"
but almost nothing concrete.

> I think you need just a few more developers changing code slightly
> more often that code reviewing and integration is rendered impossible.

I question that. I don't see how a more heavyweight and formal process
would do anything to reduce the amount of work that a reviewer had to
do. Quite the opposite.

If the work is too big then that simply means that a lot of
development would happen. This is not the case for any of the Squeak
Image packages.

> This leads very quick to a situation where code reviewing is fulltime
> job and I doubt anyone is willing to take it. If there is nobody which
> does this work it leads to a situation where each developer is his
> own branch including from others only what he needs/likes.

If you are referring to Monticello there the situation is that the
"maintainer"  does no work at all. The amount of changes would very
well be reviewable in an afternoon. Especially if it was done a year
ago. But there is simply no one in charge.

> And we have a lot of squeak branches right now.

That's because nobody is in charge who cares. Not because of the sheer
amount of changes is too big.

Just that nobody gets this wrong. I am not accusing anybody, I am not
saying anything should/must change. It's everyones good right to do
his own private fork of Squeak and everyone is free to do whatever the
wants with his time.

Cheers
Philippe

> Just my 2 cents,
>
> Norbert
>
>
>

On 3 juil. 07, at 12:18, Giovanni Corriga wrote:


from my experience of been overwelm with information or with no  
information
having a mantis entry per package would help.
Having a centralized database is important.

Stef

>
> Giovanni
>
>
>

I should say that it made me think a lot when ralph was talking about  
social engineering to bring
people to help and I see ***no*** communication about the fixes been  
introduced in 3.10.
I think that there is a total lack of communication and if damien  
would not build regularly
an image we would have no clue that there are progress.

I proposed to ralph to participate and pair with him on 3.10
We passed all the information we had to ralph (and he released that we
have implemented in 3.9 the process he had in mind).
I guess that pavel wanted to help too but there were miscommunication.
I will not talk for him but real progress should be made on that side.

> 2) having a larger team would allow specialization in the release  
> team.
> One release team member could specialize in, say, devel tools, while
> another one could specialize on file and network, etc.

Indeed

> 3) having the release team serve for more than a single release
> iteration would allow planning on a longer timespan and creating a
> proper roadmap.

Indeed why 3.11 and why not 4.0

>>
> Sorry, phillipe, I don't agree. I like the open source way of doing
> things (I'm doing it for over 10 years now) but there are problems.
> Taking seaside as an example is not a good comparsion. There are
> 3 to 4 developers in average which contribute to the repository with
> one unofficial leader which is Lukas.

Basically you have a small domain and four excellent guys. So this is  
counting too. :)

> That is more the way a project
> is organized from the top. As long as very few people are contributing
> and one which is reviewing the changes and integrates them into the
> trunk everything is fine. Furthermore the seaside developers are more
> open to change seaside the way they like.
> I think you need just a few more developers changing code slightly
> more often that code reviewing and integration is rendered impossible.
> This leads very quick to a situation where code reviewing is fulltime
> job and I doubt anyone is willing to take it.

yeap

Giovanni Corriga wrote:
And the nice thing is, is that it doesn't have to be an either/or
proposition. A "chaotic" repository can be opened up and access granted
as desired by the repository creator/owner. Possibly using some of the
squeak people rankings. Apprentice is able to submit code/fixes,
journeyer and up commit code/fixes. An apprentice's code/fix would need
to be approved by those with commit privileges.

Possibly as Giovanni suggests with certain committers having a type of
stewardship over an area of the code base.

If such works, great. If not, what is the harm in trying. In the end it
would seem those who prefer the current or a previous process are still
at liberty to pursue said process, concurrently with the chaotic
process. They can be done in parallel.

Worst case, we try, we fail.
We've done that before, survived, kept going.
But we could learn that we can manage the process like that, and
prosper. It doesn't have to be a perfect process, just one that is
better than the current one. We won't know until we try. We can tweak
and massage the process and improve it as we go. Let's be agile. ;)

It has been mentioned that Seaside isn't a good example because the
community is small and the number of committers to the codebase is
small. The active, participating, code committing users of the Squeak
community is also not large and should be reasonably manageable. This
mailing list is open, yet only a small fraction of those who subscribe
actually participate. Look who participates in the voting process. Those
involved in this process are people who are relatively known to each other.

I believe there are people who are qualified anxiously awaiting genuine
opportunity to contribute, but may not have found their place or
opportunity. You never know, I might find a typo, submit a fix, and find
me a place of immortality. ;)

Any way, it doesn't have to replace the 3.10 process. It can be done in
parallel if desired. We could learn something about the process and
about the community. Nice thing is, it doesn't really require anybody's
permission either. A community member can step up. Set up the
repository. Set up the submit/commit structure as desired. It can be
community sponsored and organically grown. If successful, it could then
become the official and default method of Squeak development.

'nuff rambling. Just wanted to toss that out there.

I like Squeak. I would love to see Squeak fulfill its potential in every
direction that somebody wants to take it. I might be active in working
on the web side of things, but I might be a user of the multimedia side
of things. Others quite the reverse. Let's encourage Squeak to be all it
can be. But its up to us to take it there.

I know, just when I said 'nuff rambling. ;)

Jimmie

> > And we have a lot of squeak branches right now.
>
> That's because nobody is in charge who cares.

     I care.


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

2007/7/3, Craig Latta <[hidden email]>:
>
> > > And we have a lot of squeak branches right now.
> >
> > That's because nobody is in charge who cares.
>
>      I care.

So what about this bug:
http://bugs.squeak.org/view.php?id=5222

> > > > And we have a lot of squeak branches right now.
> > >
> > > That's because nobody is in charge who cares.
> >
> > I care.
>
> So what about this bug:
> http://bugs.squeak.org/view.php?id=5222

     Hmm, so the idea is that unless I personally fix any and all bugs
anyone cares to mention, I don't really care? ;)


-C

--
Craig Latta
improvisational musical informaticist
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]

2007/7/4, Craig Latta <[hidden email]>:
http://www.squeak.org/Community/Teams/
Says you are responsible or do I misinterpret that?

The bug, like many other actually has a fix included. All it would
take from a responsible person is to have a look at it and either take
it in or reject it. Not just simply ignore it.

Philippe

On Wed, 2007-07-04 at 19:09 +0200, Philippe Marschall wrote: Yes, I think you misinterpret.  I assume you are referring to the fact
that Craig appears in the Coordinator column of the Morphic Stewards
entry in this list.  Coordinators are merely go-betweens between the
team and the SqF Board.  A coordinator is only assigned so the team
knows how to communicate with the Board if such a need ever comes up.

Ken

On 4-Jul-07, at 10:09 AM, Philippe Marschall wrote:


>
> http://www.squeak.org/Community/Teams/
> Says you are responsible or do I misinterpret that?
Yup, you do. That list shows Craig as the coordinator of several  
teams - which means he is the interface between the board and the  
team, not that he is responsible for doing the work.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
The world will end in 5 minutes.  Please log out.

2007/7/4, tim Rowledge <[hidden email]>:
Then please excuse me, in this case he is clearly not resposible for
reviewing and fixing bugs. I recognize that Craig has done a lot of
important work in the board especially regarding the SFLC and SFC.

Philippe.

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> The world will end in 5 minutes.  Please log out.
>
>
>
>

El 7/4/07 2:09 PM, "Philippe Marschall" <[hidden email]>
escribió:

> The bug, like many other actually has a fix included. All it would
> take from a responsible person is to have a look at it and either take
> it in or reject it. Not just simply ignore it.
>
> Philippe


Blaming Craig don't help.
He do Spoon and many people here feel in the long time Squeak become Squeak.

Now you should blame me, as part of release team harvesting Mantis.

But before you complain, should read

http://wiki.squeak.org/squeak/5919 The 3.10 release
http://wiki.squeak.org/squeak/5975 History of the 3.10 release
http://wiki.squeak.org/squeak/5934 List of Mantis issues ready to be
included in 3.10

The 3.10 should do not have any red test (7121 don't have) no failures (have
some , but are know and we are working on).
Off course, Fix or ENH any targeted to 3.10 should have test.
5222 don't have test, so should be automatic rejected.

The reporter is renggli. As I have deep respect for he, I try the bug and if
I could reproduce the bug and the fix, maybe you are lucky and I put into
updates.


Edgar