Is there a decent way/tool to keep this on a website as a
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"
I guess something in the following is a good start.
> 1. Gain agreement on the problem
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:
> 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
>> <http://_the_five_focusing_steps.totallyexplained.com/> listed above.
> 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
> 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.
> 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 <firstname.lastname@example.org
> <mailto:debian-embedded-REQUEST@lists.debian.org>> <mailto:email@example.com>> wrote:
> 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
> so we can start sending patches to Debian maintainers after the
> 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
> use stable apt/dpkg to install build dependencies, so packages in
> 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
> the firmware as an arch:all package on an e.g. ARM host) and cross
> 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
> > 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)
> > 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?
> dpkg-cross will not go away soon, but it needs to do considerably
> less for
> multiarch packages. It already supports a very similar mode
> 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
> 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).
> To UNSUBSCRIBE, email to debian-embedded-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact> firstname.lastname@example.org <mailto:email@example.com>