Ralph Passgang dixit:
>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.
Yep, like with BSD ports. But not now… we don't really have
maintainers yet. But if it's time to do this, I'll do it.
We also need licence stuff:
PERMIT_DISTFILES and PERMIT_PACKAGES
>- 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.
Overkill IMO.
>- for "non maintainer uploads/commits" we should specify a common way of
>handling this. for example: at first ask the maintainer
Of course - but we need more communication in all areas ATM.
>- set a timeframe for broken packages
Maybe, but for now: if you see it's broken, you fix it or tell someone
to fix it and give him a timeframe.
>- 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.
wbx@ maintains the "stable" branch, and all commits should be ok'd by
him; if they aren't, they should be reverted ASAP automatically, even
(yes, even!) if they're okay, if he hasn't seen them before.
>- 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.
This is difficult. I think stuff like that should not be done
automatically, because it's responsibility of the admin. For
example rc.conf, if I ipkg remove an old package then ipkg add
a new version of that package, the old rc.conf entries are just
fine.
>- use the most recent svn revision number (from 'svn log
>packages/<packagename>') for the package dash version (PKG_RELEASE) in trunk
No! The dash-ver is used to determine if the package has to be
rebuilt or not (among other things).
Besides: how many megabytes of policy documents do you want a
new developer to read before being able to join? I don't think
we should become a second Debian… but a little bit of "policy"
is desirable.
bye,
//mirabile
--
"Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
-- Henry Nelson, March 1999
_______________________________________________
freewrt-developers mailing list
[email protected]
https://www.freewrt.org/lists/listinfo/freewrt-developers
