Am Dienstag, 20. Februar 2007 08:06 schrieben Sie:
> 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 ;)
:)
In general it's better to be prepared for upcoming changes. What about when
there are more active developers in future? Using groups for some packages
could be wise than, but for the moment it's of course not needed.
> > - 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
PKG_BROKEN would be _cooler_ than disabling it in package/Config.in. It also
helps to have all package related information in one place.
But maybe we can also use the style of the normal linux kernel. The linux
kernel has an config option to hide all features that are "known to be
broken". If we would do so, the default should of course be to hide all
broken packages and features, but it would make it easy for developers to
say: "I don't care, give me all packages/features that are available, even if
they are broken" without to edit any Config.in or Makefile at all.
Maybe we could also call it "not tested or known to be broken" and mark
additionally all packages that (for example) a customer needs and has asked
for but where we are not sure about if it's really ready for the masses.
Hmmm, PKG_NOTTESTED sounds nice .)
> > - 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 ;)
sure, it's the same as with the group feature. for the moment not important,
but might be a good feature in future.
but maybe (because of the complexity of this topic) it's better to not include
it in the first version of the policy.
> > - 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.
By thinking of this, the only problem I see is that local changes are not
catched by this. The dash version would not change as long as no svn commit
has been done. This could be a problem, because (as thorsten said) the dash
version is important for the decision of the buildsystem if a package needs
to be recompiled/repackaged.
maybe this is a solvable problem, but for the moment overkill :)
> Ralph: Can you make a draft for a package and svn policy based on my
> draft I send you last week, plus your ideas?
I will send you an updated version of your draft. Please give me some days for
it... ;-P
> bye
> Waldemar
_______________________________________________
freewrt-developers mailing list
[email protected]
https://www.freewrt.org/lists/listinfo/freewrt-developers
