On Wed, Oct 25, 2006 at 04:43:05PM +0200, Bas van Dijk wrote:

I think it's wise to also add style guidelines/advice. The Haskell and GHC wikis already have a lot of material on that:

http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions http://haskell.org/haskellwiki/Programming_guidelines http://haskell.org/haskellwiki/Category:Style

They might be reasonable as extra resources, but not as guidance on what a patch ought to look like. The last one is a collection of general advice, with significant disagreements between the authors, while the GHC conventions don't necessarily apply to libraries. It's far more important to follow the conventions of the code you're modifying.

Ross Paterson wrote:

I see you've deleted the bit about silence being taken as consent. I think we need something like this, or at least a presumption that the change will happen unless someone objects

Sometimes silence means "This idea is so crazy and useless that I don't even know where to begin in rebutting it". The lack of any positive response should not lead to an automatic presumption that the idea is OK! Regards, Malcolm

On Wed, 25 Oct 2006, Malcolm Wallace wrote:

Ross Paterson wrote:

...

I see you've deleted the bit about silence being taken as consent. I think we need something like this, or at least a presumption that the change will happen unless someone objects

Sometimes silence means "This idea is so crazy and useless that I don't even know where to begin in rebutting it". The lack of any positive response should not lead to an automatic presumption that the idea is OK!

I agree explicitly. (not only by being quiet :-)

ross:

On Wed, Oct 25, 2006 at 01:26:44PM +0100, Ross Paterson wrote:

...

On Wed, Oct 25, 2006 at 11:58:59AM +1000, Donald Bruce Stewart wrote:

...

After some discussion on the libraries list, I've put up the suggested 'best practice' for proposing library changes, here:

http://haskell.org/haskellwiki/Library_submissions

I see you've deleted the bit about silence being taken as consent. I think we need something like this, or at least a presumption that the change will happen unless someone objects, to encourage a discussion, and to help focus the discussion.

Actually, I think this is essential to improving the process. As it is, that page lists lots of extra work for the proposer, but gives nothing in return. After they do all that work, they're in the same situation they are now: if the proposal doesn't get a chorus of approval, it's left in limbo, with no indication of why. If we really do want to encourage submissions, we need balancing obligations on reviewers, and this is the simplest, most flexible way to achieve them.

Yes, given the extra, work, the obligation should be on the libraries hackers to review and note any objections. The extra burden on the proposer to actually craft a patch and produce the code, will rule out crazy ideas, I suspect. So silence == consent makes sense, and should work I think, under our more rigorous submission process. -- Don P.S. Now if Haskell' had the same requirement, that any submission must come with a GHC, Hugs or Yhc patch to implement said proposal we'd be in great shape...

ross:

On Wed, Oct 25, 2006 at 11:58:59AM +1000, Donald Bruce Stewart wrote:

...

After some discussion on the libraries list, I've put up the suggested 'best practice' for proposing library changes, here:

http://haskell.org/haskellwiki/Library_submissions

The idea is to reduce the number of 'bikeshed' discussions we're having, ensure that submissions are not dropped, and generally improve productivity.

People should refer to this when proposing new functions for the core libraries, at risk of not having the suggestion adopted or considered ;)

Perhaps it would be kinder to the mail system to suggest attaching the patch to the ticket instead of mailing it. These patches to base are quite big, and are causing trouble.

Good idea. So instead of 'darcs send', we'd use the Trac system to send a combined proposal and patch?

And if we could get the ticket mail sent to libraries instead of ghc-users, that would make the procedure simpler, too.

Ah yes. Igloo or SimonM, do you admin trac? For the time being I've increased the libraries@ limit to 250k, inline with that for ghc-cvs and cvs-all@. -- Don

ross:

On Tue, Oct 31, 2006 at 07:58:26PM +1100, Donald Bruce Stewart wrote:

...

ross:

...

Perhaps it would be kinder to the mail system to suggest attaching the patch to the ticket instead of mailing it. These patches to base are quite big, and are causing trouble.

Good idea.

So instead of 'darcs send', we'd use the Trac system to send a combined proposal and patch?

Trac doesn't put file attachments in the emails, and that's probably what we want. Instead of hundreds of copies of the 50k patch, it's on the web for those who are interested. (And it becomes part of the record, too.)

The current procedure, where you have to create the ticket before you darcs record, so you'll have a ticket number to put in the patch, is quite cumbersome.

Agreed. Can you update the submission guide? I'll pester Igloo to redirect libraries tickets to libraries@ -- Don

Ross Paterson wrote:

On Tue, Oct 31, 2006 at 08:09:58PM +1100, Donald Bruce Stewart wrote:

...

I'll pester Igloo to redirect libraries tickets to libraries@

The mailing address seems to be a global setting. Perhaps we could achieve it by enrolling libraries as a user on the GHC Trac system, and adding that user as a cc on all these tickets.

Good idea - did anyone do this yet? Simon

Hello Donald, Tuesday, October 31, 2006, 11:58:26 AM, you wrote:

For the time being I've increased the libraries@ limit to 250k, inline with that for ghc-cvs and cvs-all@.

can someone please explain me why we can't optimize dsarcs repositories to make these ptaches a lot smaller. afaiu darcs system, we need just to "tag" current state of repository and all subsequent patches will be based on this tag instead of back-to-jan2006 whole history. the same applies to ghc repository, where history now is about 200k long! -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Samuel Bronson wrote:

On 10/31/06, Bulat Ziganshin wrote:

...

Hello Donald,

Tuesday, October 31, 2006, 11:58:26 AM, you wrote:

...

For the time being I've increased the libraries@ limit to 250k, inline with that for ghc-cvs and cvs-all@.

can someone please explain me why we can't optimize dsarcs repositories to make these ptaches a lot smaller. afaiu darcs system, we need just to "tag" current state of repository and all subsequent patches will be based on this tag instead of back-to-jan2006 whole history.

the same applies to ghc repository, where history now is about 200k long!

Well, you have to do it to your local repo, too. And if it is a --partial one, good luck! I can't even get --partial to grab me an older checkpoint properly :-(. Nevermind trying to reproduce the bug as simply as possible...

Both Igloo and I have seen strange behaviour w.r.t. partial repositories with GHC. In my case, I find it hard to decide what is really a bug. Igloo said he'd try to reproduce a buggy case on a smaller repository, but we're keeping him too busy with GHC :-) If anyone else can help us out here - characterise a bug report for the darcs folk - we'd be very grateful. Cheers, Simon

On 11/9/06, Samuel Bronson wrote:

On 11/7/06, Simon Marlow wrote:

...

Samuel Bronson wrote:

...

...

Well, you have to do it to your local repo, too. And if it is a --partial one, good luck! I can't even get --partial to grab me an older checkpoint properly :-(. Nevermind trying to reproduce the bug as simply as possible...

Both Igloo and I have seen strange behaviour w.r.t. partial repositories with GHC. In my case, I find it hard to decide what is really a bug. Igloo said he'd try to reproduce a buggy case on a smaller repository, but we're keeping him too busy with GHC :-) If anyone else can help us out here - characterise a bug report for the darcs folk - we'd be very grateful.

Personally I was hoping lispy's simulations would turn something up... I already found one bug, but nobody seems to have looked at it yet :-(. But it wasn't the bug I was looking for.

These are not the bugs you are looking for. ;) Some darcs bugs take a very long time to get fixed. If something about darcs bugs you I highly recommend you take a peek at the source code. Especially you Sam. You know enough haskell to send in a patch to GHC, surely you will find darcs grokable. :) As for the darcs user simulator, lispy hasn't written the simulator yet but he only has about 3 weeks left to do it. And when it's written it will be found here (in scala instead of haskell due to a course requirement): http://www.codersbase.com/index.php/DarcsSim Jason