<div class="gmail_quote">Hi Magnus,</div><div class="gmail_quote"><br></div><div class="gmail_quote">sorry for my late answer on this and for my bad English... I'll try to be more clear.</div><div class="gmail_quote"><br>
</div><div class="gmail_quote">IMHO, the ArchHaskell project should be a very big repository with most up-to-date packages from hackage. Now, it seems to me that you are doing all the work, so it's not possible for this project to grow (actually you proposed to drop some packages!). It seems to me that the method you're adopting doesn't allow a real help from others: some times ago I try to help, run some update in cblrepo, build all the updates and pushed the changed cblrepo.db file to you. I assume that you had to build all packages again. And this is a waste of time.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">My idea is to use cblrepo in another way: now cblrepo.db file has about 300 packages. We should split this file in 4 or 5 groups of packages, 1 group (the main one) with common, more basic packages and the others divided by category (for example: net, dev, etc.). We should group the packages, so that one group has dependencies only in itself or in main group. So let's say, for instance, that you work on the main package and I take the network. I will create a cblrepo db that <i>depends</i> on your: if there are updates in the network, I'll do the updates, and send to you (or upload to the server) the resulting packages; when there are changes in the main you'll do your job, and I will bump packages that depends on the ones updated by you. If I understand well, that's the way you deal with DistroPkgs.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">So my cblrepo db will include packages belonging to your cblrepo as <i>DistroPkg</i>. This will share the long compiling work between us. The downside is that we <i>must</i> be in sync: you have to tell me witch package you are updating and I can't wait long before update, or packages will be broken. I would take the risk, anyway, there are already broken packages, but that's depends on another problem, I will discuss this on the proper thread...</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">A script should automate the process of finding, inserting and compiling updates, i.e. should wrap cblrepo into something more easy. I'm working on this.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">Bye,</div><div class="gmail_quote">Fabio</div><div class="gmail_quote"><br></div><div class="gmail_quote">2011/11/14 Magnus Therning <span dir="ltr"><<a href="mailto:magnus@therning.org" target="_blank">magnus@therning.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>> why should we drop packages? Unless we are running out of space on the<br>
> repository server we shouldn't. So I think we should find a solution to<br>
> decentralize the building process. So a build server could be okay. Is it a<br>
> problem to have a maintainer that check some packages, and not everything?<br>
<br>
</div>Sure, we could use a build server. There's a standing request for<br>
anyone to step up with an offer of a system that we can use. Ideally<br>
with a web interface so we can submit source packages, together with a<br>
build list, and then just check in to get the results later on. In the<br>
meantime however, we're stuck with building things on whatever systems<br>
we have access to.<br>
<br>
I'm not sure I understand your question about maintainers, but I'll<br>
take a stab at answering anyway. Let me know if I got you all wrong :)<br></blockquote><div><br></div><div>Sorry. I'll try to improve my English! :-)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hackage moves very quickly, and it's very common that updating a<br>
single package requires that a few others are updated as well. Due to<br>
the nature of the code that GHC spits out we also need to bump the<br>
release of all packages that depend on an updated package. The end<br>
result is that it's very rare that I can update a single package, and<br>
I don't I've ever been able to build just a single package due to an<br>
update. Given this I don't see much value in having maintainers for<br>
subsets of ArchHaskell.<br>
<div><br>
> The main maintainer should only put everything together, maybe periodically,<br>
> so the others know when to submit updates and when to wait for the next one.<br>
> Are you sure this will be more painful than build everything by your own on<br>
> your laptop?<br>
<br>
</div>I don't understand what you mean here, would you mind giving an example?<br>
<div><div></div><div><br>
/M<br>
<br>
--<br>
Magnus Therning OpenPGP: 0xAB4DFBA4<br>
email: <a href="mailto:magnus@therning.org" target="_blank">magnus@therning.org</a> jabber: <a href="mailto:magnus@therning.org" target="_blank">magnus@therning.org</a><br>
twitter: magthe <a href="http://therning.org/magnus" target="_blank">http://therning.org/magnus</a><br>
</div></div></blockquote></div>