2006/10/16, Giovanni Giorgi <jj at objectsroot.com>:
> Philippe,
>  Giovanni is working hard to give us a workflow.
> I think you are posing the problems in the wrong way.

I'm just saying Squeak is extremely limited on development resources.
There is a lot of great stuff that we could do if we had more
development resources but we have to work with what we have got.
Sometimes stuff just doesn't get maintained because the maintainer is
extremely busy.

Sure it would be cool if "someone" could do this.

Also all suggestions have to orient themselves on the reality. Sure it
would be great if we just could drop package X because it is not
maintained. But often this is not simple and requires some effort. How
should do this if there is not even a maintainer for it?

Sure it would be cool if "someone" could do this.

Forking Xf86 worked fine because there were a lot of development
resources. A lot of the original team (except the leader) could be
taken over. There was work from fd.o to integrate. And finally there
is commercial interest in X11. People are getting paid for developing
this kind of stuff.

> A package without mantainer is in a very sick state.

Agreed.

> If we want to continue developing in Squeak, we must find a solution
> together.

Agreed.

Philippe

> On 10/16/06, Philippe Marschall < philippe.marschall at gmail.com> wrote:
> >
> > 2006/10/16, Giovanni Corriga < giovanni at corriga.net>:
> > > Il giorno lun, 16/10/2006 alle 12.50 +0200, Philippe Marschall ha
> > > scritto:
> > > > 2006/10/16, Giovanni Corriga <giovanni at corriga.net >:
> > > > > Il giorno lun, 16/10/2006 alle 10.55 +0200, Lukas Renggli ha
> scritto:
> > > > > > > This proposal is based on two points:
> > > > > > > - decentralization of development
> > > > > > > - fixed duration of iterations ("timeboxing")
> > > > > >
> > > > > > Sounds like a good proposal, however I see a couple of problems
> that
> > > > > > you don't adress:
> > > > > >
> > > > > > - How to manage the code and the changes? Most changes related to
> > > > > > Compiler, CompiledMethod, Behavior, Traits, etc. cannot be loaded
> > > > > > using Monticello.
> > > > >
> > > > > How did these things get managed in 3.9? By changeset and DoIts?
> Will it
> > > > > be possible to keep doing this for 3.10, until we develop better
> tools?
> > > > > (MC2 maybe?)
> > > > > On the other hand, I know this was pretty ugly for Marcus and Stef.
> > > > > Would reducing the scope of the changes to manageable bites solve
> this,
> > > > > at least in part?
> > > > >
> > > > > > - What to do with code that is not properly packaged yet? How to
> pass
> > > > > > code over to another package?
> > > > >
> > > > > Isn't all code in the image segmented into packages?
> > > >
> > > > In theory yes. In praxis no. You can't just go there and unload eToys.
> > >
> > > if we want eToys to be maintained, then the first task of the eToys team
> > [...]
>
> --
> "Just Design It" -- GG
> Software Architect
> http://www.objectsroot.com/
>
>
>
>