Hi Ralph,
On Sun, 18 Feb 2007 at 17:15 +0100, Ralph Passgang wrote:
> > >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.
Sure. It was just one of the points n0-1 told me, why it is
unuseful. There are more issues with ltp, but I didn't know so many
developers like to know the real reasons ;)
> 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.
That will come with the new NFO-System. Phil is working on the
NFO-Parsers, and I hope we see the first code next weekend. Phil?
> - 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.
We even have mostly no Maintainers for most of our packages. So I
don't think we need groups. Except for shorewall ;)
> - 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.
Fine with me.
> - 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.
Disabled via package/Config.in should be enough. Or PKG_BROKEN:=1
> - 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.
Not yet, because nobody is using trunk, except Phil ;)
> - 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.
Good idea, but Thorsten has a good point against it.
Ralph: Can you make a draft for a package and svn policy based on my
draft I send you last week, plus your ideas?
bye
Waldemar
--
don't open your wrt, free it
http://www.freewrt.org
_______________________________________________
freewrt-developers mailing list
[email protected]
https://www.freewrt.org/lists/listinfo/freewrt-developers
