On Fri, Nov 11, 2011 at 10:26:54PM +0100, Nicolas Pouillard wrote:

On Fri, Nov 11, 2011 at 9:42 PM, Magnus Therning wrote: [...]

...

...

Moreover I'm not fond of this kind of race.

Neither am I, but I see no way easy way of addressing that.

A way to quickly sending notices that a change is in progress.

Send it where? To the mailing list?

...

 I'm a strong believer in only pushing changes once they build, and the only way of making sure of that is to make the build.  Building ~50 packages takes quite a while.

Yes but you pushed the x86_64 while the i686 was not fully built.

I recommend the following:

* build one arch * git push * build the other * push both

Good suggestion, I will adopt this. [...]

Currently, there are not much users. And I want this repo to at least suit my needs otherwise I will simply build them for my use. I prefer to have the side effect of being potentially useful for someone else.

Fair enough, but I still ask of you to consider that every package you add will result in longer build times and that affects everyone who works on keeping [haskell] up-to-date.

...

...

So for me we move out broken packages that we cannot quickly fix if they are not much used.

How do we find out if they aren't used?

I don't know. Maybe we can GC with a kind of vote/lease system. Imagine the following use case:

$ cblrepo vote agda haskell-pandoc ...

Which would transitively mark these packages as used (or add a voice to them, or put a timestamp).

$ git commit ; git push

Everyone does the same and then:

$ cblrepo remove `cblrepo unused` $ cblrepo clearvotes

I'm not sure I understand the thinking behind this, but I suspect this would mean that only people with commit access to our habs repo may vote. Or did I get that wrong? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay