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: [email protected] jabber: [email protected] twitter: magthe http://therning.org/magnus
signature.asc
Description: OpenPGP digital signature
_______________________________________________ arch-haskell mailing list [email protected] http://www.haskell.org/mailman/listinfo/arch-haskell
