Ainsi parlait Buchan Milne :
> Guillaume Rousse wrote:
> > Ainsi parlait Denis HAVLIK :
> >>On Tue, 4 Mar 2003, Guillaume Rousse wrote:
> >>
> >>Club does not restrict its volunteers in this way.
> >
> > That's the reason of duplicated work.
>
> Would you like to list examples of duplicate work??
>
> I guess someone besides Danny has a working preempt kernel rpm (for
> example)?
>
> Unless there is a vast quantity of packages that have been duplicated,
> the whole argument is senseless at present.
Duplicated is not the correct word, rather potentially duplicated. I'd never
checked in club before creating a quakeforge package, for example.
Check my originally submitted list, for me all packages listed as "club only"
should not be there until they are either in contrib (license allowing) or in
PLF (license problem) for cooker level.
And just because there is no duplicate currently doesn't means there won't
ever.
> If you want, I will dig up some examples where duplication was
> *prevented* by club ...
>
> >>If there is demand for an aplication, and one of the volunteers (folks
> >> who are allowed to upload stuff) builds it, he/she can upload it and put
> >> the pack in "testing" status imediately. When testing is done, and the
> >> users are happy, he can move the packs to "done" area.
> >>Uploading for cooker contribs too is recomended, but I have no mean to
> >>enforce this.
> >
> > Yes you can: just prevent new packages to appears by checking against
>
> main and
>
> > contrib in cooker branch. This will force them to either forward their
> > request to contributers, or ask for a contributer status themselves.
>
> Huh? How does this help? Would you want to
> 1)restrict RPMs to ever be created by the few that have contrib access
Nothing prevent to give contrib access to more people, provided there is some
criteria for this.
> 2)force contributors to follow cooker to find why their packages build
> at home but not on cooker?
That's the whole problem of backporting. Short-circuiting avoid it, but
doesn't solve it.
> 3)Force people to wait for something to get into contrib, when they have
> a working rpm for a stable release, and the end-user also is running a
> stable release.
Nothing prevent them to upgrade to cooker, if they really want bleeding-edge
software and can't wait for next release.
> >>There is absolutely no control on "what's uploaded" on my side, but
> >>volunteers need to pas a test before getting upload permissions, and we
> >>can also revoke the permission in case they start producing bad packs.
> >
> > Same for contributers (aka: people with an account on klama)
> >
> >>This is quite close to Debian way of doing things, and IMO much better
> >>than the system where one person is supposed to check all incoming
> >>packs...
> >
> > I guess you're refering to the past when Lenny was alone. This isn't true
> > anymore.
>
> Oh, so I have read access to /incoming then ;-)?
>
> We have a Request For Package system (besides cooker - see thread on
> linecontrol, which was also instigated by Club ...)
Don't misunderstand me: i think the club is wonderful for extending stable
release life, and also for user input. I also think a formal RFP system would
be great for cooker. And lastly, i think every *.mdk package currently
included in PLF archives would definitively be better in club. But it doesn't
make the club the best place for introducing new packages.
--
Disks are always full. It is futile to try to get more disk space. Data
expands to fill any void.
-- Murphy's Computer Laws n�4
