[Frugalware-devel] questions about syncpkgd2

[VMiklos]

Hello,

Na Mon, Jul 30, 2007 at 10:54:06PM +0200, Gabriel C <crazy at frugalware.org> pisal(a):
> > 1) still allow this feature (uploading packages manually and
> > automatically, too) or
> > 
> > + no big change, does not violate freedom
> > - when will we build a pkg? if no upload with in ie 2 hours? that will
> >   slow down syncd again
> 
> Really what do you mean by *slow down* ?! 

currently if you're lucky, your pkg is built in 10 mins, if not then it
may take a half of a day. this is not a big issue if we can upload
packages manually (imagine a package that somehow does something really
mad - ie rm -rf important files or whatever - then waiting a half of a
day for a fix is quite annoying)

>   - if syncd is acting up ( deleting packages or whatever else ) we are screwed

this is already an issue, if for some reason syncd decides to rm *.fpm,
then it'll be mirrored out and we'll loose our fpms. in fact of course
this is already handled very seriously and it never happened

>   - in 'long-term' no one will even *try* to build any package local resulting in :
> 	-- s/1.2/1.2.1/ && push out
> 		which means again :
> 			-- broken and not tested packages _at_ all

this does not mean you should not build & test packages, it just means
if you somehow did some trick (you build not in a clean chroot, etc),
then it won't affect the uses as the packages are built automatically. i
think this also improves security: if one does something bad by
accident, then it _will_ have some log in the scm, ie you can't do
something like:

1) modify the FB and cause some silly bug
2) build the fpm
3) fix the silly bug
4) push

or:

1) you detect a bug
2) rebuild without relbump
3) push

-> other arches won't be fixed

to sum up: i think building all packages automatically improves the
quality of packages and also much more secure. and here i'm not talking
about malicious devs because i still think the team is small enough that
i trust devs, but i'm talking about accidents. during the past few
months i can remember at least 2 times i uploaded buggy fpms, which
included wrong README.Frugalwares, because i thought i know what i'm
doing, then forgot to clean the chroot after a failed build, built an
other pkg and voila: the new pkg contained an unrelated readme.fw

> > so, what do you think about this? i think in long-term it would be good
> > to choose 2), that would ensure a higher package quality
> > 
> 
> Only 2 is not a good idea , giving only some build tools ( scripts etc ) the power to upload fpm's / packages
> is wrong .. ( of course IMO ) 
> 
> And I don't agree at all about the 'higher package quality' packages we already check for 'chroot builds'
> on upload and that is good as is.

we do not check about clean chroots. and if we deny building in a dirty
chroot, we make debugging impossible. just the pkgs hitting current
should be built in a clean chroot

> > in short-term, maybe it would be good to choose 1), but then we need
> > this ugly "build the pkg if no fpm uploaded in x time" hack, and we
> > should decide such an interval
> 
> Why ugly ? and why we need run the daemons all xx minutes or all some hours ?
> 
> Run 'twice' a day and is fine for stable and current 

basically yes, but if syncd build all pkgs then waiting half a day for
an important fix may be too much

to sum up: you say would it be good to stay at 1) and build packages
automatically if we waited at least 12 hours after the push (in case the
pkg is uploaded manually till then)?

feel free to correct me, i just want to sum up our ideas so that
hopefully we'll have a constructive discussion, not a flame :)

thanks,
- VMiklos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/attachments/20070730/f176d5d5/attachment.bin