[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Crush 2.0 abandoned - Looking At The Big Picture

Is there a decent way/tool to keep this on a website as a
discussion/reference/status/todo ??

wiki or blog or ... ??

a wiki page with summary of issues and direction, and separate wiki for
each issue with details on solutions, etc.
Is the standard bug tracking tool enough.  maybe it's not "dynamic"
enough ??

I guess something in the following is a good start.


Prince Riley wrote:
> 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
> <http://_the_five_focusing_steps.totallyexplained.com/> 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
> <mailto: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
>     <mailto:debian-embedded-REQUEST@lists.debian.org>
>     with a subject of "unsubscribe". Trouble? Contact
>     listmaster@lists.debian.org <mailto:listmaster@lists.debian.org>

Reply to: