Am Montag, 1. November 2010, 22:04:59 schrieb davidMbrooke: > On Mon, 2010-11-01 at 21:32 +0100, KP Kirchdoerfer wrote: > > David; > > > > Am Sonntag, 31. Oktober 2010, 22:09:54 schrieb davidMbrooke: > > > On Sun, 2010-10-31 at 20:50 +0100, KP Kirchdoerfer wrote: > > > > Am Freitag, 29. Oktober 2010, 20:25:58 schrieb Andrew: > > > > > > > > Ok; I propose: > > > > - just "core" and "contrib" repository (names are not fixed), testing > > > > isn't needed - we can also put packages in contrib which we > > > > consider for testing or provided as-is. > > > > > > Just to make sure I understand 100%, some examples: > > > etc.lrp: Certainly part of "core". No debate. > > > > Maybe this also debatable :) > > > > The most radical way (besides opening it all) would be just to define > > "core" just as buildenv and buildtool itself. Which is the bare minimum > > to build packages on a definded base (uclibc version). > > Though even that raises pb's. What if a user wants to provide a complete > > new kernel arch? And in the developer guidelines and policies we asked > > to provide modules not in the package, but with modules.tgz.... > > > > During 2.x and 3.x we thought about "core" mainly as "packages that are > > provided on the floppy image" - but as that donÄt exist any longer..., > > and it doesn't work very well in the long term. > > > > > asterisk.lrp: Certainly part of "contrib" (only if it is fixed?) > > > aiccu.lrp: Not part of "core", since only relevant to some users, > > > but > > > > > > you (kp) and I (dMb) would be willing to upgrade, test, repair etc. > > > > Both belongs shurely to "contrib" > > > > > Should we distinguish "supported" contrib from "unsupported" contrib? > > > Something like "primary" (instead of "core" - approx 10 packages that > > > EVERY user will need), "secondary" (tested and supported, but not > > > "core"), then "contrib" for the others? > > > > Hmm, the idea of "approx 10 packages that every users need" is a good > > one. Your "secondary" and "contrib" maybe rephrased as "packages" and > > "testing"? (primary/packages/testing) > > > > kp > > Hi kp, > > To me, "testing" implies a temporary state: "will move somewhere else > when testing is successful", which isn't quite what I had in mind. A > package in "contrib" will always stay in "contrib"... > > In terms of packages (i.e. ignoring buildenv and buildtool) then "core" > or "primary" is: > - kernel (OK, not really a "package" as such...) > - initrd > - root > - etc > - modules > Would a system actually run with just this list (+ moddb + configdb)? > > Then there are "mainstream" add-on packages: > - iptables > - shorwall > - Hence also libm, perl > - ip6tables > - shorwall6 > - dropbear > - dhcpcd > - dnsmasq > - mhttpd > - webconf > - A few more perhaps? > > Others would be "contrib". > > So maybe 3 categories: "core", "mainstream", "contrib" ??? > > dMb
David; I've slept and thought over this the past weeks. In the meantime Erich has been added to the list of developers being able to commit and it worked out pretty well. I've made the experience in the past that too restrictive settings are more a loss than a win. So I think we may go with a more open-minded and easy-to-understand rule. Current cvs should be open to every LEAF developers who asks for write permission - assuming everyone is aware of the responsibility having write permissions. A contrib section should be added with write permissions for everyone who has been added as LEAF developer. Sounds easy and effetive to me :) kp ------------------------------------------------------------------------------ Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! Tap into the largest installed PC base & get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
