> how did I know this would cause fun :)
Heh :) Why do I have the feeling that I'm dipping myself into something
as we speak ? :)
> >> More information about the gate itself will appear when it is pulled
> >> out of thin air... I mean when it reveals itself in a dream... no I
> >> mean when we have figured that out completely. It's not just being
> >> made up as I go, honest. :)
> >
> > Are there any sketchups already ? There's one thing we have been
> > discussing here in Prague - the repository size.
>
> yes that has been a concern (even with teamware, though partial
> bringovers can help there).
To be fair, mercural might have partial clones one day also. It just
does not seem to be priority at the moment.
> > The files could be easily made available through http or ftp server
> > instead. It would require change to build scripts thought. Every
> > 'program' or 'library' would need to download the source first.
>
> Long ago I tried a simple makefile change which (with limited testing)
> cached the tar files in your workspace after downloading them (well,
> it used nfs but a script could download). My fear there was that
> I don't want adding more ways the build can fail because the download
> site is down/unreachable.
Yes, it's additional complexity.
> And though that site would probably be
> on opensolaris.org where we'd keep all the tar files to make sure
> they don't disappear and that builds aren't subject to 56 different
> ftp sites staying up all the time, that turns one putback into two -
> first drop your tar file in, then you can putback - and that worries
> me. But perhaps I'm the only one.
Imagine it other way around. You would specify source url in your change
to the product (being it sourceforge or anything) and our mirror would
automatically pull the source later. But I'm dreaming too much ahead
here.
> > If we would find this change appealing, it would be better to do it
> > before transition to mercurial, or we will have to rebuild the
> > repository twice. (once for temware -> hg conversion, and once to get
> > rid of unnecessary sources from hg)
>
> If you want to do that, hash it out here and go for it. I am happy
> to just be another consumer of the gate and not involved in this
> transition at all :)
Fair enough. Seeing how can be people unhappy because of onnv transition
should warn me :) But I'm new kid on the block, and I wanted to know the
system better first. Tossing around ideas without knowing the details is
simple ...
> My concerns are failed builds and now having to coordinate two
> putbacks (and that not involving me having to wake up at 3am to copy
> someones tar file :).
Well, with hg you can always return to history, to a non-broken state.
> In that case, ignore my 102 target and go figure out your target :)
Being just few days here on the list, I feel to shy to suggest things.
Would be good to know what we want to achieve. "Make contribution as
easy as possible" might be one goal. What about starting thread 'what
could be better on sfw gate' to get idea about where could we improve
things ?
--
Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/sfwnv-discuss/attachments/20080917/809c7ab8/attachment.bin>
