Interesting and thoughtful, thanks.
I think we need to file these ideas in the hackage trac. They've been
floating about for a while but we need to get them properly recorded.
On Sun, 2009-01-18 at 01:06 -0500, wren ng thornton wrote:
Minimally these aggregated reports should indicate the
2009/1/18 Duncan Coutts duncan.cou...@worc.ox.ac.uk:
Second, and this would take more work, I would like it if the Haddock
documentation for packages could be given a wiki-like and/or reddit-like
interface so that people could make comments about what is unclear or
needs better documentation
Duncan Coutts wrote:
It may well be tempting to plague maintainers until they fix their
packages however in practise it will not work. We want a low barrier to
entry for packages on hackage and we do not want to annoy package
maintainers to the point where they decide to stop using hackage at
On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote:
Would be nice if after a failed build cabal asked whether or not to
upload its log immediately, and (on the hackage side) this led to an
email being sent to the maintainer.
It should not be quite that synchronous but yes that's the
Well, I thought about these 10's of emails too; probably hackage could
send an email when a new broken build arrives but only if there were
no 'unresolved' broken builds before this one; or probably an email at
the first broken build and a weekly email reminding you've got some
unresolved broken
Duncan Coutts ha scritto:
[...]
Do you know buildbot?
http://buildbot.net/trac
Yeah, it's great for some kinds of projects. For example it's used for
ghc. However it is very centralised, synchronous and needs ssh on
Windows.
What we've implemented is using cabal-install to generate build
On Thu, 2009-01-15 at 12:45 +0100, Manlio Perillo wrote:
Duncan Coutts ha scritto:
[...]
Do you know buildbot?
http://buildbot.net/trac
Yeah, it's great for some kinds of projects. For example it's used for
ghc. However it is very centralised, synchronous and needs ssh on
Windows.
Eugene Kirpichov ha scritto:
Well, I thought about these 10's of emails too; probably hackage could
send an email when a new broken build arrives but only if there were
no 'unresolved' broken builds before this one; or probably an email at
the first broken build and a weekly email reminding
Duncan Coutts ha scritto:
[...]
This seems a good idea.
However, it is possible for a thirdy part user to submit build logs for
a specific platform?
Yes.
Ok, that's great!
In detail:
- The package author submit his package, and additional build logs
for each platform he have access
On Thu, 2009-01-15 at 13:26 +0100, Manlio Perillo wrote:
In detail:
- The package author submit his package, and additional build logs
for each platform he have access to
- Other users can submit additional build logs for their platform
I think, however, that a centralized system
Duncan Coutts wrote:
We want to let random users on random
platforms submit simple anonymous build reports (no logs)...
The only downside compared to a more centralised system is that we do
not get to centrally monitor the status of the dedicated build clients.
And that we open ourselves up
Yitzchak Gale ha scritto:
Duncan Coutts wrote:
We want to let random users on random
platforms submit simple anonymous build reports (no logs)...
The only downside compared to a more centralised system is that we do
not get to centrally monitor the status of the dedicated build clients.
And
On Thu, 2009-01-15 at 14:38 +0200, Yitzchak Gale wrote:
Duncan Coutts wrote:
We want to let random users on random
platforms submit simple anonymous build reports (no logs)...
The only downside compared to a more centralised system is that we do
not get to centrally monitor the status of
Duncan Coutts wrote:
let random users... submit... build reports...
I wrote:
...we open ourselves up to... hostile build reports and DOS.
Manlio Perillo wrote:
DOS is always a problem, for every application open to the Internet.
Yes. But I didn't mean just generic flooding. I meant
abusing
Duncan Coutts duncan.cou...@worc.ox.ac.uk writes:
On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote:
Would be nice if after a failed build cabal asked whether or not to
upload its log immediately, and (on the hackage side) this led to an
email being sent to the maintainer.
It should
Duncan Coutts wrote:
Detailed build reports with logs are not anonymous, clients will need an
account on hackage (ie username and password).
Right. If we experience problems with that in the future,
we just have to make sure that it won't be too hard
to set up captcha.
they'll either be
There's no point wasting development resources on threats that may
never emerge. If attacks become a problem, it can be dealt with then
-- when more information on the nature of the threat is available, so
a better solution can be developed than now (when there is no
information, only
On Thu, 2009-01-15 at 14:25 +0100, Ketil Malde wrote:
Duncan Coutts duncan.cou...@worc.ox.ac.uk writes:
On Thu, 2009-01-15 at 09:49 +0300, Eugene Kirpichov wrote:
Would be nice if after a failed build cabal asked whether or not to
upload its log immediately, and (on the hackage side) this
Duncan Coutts duncan.cou...@worc.ox.ac.uk writes:
Perhaps the maintainer should receive a build summary at regular
intervals? This would also work as a check whether there is a live
maintainer at the other end of the listed maintainer address. (And
hopefully be enough of an annoyance on the
Krzysztof Skrzętnicki wrote:
My experience from using GHC under Windows XP is very similar. Many
packages (especially those involving bindings to C packages) are at
least painful to build.
+1
Also have to love packages that use Unix-specific features as part of
their build process. (I
On Tue, 2009-01-13 at 19:20 +, Andrew Coppin wrote:
I vividle remember Dons repeatedly telling me that I should try out
[some package who's name escapes me], and then discovering that it
doesn't actually work on Windows at all. (Couldn't this critical
information be included somewhere
Duncan Coutts ha scritto:
On Tue, 2009-01-13 at 19:20 +, Andrew Coppin wrote:
I vividle remember Dons repeatedly telling me that I should try out
[some package who's name escapes me], and then discovering that it
doesn't actually work on Windows at all. (Couldn't this critical
On Thu, 2009-01-15 at 00:22 +0100, Manlio Perillo wrote:
Duncan Coutts ha scritto:
On Tue, 2009-01-13 at 19:20 +, Andrew Coppin wrote:
I vividle remember Dons repeatedly telling me that I should try out
[some package who's name escapes me], and then discovering that it
doesn't
Would be nice if after a failed build cabal asked whether or not to
upload its log immediately, and (on the hackage side) this led to an
email being sent to the maintainer.
2009/1/15 Duncan Coutts duncan.cou...@worc.ox.ac.uk:
On Thu, 2009-01-15 at 00:22 +0100, Manlio Perillo wrote:
Duncan
Hi,
Ive seen many times the monad topic coming around on the cafe and plentiful
tutorials on monads have been published. However, as a complete Haskell
newbie coming from OOP, I felt monads were not particularly difficult to
grasp, and very exciting to work with.
During my experiments with
I agree completely. There is not nearly enough documentation on
packaging in haskell and too many hackage packages are broken or do
not install. I know several people are working on improving this but
they seem do be doing so rather quietly. Could someone briefly outline
what improvements are
My experience from using GHC under Windows XP is very similar. Many
packages (especially those involving bindings to C packages) are at
least painful to build.
Regarding encoding package: it compiles fine for me:
C:\Documents and Settings\Methariuscabal install encoding
Resolving dependencies...
Well, the number one thing is to use Cabal and the cabal-install tool.
That is the simplest way to avoid headaches.
Regarding libraries in general, the platform project is underway, aiming
to bless a set of stable, batteries included packages, saving
duplicated work determining which, say, json
What could be done is letting the community rate the quality of the modules
for each platform? Maybe with user comments? Like amazon.com (so we
hackazon.org ;-) And using lambdas instead of stars for giving the rating
:)
On Tue, Jan 13, 2009 at 6:13 PM, Don Stewart d...@galois.com wrote:
Don Stewart wrote:
Well, the number one thing is to use Cabal and the cabal-install tool.
That is the simplest way to avoid headaches.
I'm sure cabal works very well for many people, but for anyone who
has used Debian based distributions for some time, cabal really
does seem like a backward
mle+cl:
Don Stewart wrote:
Well, the number one thing is to use Cabal and the cabal-install tool.
That is the simplest way to avoid headaches.
I'm sure cabal works very well for many people, but for anyone who
has used Debian based distributions for some time, cabal really
does seem
Don Stewart wrote:
mle+cl:
Don Stewart wrote:
Well, the number one thing is to use Cabal and the cabal-install tool.
That is the simplest way to avoid headaches.
I'm sure cabal works very well for many people, but for anyone who
has used Debian based distributions for some time, cabal
On Tue, 2009-01-13 at 16:33 +0100, Regis Saint-Paul wrote:
Hi,
I’ve seen many times the monad topic coming around on the cafe and plentiful
tutorials on monads have been published. However, as a complete Haskell
newbie coming from OOP, I felt monads were not particularly difficult to
On Tue, 2009-01-13 at 16:21 +, Jamie Brandon wrote:
I agree completely. There is not nearly enough documentation on
packaging in haskell and too many hackage packages are broken or do
not install. I know several people are working on improving this but
they seem do be doing so rather
On Tue, 2009-01-13 at 18:43 +0100, Peter Verswyvelen wrote:
What could be done is letting the community rate the quality of the
modules for each platform? Maybe with user comments? Like amazon.com
(so we hackazon.org ;-) And using lambdas instead of stars for giving
the rating :)
On Tue,
35 matches
Mail list logo
