> >So not to get this wrong: the policy you mentioned is really important,
> >and also useful. For about every package other than this one. ;)
>
> That was my point. Other comments?
yes, a policy about how packages are handled would be good. I am also against
removing packages just because someone things it's too big or too slow for
embedded devices. I am not talking about ltp, so for me it's okay when it's
removed, but in generell "too big" should be not a valid reason.
Thorsten is totally right. Because of cf-cards and usb memorysticks and
harddrives, the available disk space of some embedded devices can be huge.
If we talk about a package policy, here some things that comes to my mind:
- add PKG_MAINTAINER variable to each Makefile, so that it's easy to see who
is maintaining what. the policy should list all required "PKG_" varibales
that each maintainer has to use.
- use groups for packages that have multiple active developers/maintainers.
use group-mailinglists for discussion about group related and packages
internal stuff. The "PKG_MAINTAINER" variable should list the groupsname is
such a case. Maybe using "@<groupname>" so that it's recorgnizable as a
maintainergroupname.
- for "non maintainer uploads/commits" we should specify a common way of
handling this. for example: at first ask the maintainer, if the maintainer is
not agreeing that there is a good reason for someone else to commit something
(or for example not replying at all), then waldemar must be asked for the
correct way of handling the particular issue. So no commit without the
package maintainer or waldemars agreement for a foreign packages.
- set a timeframe for broken packages, so that broken packages, which have not
been fixed in (for example) 30 days, will be automaticly removed from trunk
(and maybe even branch). This should apply to packages that are known to not
build correcty and to packages that are totally unusable (for example
reported via the ticketing system) or have major security issues. There
should be one or even more warnings to the <PKG_MAINTAINER>@freewrt.org that
package XY is broken and will be automaticly removed in Z days. Maybe even
one or two automatic warning to freewrt-developers would be great.
- as our users base is growing, we might think of a timeframe before new
trunk packages or major trunk changes are allowed to be merged into branch.
This is for assuring a high quality in branch, because most likely problems
in the trunk version will be reported before the package is merged to branch.
- the policy should also describe where files are stored on our targets and
for example that after a ipkg package is removed every installed file needs
to be removed as wells as run-time generated files and also entries
in /etc/rc.conf for example should be deleted. Maybe even logfiles and so on.
Or in other words: It should describe exactly how packages should behave when
it gets installed/removed/upgraded :)
- use the most recent svn revision number (from 'svn log
packages/<packagename>') for the package dash version (PKG_RELEASE) in trunk
(not branch!). This could be done by setting: "PKG_RELEASE:=
${SVN_REVISION}"
in the Makefile and letting the build system set the correct version for each
individual package automaticly. This helps to see when exactly a package has
been touched the last time without the Maintainer need to set this number
each time he changes something.
just my two cents ;-)
bye,
Ralph
_______________________________________________
freewrt-developers mailing list
[email protected]
https://www.freewrt.org/lists/listinfo/freewrt-developers
