From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Thu, 17 Apr 2008 14:01:48 -0400 Subject: [U-Boot-Users] u-boot wiki and arch-specific details In-Reply-To: References: <200804131926.41049.vapier@gentoo.org> <200804141334.57715.vapier@gentoo.org> Message-ID: <200804171401.58162.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thursday 17 April 2008, Detlev Zundel wrote: > Hi Mike, > > > On Monday 14 April 2008, Detlev Zundel wrote: > >> > we maintain a Blackfin-specific u-boot wiki that goes into quite a bit > >> > of detail, some of which is duplicated with the main u-boot wiki. how > >> > do people feel about extending the u-boot wiki to allow for > >> > arch-specific details ? > >> > >> What exactly do you have in mind? I surely don't see any principal > >> problem here. > >> > >> It would certainly be valuable to get all U-Boot related info collected > >> in a central place and have pointers wherever that make sense... > > > > from my reading of the wiki, it's more of a technical/command reference > > than a guide. the wiki we maintain is geared to be more of a guide. i > > think the two can be merged, i just dont want to convert things only to > > find out people dont want to take it that direction. > > Just to be clear, we are discussing the DULG wiki, right? is there any other worth talking about :) > I agree that in the current state the documentation is more a reference > but IIRC that wasn't really a conscious design decision. It simply > turned out this way in the end. > > So I do not see any general problem in adding "guide style" sections in > there. Maybe then most of the current documentation can then be shifted > to a "commands reference" section. OK > One problem I see though is how to correctly adapt such sections to the > board specific nature of the DULG. Hopefully we can get away with > mostly generic text passages and only a few ifdefs. It would be very > helpful to know more concrete plans (outline!) to think further about > these implications. so talking to some people on our side and i realized i forgot about a lame (but important) aspect. we need to retain full copyright over our docs. we license it all under a non commercial creative commons license, but sometimes we get customer requests to include portions of our docs into their work but under their own rules. if i were to merge the our wiki with the DULG one, we couldnt in good faith continue that practice. so the wiki's will have to remain sep, but i can push content into the public one to improve it, just not vice versa. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://lists.denx.de/pipermail/u-boot/attachments/20080417/e86a8447/attachment.pgp