Re: Crush 2.0 abandoned - Looking At The Big Picture

[Prince Riley <wmarketing3@gmail.com>]

Hello Everyone --

Hector, Neil, Simon, and the other list members who have recently posted your suggestions and ideas on how to move ahead on Crush 2.0 your contributions are very much appreciated. 

Now that we appear to be headed toward better scoping Neil's issues list, can I suggest you reference the issue number and create a header for the post subject line. When we can pull together the wiki that was suggested earlier, those subject lines will help in collecting/categorizing the relevant e-mails together and creating good links pointing back to them. Thanks in advance to those who put in this little bit of extra work. 

As we begin to delve more deeply into the mechanics of getting Crush 2.0 restarted, here are my thoughts on the overall strategy we can adopt in defining both the scope of the new effort and leveling the effort across the members of this list . 

Participation by working on one or more issues is requested, encouraged, but not required. I know many of you have skills, resources, and insights you would like to contribute, but are wary of making commitments at this early stage. Whether its a day, a week, a month, maybe even just an occasional hour or two can help greatly here. 

By the end of next week, our goal should be to have framed the project's major challenges in enough detail that we can begin laying out the specifics solutions to Neil's item list. When that's done, opportunities large and small will emerge and then if as many of us as can sign up to work on them, in whatever way we can, progress will be made without putting to big a burden on anyones shoulders. 

Now, and later when the solutions are in front of us, the basic approach we can follow can remain the same. Whether we work in teams or as individuals, the basic steps of our strategy for Crush 2.0 (Neils list) are to:

1. Gain agreement on the problem
2. Gain agreement on the direction for a solution
3. Gain agreement that the solution solves the problem
4. Agree to overcome any potential negative ramifications
5. Agree to overcome any obstacles to implementation

Those of you familiar with Dr. Eli Goldratt's Theory of Constraints (TOC) recognize these steps. The premise of TOC is that

1) any manageable system's limited in achieving more of its goal by a very small number of constraints, and

2) there's always at least one constraint.

The goal of TOC process is to identify the constraint and restructure the rest of the the Crush 2.0 development effort around it, through the use of the Five Focusing Steps listed above. Several candidates of that key constraint have been suggested in discussions here. By next week, we should have narrowed (prioritized) them so that we have a concensus. That covers steps #1 thru #3.

What follows those first three steps are list member's signing on/singing up under some workable project framework structure keeping steps #4 and #5 in mind.

Again, looking forward to working with all of you.

Prince

 

goal of this process is  practitioners sometimes refer to these in the negative as working through layers of resistance to a change.

Recently, the Current Reality Tree (CRT) and Future Reality Tree (FRT) have been applied to an argumentative academic papering

On Wed, Aug 12, 2009 at 6:43 PM, Simon Richter <sjr@debian.org> wrote:

Hi,

On Wed, Aug 12, 2009 at 01:52:13PM +0200, Hector Oron wrote:

> Package source format (we wish) will allow to have foreign
> dependencies (build-cross-depends or bootstrap dependencies fields).

If we have a small enough change we might even shoehorn that into squeeze,
so we can start sending patches to Debian maintainers after the squeeze
release.

The "cross building" use case can be handled by simply adding a third
"magic" architecture name and have the Debian tools handle that as if it
meant a strict ("same" if I understood it right) dependency.

For Debian, this brings no real benefit for squeeze as they don't want to
cross-build, but it will allow us to merge the patches distinguishing cross
and native build dependencies back into Debian (the official autobuilders
use stable apt/dpkg to install build dependencies, so packages in unstable
need to be fully supported by the stable tools).

For squeeze+1, we can then push for "multiarch phase 2" which includes
declaring dependencies on foreign architecture packages, which will be
necessary for both firmware builds (which are currently handled by building
the firmware as an arch:all package on an e.g. ARM host) and cross compiler
bootstraps. Such packages could exist in emdebian's unstable for the time
being, and be added to Debian unstable after the squeeze+1 release (so
cross compilers will be built using the method we outlined in Cáceres).

> Multiarch solves many things, but it will not be ready for our needs on
> Squeeze, but it could be ready for Squeeze+1. What I (also Neil) meant
> it is better to work towards that approach than fix apt-cross perl
> bindings, dpkg-cross and patch all the packages to be able to cross
> build properly for Crush2.0 which will be deprecated after multiarch is
> ready. Did I make sense?

Yes.

dpkg-cross will not go away soon, but it needs to do considerably less for
multiarch packages. It already supports a very similar mode (cross2cross)
where it filters the file list only and creates an output package that is
arch:all -- if that is adapted to handle the multiarch paths similarly, it
should be enough to get us to squeeze+1. This change should happen before
squeeze. I can do that, but would prefer if someone who actually knows perl
looks at it (in principle: add regexes matching the multiarch paths and
handlers that copy the file into the same path in the target package; also,
the created package needs to Provide and Conflict with the original).

  Simon

--
To UNSUBSCRIBE, email to debian-embedded-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org