On Mon, 29 Sep 2003, [iso-8859-1] Juancarlo Aņez wrote:
> > I suppose you could edit history files, but I really would > > recommend against it. > > I've done repository manipulation (moving files around, basically) before > for what I think are valid reasons. I always do a full backup first. > > In this case, the reason for wanting to manipulate the repository is because > I think that the differencing engine should be split from JRCS. That's > because more people have interest in the engine than in archive > manipulation, and bundling the two libraries makes the engine less visible. People do do this on the apache servers too. Not with wild abandon, but for reasonable reasons it happens. Your shell account has access to do this. Usually the 'community' ought to be checked with before doing such a thing, just for sanities sake, but as you're the only active committer on jrcs you represent the sandboxed community. > After moving the project elsewhere, my plan was to: > > * Split the diff engine from archive manipulation > > * Find a name for the diff engine (JDiff is overloaded) [perjaps > "prefix-diff"?]. > > * Give each subproject its own page and repository. An alternative would be to split the stable bit off and get it to commons proper, but remove the unstable bit back to your own control. > Can that be done here without too much delay or red tape? Depends. If you grokk commons already and know what to do at each step, it's pretty easy to smooth things along. If you've got to bounce into these each time, then it can slog along. Minimum time to get a component into commons proper and released would be about 2 weeks I think. You've got two votes to fit in there [one to commons-proper and one for release]. Biggest stumbling block would be lack of a community blocking the commons-proper vote. > The only thing that should not happen is that the project is made visible > here and somewhere else at the same time. Agreed. > I have already been offered hosting for the project elsewhere. I'm wating > for this discussion to arrive to a conclusion before making a move. The > voting, as I remember, was +2 -1. My own criteria is that uless at least a > couple of committers voluntier to do project maintenance (especially the > admin stuff), I should think that there's not much interest for the project > here, that Jakarta is in fact not endorsing it, and that it makes most sense > to move the project out. Unless you have a community of interested developers [3 or more], I don't think it would make sense to stay here. If JRCS had had public space on the website for the last year, it may have gotten that, but as it didn't [partly due to your lack of time, partly because the website has no centralised management] I don't think it would be fair to you to keep the code sitting in situ for another year while a community builds. Hen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
