> do we want bugs to be reported in trac or on the mailing list. > I personally find it difficult to keep track of which patches on the > mailing list have been applied and which have not.
I'm perfectly fine with whatever mechanism is easiest for the developers actually applying the patches. It's nice to have ML-level posting for discussion, although I admittedly don't look at any I don't know anything about. > Trac is totally disorganized imho. There is no clear differentiation between > * bug fixes > * updates > * new packages > * new ideas > * images not booting on certain hw <snip> > 1.) Create a proper user manual IMHO, these issues are related. Several times I've encountered the non-unanimous [but stated and not countered] opinion that documentation and end-user presentation are unimportant as long as *something* is out there, whether good or bad. So little is clearly or coherently documented, it's a near-epic effort to dig into the system and really pick up what's going on. The wiki is a perfect example - as often as not it's a steaming pile, full of factual errors and inconsistencies, constantly throwing 500 errors on anything more complex than rendering a single page, and is constantly being fed spam (which a few erstwhile users that have managed to get a login and use it actually manage to keep down). It's been "going to be migrated" for ages, which is often used as an excuse to not do anything about the problems, but that looks to happen no sooner than widespread abandonment of IPv4 for IPv6. Since I'm complaining, I'll stick my neck out too - I'd be glad to temporarily drop what little private development work I'm doing and commit to building (or helping build) a more-working wiki and documentation. Who can I get in contact with? > 2.) Add a MAINTAINER:= field to those packages where it makes sense, > so the patch submitter can peser the dev that is not maintaining his > package (for what ever reason) Absolutely, with the committment from the development team that should a maintainer become unresponsive for $hard_time_limit that maintainer's status will be revoked and either the package will be dropped into an 'unmaintained' category or the core dev team will take up maintainership. > 7.) get contributors to actually maintain their own packages (i.e. new > packages will only be applied, if a valid mail addr is present, this > person will then be the maintainer) Agreeed as long as commit for those particular packages is granted and vetted for a while. IOW, I would hope maintainership would be granted more on history than on presence - crowds of deadbeat one-time-committers would be the pain on the other end of the spectrum. > 8.) Clean up the wiki and ideally add docs for all the packages, even > if we generate this out of the Package/X/description fields Agreed, see above. > 9.) I am setting up a new server this weekend, that will do recursive > full builds and also dependecy bug testing, so we have a chance to get > trunk more stable. i know its trunk, but that does not mean we should > not try to keep it stable. Its one of the reasons i started on owrt, > as it "just works" Check with Travis/x-wrt, there's already at least one system building snapshots. > 10.) last but not least, find a codename for 808 Gargleblaster, since the delta from 707 is so huge. I also vote for 842. :) _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
