On 07/01/11 18:47, Peter Simons wrote:
Hi guys,
[...]
Now, based on my experience from maintaining 5% of Hackage, I've arrived at the conclusion that our tools and our procedures are quite inadequate to get the job done. Maintaining 118 packages in an orderly fashion has been really difficult. I wouldn't dream of even trying to maintain 2500+ packages that way. The most significant problems I've encountered are:
1) A lack of coordination. We have made a couple of attempts to define policies, procedures, and responsibilities for this project, but ultimately we never really got anywhere. The net result is that everyone of us is working on whatever interests him, but the others mostly don't even know about it. Consequently, we are inefficient.
This is true to a large extent. What do you feel is left to define? But bear in mind that this is an effort by volunteers, especially "responsibilities" are always tricky in such projects.
For instance, we develop patches for the ArchLinux library, and when they're ready, we throw them away, because we realize way too late that we don't like what they do.
I don't think this is that common in FOSS when people work on their own without telling people what they are doing.
Similarly, we perform updates in [extra], and then we revert them again, because we notice way too late that they break someone else's efforts.
I can only agree on this point, and I'm not sure what can be done to fix it, if anything
It feels like most of the things we've accomplished were being accomplished though individual machismo, rather than through a coordinated team effort.
2) Lack of communication. In my experience, it's incredible hard to get
[...] This is again about [extra], I can only say I wish it were better, but I can't personally do much about it.
3) Inadequate tools. The cabal2arch utility is a great, but in its current shape it cannot re-generate the habs in a fashion that I'd call "automatic". For some packages, such as OpenGL or GLUT, the cabal2arch output is outright broken and doesn't compile. For other packages, such as cabal2arch itself, the generated PKGBUILD compiles but is incorrect anyway, because run-time dependencies are declared as being build-time dependencies. There are several other packages that cannot be generated with cabal2arch, such as haskell-platform, and that need manual editing before they can be published. So far, we have been addressing these problems in a way that feels "ad hoc", to put it mildly. Being a professional software engineer, that makes me quite uncomfortable, because I have the impression that we don't fully understand what it is that we're trying to do.
This is why I say that your experience is invaluable. Have you raised bugs for the individual issues here, so that we have them documented in a central place? Please provide info of HOW things are broken, i.e. current behaviour and correct behaviour.
Furthermore, we seem to have no functioning tools that help us automate the updating process. My experience so far is that even the tiniest trivial update has a significant potential to break the build of dozens of other packages. Basically, there seem to be trivial updates in Haskell land. Whenever such breakage occurs, there is no easy way to figure out how to remedy the version conflicts. Doing that manually is quite an effort when 118 packages ought to compile, but remedying those conflicts manually for 2500+ packages is not going to be possible.
What process are you using? Both when adding completely new packages and when puling in a new version of a package. What tools are you currently using? What actions are manual, and what actions are only partially covered by tools? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus