[EMAIL PROTECTED] wrote: > Coming back to the never ending story of patches not being applied .... > > i think the first question that needs to be solved is : > > 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.
IMHO, bugs should go in some maintained (bugzilla) system that follows up on bug. ML are for questions, discussion, ideas, etc.. Patches should also be submitted to the 'patch system' in order to avoid losing/ignoring efforts of the submitter. As you pointed out owrt developers do have other work and sometimes there is just not enough time to comb the ML for patches, apply, test and commit them in proper fashion. > > Trac is much more usefull here. i certainly cannot remember why patch > series started to pop up on the ML and not in trac. > > Trac is full of bugs, which we do want and need to apply. We owe this > to the users and contributors of owrt. > > Trac is totally disorganized imho. There is no clear differentiation between > * bug fixes > * updates > * new packages > * new ideas > * images not booting on certain hw > > We need to think about a way to make this cleaner. > > The last thing we want is for people to get pissed off and switch to a > less powerfull system. I second that. I'm little uncomfortable with trac too, but thats me as a user, although there are some nice features I like - source browsing, OTOH I don't know nothing about the tickets.. John is right, things should be more organized in the patch submission department. I too posted few patched on the ML, but at the time I was not aware of the trac, and now that I about trac I not quite sure how to submit patches via it (..i know RTFM..). > > 808 should not only be a release but as part of it, we as the dev team > should think about these issues and address them. > > So here is my 10 point plan of how we could change this. > > 1.) Create a proper user manual > > 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) > > 3.) NOT!!! use ML to submit patches. ML should be used as a discussion > only or for really large patch series, as was done for PS3. If a patch > is up to discussion, then put it on the ML once the issues were > solved, the patch submitter should copy the patch to trac. > I agree. > 4.) clean up trac and move patches into proper categories. (see the > list above) > I agree. > 5.) some times patches can have quite an impact on owrt, that might > not be that obvious from the start (update of pppd, i certainly wont > commit such a patch without trying it on 10+ devices, as it affects > the core function of a pppoe router, which takes time) so we need to > find a way to handle this. > > 6.) less flaming please. as said before, we all work really hard and > some times it just takes time. I for example do about 55+ hours a week > before even looking at owrt. > > 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) I like package maintainers idea too. > > 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 > A nice overview of the packages included would be nice, yes. Along with some comments about the package and its usage. > 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" > > 10.) last but not least, find a codename for 808 > > Any suggestions feedback is welcome > just my 2c. Regards, Hinko -- ČETRTA POT, d.o.o., Kranj Planina 3 4000 Kranj Slovenia, Europe Tel. +386 (0) 4 280 66 03 E-mail: [EMAIL PROTECTED] Http: www.cetrtapot.si _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
