-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Montag, November 25, 2002, at 04:16 Uhr, Max Horn wrote: <snip>
I do not feel the need to "defend" anything, because I really do notWhy? The fink "core" members know pretty well who is responsible for1.) Determine who the actual "core" coder are
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.
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...
see an attack in your course of argumentation. To me Fink is not
transparent. You as Max might know who the core coders are, what they
do and where they live. I, as a new user, member, call it whatever you
want, don't. This discourages some people a great deal, because they do
not feel, that they know where to go or whom to contact when things
really break down, nor do they feel, that there is a solid foundation
tot he project.
I merely say, that it would be smart to put up a little list of the
"core" coders, be the active or not. Set up a little profile of them,
what they do and where they are from, make them seem a bit more human,
transparent and friendly . Maybe Core is the wrong word, I simply took
it from KDE.
Determining does not mean, not in my eyes, that you say, "you are in,
you are out", I am simply trying to find out who it is.
Because It will make my work a lot easier. We have over 72 languages2.) Organise them into a structure (give them email addresses under a
unique domain for example)
Why? Seriously.
with more than 2500 different translators world wide in KDE. The
hierarchical structure of the KDE domains and the fact that every of
those is reachable via some sort of @kde.org address simply makes life
easier to those who need to bother with setting up organisational
structures. Furthermore it creates a unique picture. When I look at KDE
docu I see [EMAIL PROTECTED] , [EMAIL PROTECTED] , [EMAIL PROTECTED] and not [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Well I do not feel, that the sf mirrors are the one and only solution.That probably won't hurt, some people already asked for this, although3.) Arrange some sort of sponsored server for: a) bindist mirrors
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.
There is no Austrian mirror for example and I really would appreciate
that. I will look into the matter, I am sure, that I can arrange
something via the mirror system that is allready established for KDE
I never said, that this is your sole responsibility, yet, as I saidNot sure what you mean... if you are talking about command line toolsb) extra organisational 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.
before, I am not going to write the documentation for packages you
create or new functions you implement, that is your task, not mine. I
doubt, that it is necessary discussing this, because it either gets
done or not and I am happy with both solutions.
I am talking about web based team building applications, where ideas,
tasks, dates and the like can be shared, much like irc, just not real
time. That is merely an idea and if you do not want this, well then not.
Another thing that might be worth investigating is signing .debs withSigning packages is surely and idea, a very interesting one too, yet it
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).
is not that hard to have our keys signed if we can agree on a legal
entity. If we all agree that a lawyer somewhere in the country acts as
trust middler. The lawyer receives copies of our personal documents
along with a copy of the gpg key. The Lawyer then has to verify the
authenticity of the sender and as the guarantor he assumes
responsibility for the accuracy of statement.
We have done this for some of our business partners as they live in the
last corners of the world and wanted to avoid flying in to get their
keys signed.
I dislike the interface and I dislike that I do not seem to have thec) (in my eyes) proper bug trackingWhat exactly is lacking in the current bug tracking I wonder?
ability to report proper feedback through emails once the bug has been
opened. But as I said, you have to be happy with it, not me. It was
merely a suggestion.
Dave already mentioned it. People with a common interest who areErr... would you mind to elaborate on what exactly you have in mind4.) Align the common helpers into groups,
here?
specialised on keeping a part of Fink working. Such as request tracker
reviewers, package testers, translators, proofreaders etc.
Come all with the package, right now there is not much to organise butorganise the documentation effortsThat's what you wanted to work on I gather.
to find my way through to those who are willing to contribute to the
effort.
5.) Find a consensus on how to distribute and assess possibleI assume you are talking about the localization of the documentation,
localisation efforts.
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).
yes
Well, currently there is no effort done there, mainly because weAs long as the fink documentation is released under an open License,
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.
such as GFDL there should be no issues with copyright. The translator
basically signs his location over to us due to its nature. It is a
derivative work of a GFDL'd document.
For the fink tool itself, an infrastructure for l10n has to be putI know someone who might be interested, he works at our company (Marcel
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.
Grünauer).
See, I am too old and spent too much time with management, I tend toIndeed. Which hurts them, in my eyes. I don't like agreeing to veryA lot of the above mentioned points are rather abstract.
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 :-)
lose the precise edge you coders tend to have and I used to have. Since
those arguments above were meant to poke the stick into the honey comb
I guess I got exactly what I anticipated. I wanted to get feedback,
your feelings thrown back at me and it worked, for that I am very
thankful, now I am more than happy to explain in more detail.
<snip>
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 agree, if I did not, I'd simply do something without consent.
<snip>
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.
That#s why we are discussing it ;)
For example, I don't believe in pressing more artifical "rankI never talked about rank, I talked about an organisational structure
hierarchy" on the volunteer fink developers. I just don't see which
purpose it would serve beyond what we already have.
and as great open source and the idea might be, every autonomous system
needs to have some soft of order or hierarchy to it. I am sure we
could quote thermodynamic as much as biological phenomenon to back
this up. I do not think us humans and the systems we create get around
it. It is merely a measure of how to implement it.
<snip>Fine, if you still have the document, please send it to me, if not,
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.
then I will get it off the list hierarchy. If you tell me the topic I
shall most likely find it.
But back to the suggestion:to make a bindist, you need willing,I agree. I do not really know what steps it takes to make a bindist
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 :-)
yet, but I will surely be one of those who'd be willing to help
It might help if we can get people beyond Dave and me to work on thisAlright, definitely something to look into then, especially for me,
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.
there are various G4 standing around here at work doing nothing but
burning power at night. They could easily help building packages.
I do not think it is something new. I spent much time in and on open
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.
source and I think I have a pretty good grasping of the "typical"
organisational issues most projects face. I think, after writing this
much, you understand that I really want to implement it.
Fine by me. May have to find out how/if one can rsync the data from<snip>
the new location on the SF.net download servers.
I will try to get on that issue as son as possible.
See my above post. I simply find, that it would be helpful if we could
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 :-)
virtualise said "user groups" into a system that allows them to
interact and allows me as maintainer to assign tasks to them. Much like
a request tracker with closed groups.
Comments, as per usual, are welcome.You asked for them, you got them :-)
I appreciate it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin)
iD8DBQE94kiFiW/Ta/pxHPQRA9hqAKDCLc7o195E4F12WcqgK6pdv4HA9wCgwQEf P2F+PAV48x9u2vrg7p8OXv0= =5WQN -----END PGP SIGNATURE----- ------------------------------------------------------- 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
