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.
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.
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.
4.) clean up trac and move patches into proper categories. (see the
list above)
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)
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
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
--
John Crispin
hacking, coding, etc
blogic on irc
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
KAMIKAZE (bleeding edge) -----------------------
* 10 oz Vodka Shake well with ice and strain
* 10 oz Triple sec mixture into 10 shot glasses.
* 10 oz lime juice Salute!
---------------------------------------------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
