At 15:05 Uhr +0100 25.11.2002, David wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
Hello list.
After spending a few weeks with the developers on the #fink IRC channel, evaluating my new role and putting much thought into the structure of fink, I would recommend the following steps which I will gladly assist all of you with.
Suggestions are of course welcome.
Why? The fink "core" members know pretty well who is responsible for what. I don't see why we have to change this at this time by impossing an rather arbitrary distinction between "core" and non-core developers. In the past, some people have changed from being very active to not being much active at all and back a lot. I don't see much to gain by this distinction except added bureaucracy. Currently, the people who have CVS write access form the "core", even though some of them are not really active anymore.1.) Determine who the actual "core" coder are
Feel free to defend your suggestions, please, but don't expect me to just accept them w/o questioning them, esp. since you didn't give reasonable justification in my eyes...
2.) Organise them into a structure (give them email addresses under a unique domain for example)
Why? Seriously.
That probably won't hurt, some people already asked for this, although the motivation for this isn't that high as we already are mirrored by all the SF mirrors. But I agree it won't hurt.3.) Arrange some sort of sponsored server for: a) bindist mirrors
Not sure what you mean... if you are talking about command line tools that ease maintaining the bindist, sure why not. Feel free to write them. Please don't start telling us now "it's all your responsibility to work on this" etc. as it is not. We are a bunch of volunteers, and at least I am currently happy to stay that way, I am not planning to turn this into my single life business.b) extra organisational tools
Another thing that might be worth investigating is signing .debs with GPG keys, but then we have to create an infrastructure to sign them, distribute the signatures, verify the signatures. More importantly, we all would need keys signed by each other, and that's tough - the only way to get that done in a secure fashion is by meeting, and we live spread over the whole world (US, Germany, Japan, and many others).
c) (in my eyes) proper bug tracking
What exactly is lacking in the current bug tracking I wonder?
4.) Align the common helpers into groups,
Err... would you mind to elaborate on what exactly you have in mind here?
organise the documentation efforts
That's what you wanted to work on I gather.
5.) Find a consensus on how to distribute and assess possible localisation efforts.I assume you are talking about the localization of the documentation, and possible the fink tool itself (your suggestion all seem a bit vague to me, but in this case I don't think there are other sensible interpretations).
Well, currently there is no effort done there, mainly because we didn't have the resources to organize and perform such a thing, nor was the desire to do so very big. That said, I wouldn't mind adding localizations. The two main issues there as I see are to put an infra structure into place for it, then get volunteers to do the translations, and more volunteers to check the translations and integrate them into the main fink site. Things like copyright issues may have to be checked etc.
For the fink tool itself, an infrastructure for l10n has to be put into place. For this various Perl modules exist, which we might be able to use. Just need somebody who is good at perl coding who can work on this.
Indeed. Which hurts them, in my eyes. I don't like agreeing to very abstract and vague suggestions, as it means I don't know what I am giving in to - a bit like voting for politicans who make abstract and vague promises, you never know what you'll get (well, it's the same for the others, too, of course <g>). Don't get me wrong, I believe you have only the best intentions, I just want to figure out what exactly they are :-)A lot of the above mentioned points are rather abstract.
Some work on my be-halve has already been invested. I have talked to rand-irc and sent him a mail concerning Server sponsorship, of course I will keep you all posted on this issue.Before we do that, I'd first want to know what exactly we'd gain be it. And if we want it. That's not something only one or two of use should decides (esp. as it might later turn into disappoinment for them if it gets rejected later).
I do not wish to come across as being rude or power hungry, but I like fink more by the day and if there is one thing I am able to do, then it is bringing some structure into chaotic systems. Fink is growing and we better start organising now, if we do not wish to be left with a rather big mess later.Note that Fink has been growing for a long time already. So far it worked well enough. Of course I know that can easily change, and actually I am a friend of structure myself, but I am not agreeing with some of the suggestions you make to achieve it.
For example, I don't believe in pressing more artifical "rank hierarchy" on the volunteer fink developers. I just don't see which purpose it would serve beyond what we already have.
This means that we need to select certain standard procedures, elected maintainers for certain tasks and areas (if not already existent). I wish to distribute the load off Max's shoulders, aligning the special abilities we all have with Fink and the goals we wish to achieve.First off, it's not as if I am bearing all the weight. Dave for example is doing the 0.5.0 bindist and did the 0.4.1 bindist before that. So work is already split between us. Still of course he is doing it alone right now, which isn't that nice...
I agree that it would be good for some things to be more structured, e.g. it would be nice if we could get a new bindist release say every 2 months or so, with clearly specified outlines as to how the release process works. I actually wrote such an outline (albeit in need of improvement) to the list, and Dave and I are more or less trying to follow it when we make bindist releases. These all should be integrated into the policy documentation on the Fink homepage I guess.
But back to the suggestion:to make a bindist, you need willing, trustworthy, reliable and experienced individuals who get their hands dirty to do the work, sacrificing a lot of time for it. Except for the time (that's somebody everybody has to decide for himself), I think we have more people than Dave, Benjamin and me on the team that fit this description, I could easily list some (I won't for now as I don't want to offend anybody by forgetting to list him :-)
It might help if we can get people beyond Dave and me to work on this together, e.g. sharing the building off packages on several machines. But that requires additional tools that don't exist so far if you want to automize it.
Don't think any of the above is new to us. Almost all of the points have been discussed here or on IRC in the past. The problem is, it's easy to suggest these things, it's a different thing to implement them.
I will gladly put a lot of time into this, my main concern right now is getting the documentation a bit up to date,
Great.
Fine by me. May have to find out how/if one can rsync the data from the new location on the SF.net download servers.organising for mirrors
I still don't know what you have in mind, and how it would help us, so I am waiting for you to explain it :-)and some place where we can organise the team better than on sourceforge.
Comments, as per usual, are welcome.
You asked for them, you got them :-) Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
