1.) Organizational Management: Apache has to be the canonical release point for all Apache content. This means that if there is an Apache package in ibiblio that is not placed there via the rsync process, then we should discuss means of getting it back over on Apache. No Apache project now actually requires a ibiblio account to get its content onto ibiblio, they already have apache accounts and can easily do it there. No rouge developers should put Apache content into the ibiblio directory, they should consult with Apache to get it added to our repository which is then rsynced.
2.) Scalability and Workload: Having either "everyone" with a project have an account at ibiblio or send email/jira requests in that have to be "manually" processed is not scalable. The goal behind the Apache rsync is to alleviate also this problem. Apache has a fairly high trust relationship between its developers and with mirroring/rsync already available throughout the world, this is just an extension of that trust relationship.
I think its a great idea to have other organizations who wish to rsync use the script. But this should be a decision within those groups, if you are a member of that groups and you object, you should take it up with that group. The rsync is a management tool to make the repository managers jobs easier.
The goal here is to build a stable and scalable repository of trusted content, not to have a "anarchy" diskspace where you can't trust anyones content. To do this requires stronger "institutional" management of the larger groups like Apache, Codehaus etc. and the proper signing (both md5 and pgp) of artifacts...
With this is mind, Jason, how close are we to having "hierarchical" organization/group directories? My point is that it would be far easier for us to control any overlap in projects if the organizations were isolated into separate directories.
for instance
www.ibiblio.org/maven/apache/<project> www.ibiblio.org/maven/codehaus/<project>
also, is it possible to get virtual host names out of Ibiblio, ie
maven.ibiblio.org/apache/<project> maven.ibiblio.org/codehaus/<project>
Maybe this is something we can really push for version two, before there are too many dependent projects?
-Mark
Vincent Massol wrote:
-----Original Message----- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: 04 May 2004 18:10 To: Maven Developers List Subject: RE: groups syncing to ibiblio
On Tue, 2004-05-04 at 11:48, Vincent Massol wrote:
Why should aspectwerkz artifacts that you place in ibiblio take precedence over what the AspectWerkz developers actually have
moved to
ibiblio?
Whatever is newer should take precedence.
Not if the difference is between the project and third party. We're
only
starting to have the capability to allow projects govern their own artifact deployment to Ibiblio. In the cases where projects have
direct
control we no long have any say. What they deploy rules.
See below
Anyway, here are my 2 reasons:
1/ Simply because otherwise I won't be able to help on this subject.
A
pity I think as I could have helped as I was currently doing (and
I've
done my share of ibiblio uploads).
You don't need to for projects that have direct access, but all the other requests you can still certainly help.
See below
2/ Because if a project jar is released by the project under an open source license I don't see why it matters to get the authorization
from
that project to put it up on ibiblio.
You don't legally, it's a matter of courtesy. If the project has
access
to ibiblio they should dictate what goes into ibiblio and this will be
a
policy I would like to enact. I think it only makes sense that in
cases
where projects have direct access (and this will be case always when automated uploads work) to control what artifacts go into ibiblio.
I believe it's up to them. Why do you want to decide for them? If they say that they want to control it, then it's fine of course and we will let them do it. However, if they do accept our help then I don't see why we couldn't help. And then I don't see what's the problem updating these files from ibiblio directly or through their repo. Provided of course (which is what I was asking) that the synchronization is bidirectional. If that's not possible then all this discussion is moot. I don't know rsync enough to know what's possible or not.
Ideally I agree it would be nice, but when you're in a hurry doing something, it's simply a pain being delayed.
Sure, but with the sync from apache and codehaus the most you have to wait is 4 hours and that interval could shortened if deemed necessary.
I have no idea where this repository is, whether I have the karma,
how
to do it, etc. I don't have the will to check this out for now.
Well, it's board policy and messages have been posted. You cannot be deploying directly to ibiblio.
Anyway, I'm busy on other things so I'm fine if someone wants to
take
charge of this. From now on, I'll be filing JIRA issues like
everyone
else is doing.
Sounds good, shall I remove your account from ibiblio then?
You have misread me. There are 2 aspects related to ibiblio: 1- uploading file there (ie. Doing the action) 2- asking to put file there.
For 2, you just told us that we should no longer do it but rather let someone responsible for that project to do it. Hence my comment, saying that I'll abide by this rule and let them do it. I'll still need to tell them by filing up some JIRA issue.
For 1, I simply don't have time right now to dig further on how to do it from apache repo or from the codehaus one. I'm off for a week leaving tomorrow morning to TSSS2004. Thus I'm letting others do it for now. It doesn't mean that I won't do it in the future once I get time to read up/understand how to do it. Just not now.
That said, if you're in a hurry to remove my account on ibiblio, please go ahead. I have no problem. If you want to be alone uploading files, it's all yours :-)
[snip]
Thanks -Vincent
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
