[squeak-dev] Waiting for 3.11 artifacts.

> *Please* do realize the value of alpha images as a form of
> communication in this community. If you post a fix for the .gz loading
> I will happily produce an alpha image for people to play with.
I do realize the value of alpha images thats what Bob the builder is
for, building images automatically and constantly building and testing
them. The plan is to have many more alphas than we have ever had before.

e.g. We can have an alpha minimal image, and an alpha full image in
which every possible package can be loaded and tested.

What I don't want to do is to be continually producing these alphas,
when if I finish Bob, he could do it for me.

regards

Keith

More on deliverables in a second.

Keith Hodges wrote:
This is one of the things that is wrong with this community: Everything
always needs to be done by new tools that nobody has written yet ;-)

In case you didn't notice - *I* offered to play the role of Bob the
builder for a while without you having to do anything. This kind of work
can easily be spread out without having to have dependencies on
unwritten tools. I'm sure there are other people who would help out once
we get the process going.

Cheers,
   - Andreas

Andreas Raab wrote: I think the opposite, people are so busy doing stuff, that they never
take the time to reflect and invest time in the tools that would make it
easier.

> In case you didn't notice - *I* offered to play the role of Bob the
> builder for a while without you
thanks for the offer,
> having to do anything. This kind of work can easily be spread out
> without having to have dependencies on unwritten tools. I'm sure there
> are other people who would help out once we get the process going.
I still have a couple of steps to go before I am really ready to publish
anything. For example I added waypoints today, so that if a build fails
you can rerun it. Steps that reached their waypoint
do not run again.

When I release 3.11bc this week sometime, I will have completed all the
steps needed to make an end to end release to release. I just have a few
fixes to workspace and then I am done.

Keith

Hi!

David T. Lewis wrote:
Right, let me clarify then - it worked while it worked. But it was not
sustainable. Very few joined the harvesting team and the few that kept
on working with it eventually got very tired.

So, sure it "worked" - for a while.

Observation:

Most of our progress is made as "side effects" from a specific project.
Be it SimpleLog from Gjallar or improvements in MC because people just
need it to work etc etc. But doing harvesting is not such a side effect
- it is a rather complex task with no other direct benefit than your
personal satisfaction. Well, not 100% true perhaps but you get the picture.

It is easy to make a small fix to say SMTPClient and smack that up on
Mantis - while working on Gjallar - but it is a totally different story
sucking up that fix, reviewing and pushing it into the image. The latter
is not something someone do as a "side effect" of other "real work".

regards, Göran

Hi Andreas!

Andreas Raab wrote:
Right, we do the same for a few packages - those that we needed to make
changes to, and that were available in MC form more or less.

> In Gjallar, how do you deal with the same set of problems (making a
> modification for the product, integrating some external modification)
> using Installer? In particular how do you deal with issues like having
> to rely on external servers (which might be on the other end of the
> world, down and out etc), the ability to make some changes quickly for
> the product to ship etc.

Right, we use a "mixed approach". We build new images - but not *that*
often. So while we do depend on a few external servers, a build mostly
goes through fine. But you wouldn't want to do that every day.

So we build a new image when we feel a need for it - or when we are
about to make a new release. Then we all jump to the new image and carry on.

> I have never found a production setup which did not require to
> ultimately have your own copies of the code on your own servers in which
> case you're quickly getting to the point that a single homogeneous
> environment is advantageous (like using MC+configs, or using an update
> stream) and where a mix of these ultimately only gets you into trouble.

We do have a mix, but most of the 3rd-party packages/fixes we load when
we build a new image are not packages that we hack on generally. 98% of
the day to day Gjallar coding is in the Gjallar MCs.

> The reason why I like DeltaStreams is that it sounds like an approach
> that allows one to reconcile the (necessary) local mods with other
> changes more easily than could be done by MC or updates.

Right, and I sure hope to get back to that project. Matthew did lots of
work on it, and it is almost there - but I still want to make a "dual
changesorter ripoff" UI for them and make sure they can work as full cs
replacements. Matthew made a UI with a distinctly different view - and
while useful I think personally it took a detour from what I want to end
up with.

 > But I don't
> think Installer is quite that and so I'm not sure how it helps in the
> process. An experience report would be most welcome.

Well, IMHO it helps in building images where you need to pluck stuff
from a lot of different directions and formats. It can suck up "the
latest Seaside MC made by Renggli on SS", the fix for bug 5689 on
Mantis, the package X from SM, etc etc. It is not limited to MC.

It is not rocket science - you could do almost the same with SM - but
that was limited to stuff only on SM (no SS, no Mantis etc) and it was
not as "scripting friendly" in its API. Installer is made to be mainly
"oneliners".

Also - LPF is a good effort. I just know that I use it and I hopefully
get a working MC. :)

> The other question here is that I don't understand how Installer has
> helped you moving between versions. Having moved Croquet from 3.2 to 3.4
> to 3.6 to 3.8 I have found each version a completely unique challenge
> and I cannot imagine that any particular tool would have helped me
> getting this work done more efficiently than the (extremely painful)
> process of loading, having it break, figure out where exactly that
> interface went, rinse and repeat. Anything that could help with this
> process would be hugely beneficial.

I am sorry if I made it sound like Installer helps with *that* problem.
Sure, all API changes in base packages, 3rd-party packages etc etc needs
to be dealt with one by one - no freebie there.

Possibly it helped by making it easy to throw away borked images and
"start over from fresh" to make sure I wasn't hunting ghosts from
previous mess-ups.

Deltas might on the other hand one day make this work slightly more
enjoyable :)

> Cheers,
>   - Andreas

Cheers, Göran

Andreas Raab wrote:
> 3.11 has lost *all* visibility to me. I didn't know whether it had even
> started because there was nothing on the server, there were no
> announcements on this list, so how would people know?

IMHO this has more to do with our current board and its lack of...
communication. Sure, I just skimmed meeting notes posted and AFAICT
there was a motion back in july:

"Motion: Spoon will be basis of a R4 and 3.x will continue as planned in
3.11 proposal as long as people want to maintain it. (Passed unanimously) "

...but I can't say that the community is very AWARE of this and what it
means. So either the team is to "blame" for not speaking up or the board
is to blame for not showing the official support. I guess it is a combo.

Let me also YET AGAIN point to the team table on squeak.org:

        http://www.squeak.org/Community/Teams/

If things were operating functionally there would be a release team
listed with Matthew Fulmer (or is it Keith? Please correct me because I
can't seem to find that info) as team leader. Can't see it.

I do see lots of other teams still listed that are DEAD. I mean, 3.9
with Stephane as team leader? Silly. There are also coordinators listed
that are not even on the board!

It seems I have pointed this out a THOUSAND times and nothing is
happening. If the board totally ignores this table then for god sake -
delete it.

regards, Göran

2008/12/10 Edgar J. De Cleene <[hidden email]>:
>
> On 10/12/2008, at 08:19, Göran Krampe wrote:
>
> It seems I have pointed this out a THOUSAND times and nothing is happening.
> If the board totally ignores this table then for god sake - delete it.
>
thanks for mentioning. We should check teams and update it accordingly.

> regards, Göran
>
> Now I awake all, and most hate me and trow me stones, wish all  say
> something before next Board election.
> Things I don't liike and say before.
> 1) The undemocratic procedure.
> Why any person on this list don't have the same rights as Masters ?

it depends, on what you putting under 'rights'.

> 2) The "rank" don't should be "eternal"
> No sports have same champions forever. !!

it is completely based on free will. If you want to become a Master
and take responsibility, and community supported you - here you go.

> So we should take two last years of community work for qualify who is
> "Master" and who is "Master2000" or whatever
> 3) What the community really wish of Board ?
>

Some time ago i proposed to put a formal declaration "what is
board/leadership" on squeak.org. Any good english writers?
I'm sure, it cant be me or you, Edgar, because our English is a bit
far from being good :)

> Edgar
>

--
Best regards,
Igor Stasenko AKA sig.

Göran Krampe wrote:

>>> Many of us who have been around for a while know that we have tried
>>> numerous approaches over the years and we know that many of these
>>> have failed due to various reasons. For example, the idea of
>>> "harvesting" and having so called "harvesters" failed because it only
>>> led to a few people burning out (in the very early years it "worked"
>>> because we had paid people doing the harvesting).

I looks that harvesting as a hard work without much reward obviously
worked until was paid. So, what if we reintroduce paid harvesters again?

Also, how was they paid, which were the rules, what was the experience,
problems, why this approach was discontinued?

Best regards
Janko


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

     
[squeak-dev] Waiting for 3.11 artifacts.


>Keith Hodges keith_hodges at yahoo.co.uk
>Tue Dec 9 05:54:11 UTC 2008

>Jerome Peace wrote:
>> The useful part of Edgar's point was that the 3.11 folder on the ftp site sits empty.
>>  
>Please give me a bit of a break<...> and haven't
>got much done on the actual 3.11 in 6 months.

The post will prove to be a bit of a break.
Please notice the concern and attention it is generating.
Also please note I said waiting for not demanding.

The work (of producing artifacts) is not yours alone to do. And maybe it isn't the work you signed up for. So the post was for all of the community.

My curiosity wanted to find out
1) what the situation was and
2) what the community wanted to do about it.


>
>In actual fact I have only spent a couple of non-spare weekends on the
>actual final form of the 3.11 building bit. That is the smallest part of
>the 3.11 effort!
>
>It's a bit soon to be asking for artefacts after 2 weekends work.

Tain't asking. Waiting.

The point at which I am willing to get involved is when the image artifact appears.
This makes sense to me because an image needs only be built once.
There is no reason for me to set myself to that task too.
Once the image exist I can enjoy more bug tracking within.
And sync my repairs to the current state of the image.


>Having said that instructions on building 3.11 images were
>published on the releases list, months ago (September I think it was),
>and those scripts have been around since January last year.

That's my point. If they exist and they work then the proof would be an image existing also.
If the release team needs help in building an image then you need to make that request to the list. A lot of energetic, idealistic newbies have shown up. And if they are not interested, I know of at least one cantankerous Argentinian Rosarian who likes to build them and has asked for them to be built.

And I now see that even Andreas is willing to lend a hand to the task. The image artifact interests people in a way the other proto artifacts don't.
>
Well that's enough the rest of the reply will have to wait.

To sum up.
I hope you have found the outpouring of concern and offers of help in this thread a help.
The post was aimed at the community, not at you or Matthew personally.
I appreciate your abilities and spirit of service.

I am patient enough to wait until a 3.11 image is ready.
I am willing to get involved when one is available.

Yours in curiosity and service, --Jerome Peace



     

Hi!

Jerome Peace wrote:
> To sum up.
> I hope you have found the outpouring of concern and offers of help in this thread a help.
> The post was aimed at the community, not at you or Matthew personally.
> I appreciate your abilities and spirit of service.
>
> I am patient enough to wait until a 3.11 image is ready.
> I am willing to get involved when one is available.

Let me just chime in and point out a few "obvious facts":

- We should all be grateful for *any* work being done for the community
etc. It doesn't matter if it is about getting the damn server up or
improving our tools or just finding a silly bug. Or writing a tutorial.
All efforts are valuable. I think we all know this. :)

- The only thing I *expect* from a release team is that they:
-- Communicate with the community (up to the team leader to decide how)
-- Try to enable people to help out

I can never *expect* anyone to actually *produce* anything - because
this is an open source project, we all do the best we can given our
personal circumstances. Sometimes we have time, and sometimes we are
choked. Some of us can, and some of us can't.

Now, note that I personally don't think the 3.11 team ever has been
*officially* started! I haven't seen an announcement and I don't know
who is the team leader. So given *that fact* I don't have any complaints
yet regarding my two expectations noted above. :) Instead I am just
grateful for all the work having been done. But IMHO it is HIGH TIME to
get 3.11 in motion. Officially.

So... to move further, can someone distill this thread into howtos on
the Squeak Swiki somewhere? That seems to be a good start.

An official announcement (from the board of course) of the 3.11 team
including who is the team leader would also help. Including getting the
team table on squeak.org updated.

regards, Göran

+1 on all of this. And Göran, are you up to offer a bit of help? Like
organizing the Wiki pages? We should all help to scratch the itch we
feel and that seems to be one that itches you most ;-)

Cheers,
   - Andreas

Göran Krampe wrote:

Hey!

Andreas Raab wrote:
> +1 on all of this. And Göran, are you up to offer a bit of help? Like
> organizing the Wiki pages? We should all help to scratch the itch we
> feel and that seems to be one that itches you most ;-)

Hehe, well... given that my time actually is a bit scarce I could try to
give it a go later tonight.

regards, Göran

I think Janko is misunderstanding.  I believe when Goran mentioned 'paid
people' he is referring primarily to Squeak Central in the early days
who of course were actively funded by Apple and then Disney.  More
recently of course others have been able to contribute using time kindly
provided by their employers (Pinesoft comes to mind as an example) and
occasionally work has been funded by a company (Qwaq for example) or an
individual who needs it.  We have never had a system of funding from a
community foundation, for that matter we've not really had a formal
foundation that could do so, at least under any sort of legal/tax
framework.

Ken

On Wed, 2008-12-10 at 23:08 +0100, Janko Mivšek wrote:

Hey!

Ken Causey wrote:
> I think Janko is misunderstanding.  I believe when Goran mentioned 'paid
> people' he is referring primarily to Squeak Central in the early days
> who of course were actively funded by Apple and then Disney.  More

Right, that was what I was referring to. More or less Dan and Ted IIRC.

> recently of course others have been able to contribute using time kindly
> provided by their employers (Pinesoft comes to mind as an example) and

Mmmm, but not typically for harvesting, right?

Anyway, my whole point is that it is best if we can find a process where
the "harvesting part" is minimized. Several of us have wondered if it
would be better to just have "commit rights" and then fix any problems
that arise from that - which would imply better tools to "back stuff
out" - which in turn points towards the idea of multiple streams etc.
(DeltaStreams and in some ways the mechanisms provided by Installer/Sake
etc).

For example - using Installer you can today point to a fix on Mantis and
install that changeset as a oneliner. So people can more or less "pick"
the fixes they think are fine. And if we add some kind of feedback
system into this then fixes could become "included" if enough people use
them.

Just thoughts. But the idea of having active "smart" harvesters
reviewing and integrating fixes from the rest of the community on a
regular basis is IMHO a tried and failed one.

regards, Göran

On Thu, 2008-12-11 at 23:39 +0100, Göran Krampe wrote: True, good point.
Well my preference is to instead minimize what a harvester has to do for
each 'fix'.  Split what we currently refer to as harvesting into two
pieces: 1. the evaluation of the fix 2. incorporating the fix into a
release or release stream.

In my opinion a large number of people, an open group with no official
membership needed could perform the first step, the actual manual
testing and evaluation of fixes and record opinions for and against it's
inclusion into a release.

A much smaller group would serve as a final backstop and selectively
perform step 2 based on comments from the first group.  Ideally this
step would involve little more than an on/off switch (in the release/out
of the release) although with the addition of automated testing, maybe
seperate unstable and stable release artifact, the switch would have
more settings.  So a harvester is responsible for reading opinions but
then takes those at face value and if they read well, then flips the
switch on.  If the harvester at that point detects, via automated
testing, or just through personal use that this was a bad decision then
he flips the switch back off.

If someone else detects it was a bad decision they update the report
with the appropriate evaluation.  The harvester(s) should receive
notices of the report and this should trigger one of them to strongly
consider switching off the inclusion of the fix.

Ken

Göran Krampe wrote:
> For example - using Installer you can today point to a fix on Mantis and
> install that changeset as a oneliner. So people can more or less "pick"
> the fixes they think are fine. And if we add some kind of feedback
> system into this then fixes could become "included" if enough people use
> them.

Well, we could do something like here:

   http://installer.pbwiki.com/LevelPlayingField-Squeak3:7

A Wiki page (nominally password protected) with candidate fixes and
maybe sections for "untested", "confirmed", and "problematic" with
discussions around the issues. At the end of the process the agreed upon
patches would go into the "approved" section and copied into an update
stream or MC releases for the new version.

If there were a page like this for every release, this may also be a
nice way of discussing potential backport candidates etc.

Cheers,
   - Andreas

Andreas Raab wrote: Hi Andreas,

you mean like this?

(not yet approved)  -
http://installer.pbwiki.com/MinorFixesUnstable-Squeak3:10
(ready)                    -
http://installer.pbwiki.com/MinorFixes-Squeak3:10

Thats exactly the approach I put in the original proposed 3.9.1. In Oct 2006
Similarly Bob version 1 took his build instructions from a wiki page.

Edgar complained bitterly that it was on a wiki and was remote script
based. So now we have moved it into Tasks, code managed by Monticello
(still publically editable but from within the image).

Still after fighting my way through a few fixes, I think it is still too
much like hard work.
Ken Causey and I are cooking something up

Keith

On Fri, 2008-12-12 at 07:48 +0000, Keith Hodges wrote:
> Still after fighting my way through a few fixes, I think it is still too
> much like hard work.
> Ken Causey and I are cooking something up
>
> Keith

Slowly, it takes a while for Keith and I to synchronize brainwaves and
I'm rather conservative about making changes.  But I'm sure we will come
up with something, hopefully something better than the status quo.

Ken

Keith Hodges wrote:
> you mean like this?
>
> (not yet approved)  -
> http://installer.pbwiki.com/MinorFixesUnstable-Squeak3:10
> (ready)                    -
> http://installer.pbwiki.com/MinorFixes-Squeak3:10

Yes, that's what I mean.

> Edgar complained bitterly that it was on a wiki and was remote script
> based. So now we have moved it into Tasks, code managed by Monticello
> (still publically editable but from within the image).

I would have to agree with Edgar if the end result were a wiki page
scraping bits from all over the net. However, as a development tool I
see nothing wrong with it. From my perspective this is useful up until
the point where it's declared "ready" - at this point this needs to be
copied into a more permanent location (an upate stream comes to mind).

In which case (I think) you can have your cake and eat it too: An agile
tool for the development stages that everyone can edit and the "usual"
permanent location that people are used to.

Cheers,
   - Andreas