Vladimir Marek wrote:
>>> Will we continue to keep the source tarballs in the gate, or will they be
>>> external? I know that mercurial has had performance problems with large
>>> binary blobs in the past; I don't know if they've been solved.
>> My plan is to transition as-is which yes, means keep the source tarballs
>> in the gate. I actually like that as I don't like having the build
>> possibly fail in the middle because it can't download something.
>
> If this is the only concern, we can very easily do some checksum over
> the downloaded files before trying to build them. The checksum would be
> stored in the workspace itself.
I was assuming that whatever downloaded the files would fail if the
download was incomplete, though I hadn't thought they might be corrupt.
So yes I suppose that is an additional concern.
>
Ideal would be if every product would
> download it's sources prior to compilation,
that was what I had it doing.
> but as a first step we could
> provide script which would download and verify all necessary sources.
That (or a 'make populate' target) is probably needed anyway for someone
who might want to setup their workspace when they have a fast network
connection but build later when disconnected - wouldn't
want it to fail then. And for critical build milestones the option
to be completely disconnected from the network and have the build
succeed is needed.
> In
> the future it would allow us to simply build only relevant products (for
> building gtar you would not have to download and compile gtk libraries
> for example).
well true, with teamware we do have that via partial bringovers. We
don't have that with hg but I wasn't yet worried about that (and it's
only the disk space, you don't have to build the gtk libraries _now_
if you just want to build gtar. Now if you're talking about being
able to run nightly and only have it build gtar, well that's not
what I'm thinking of since nightly's audits will be kinda pointless
without a fully built workspace).
> a) new repository will not be related to old one, so if someone has
> some local changes to his clone, hg would not be able to merge his
> changes automatically.
It doesn't seem to me that there's a lot of intersection between
people changing the same files in sfw compared to say, ON, except
in a very few places like {pkgdefs,lib,cmd}/Makefile, and Targetdirs.
Well unless I'm around but I could stop changing things :)
Which aren't that hard to merge, and we could if necessary change it so
you are less likely to have to touch those files.
So I wasn't really worried about that though perhaps it's a larger
issue than I thought.
> b) we would either loose history during the transition, or we would have
> to use the 'convert' extension and handpick every 'old' source. (granted
> it could be scripted to some degree)
but the history would already be in the old repository. It seems just
like having to look through the various release gates to me, so again
perhaps I'm too close and this is a larger issue than I believe.
>> If there are issues doing it this way then I am quite open to not doing
>> this transition now and allowing others to do it, so feel free :) I'm
>> just feeling pressure on this so thought I'd give it a shot, but I'm
>> not in a hurry there are bugs to fix as well.
>
> Where is the pressure coming from ?
every few days I get 'Mike, when are you transitioning sfw to hg? What
build can I put down?' From upper management (internally of course).
> If it's because we want to give
> community the possibility to contribute, we should first create proper
> tools for it first. I can hardly imagine 1G of sources just to bump up
> gtar revision ...
If that's what you're envisioning you may be arguing for something
else, like breaking up the workspace into smaller chunks. Which perhaps
might be good, or perhaps not (I tend to like being able to build it
all and run the audits but if the tools were changed that could be
done with a meta-nightly too). And I understand the build time and space
concerns, but please remember I'm old and come from the days when
gatekeepers were forever having to yell at people for breaking the
full build because they didn't think they had to do one :) Even for
things like gtar, where you might not think it's worth doing even one
full build, I'd say that yeah it might not catch anything you wouldn't
catch building just gtar by hand (or it may actually find some things
you forgot to package) but if nothing else it will run gtar a lot and
help your testing :)
> I would be happy to help. But first it would be good IMO to define what
> is our goal.
My goal is, as usual, to have people stop yelling at me. But I never
seem to succeed :)
Mike
