Hi this thread is intended to organise this move. I will create a dependency list that needs to move in tomorrow afternoon. Would it be possible to meet each other on IRC tomorrow evening, european time? aaron is 7 hours behind germany.
Put your ideas here, how to do it smoothly. the easies way to move the stuff in would be to put all in base. including kernel + modules. will cause probably some issues on ftp installs in setup and kernel installation, which can then be solved with new isos eventually.
well i think the rest will be clear tomorrow evening. thanks for participating, im too tired for more now. greetings tpowa
On 9/13/07, Tobias Powalowski t.powa@gmx.de wrote:
aaron is 7 hours behind germany.
Yeah 7 hour difference here. Ummm let me see, I will be available but at work from... hmmm 14:00-23:00 your time, so I can do what I can. Of course, as usual, I will be home around 24:00 or 1:00 your time, and can do whatever at that time.
Put your ideas here, how to do it smoothly. the easies way to move the stuff in would be to put all in base. including kernel + modules.
I'm not sure if you mean the "base" directory or not, but that could work.
I would say if you want to organize the "troops" everyone grabs a directory and goes at that, so we don't have overlap, but you might have plans for this.
We also need to make sure to remember to move the packages to someone's staging dir, so we can run the db scripts and repopulate the mysql DBs and the repos (this includes /del in current and /add in extra). This is an important one that I could see overlooked.
As for actually moving files via CVS, there are a few options... firstly, we can (possibly) move the raw RCS files from the backend. I have never done this but I think, in theory, it works. Can anyone confirm or deny that?
Moving the RCS files would be the *best* thing to do, but I don't know how practical it is...
will cause probably some issues on ftp installs in setup and kernel installation, which can then be solved with new isos eventually.
Yeah. I thought of this. Our ftp installs will have problems. I don't know the current incarnation of our installer well enough, but what problems will this cause exactly? I was under the assumption that as long as we put the right things in packages.txt everything will work out fine. (I'm probably wrong though).
Friday 14 September 2007, Aaron Griffin wrote: | Yeah. I thought of this. Our ftp installs will have problems. I | don't know the current incarnation of our installer well enough, | but what problems will this cause exactly? I was under the | assumption that as long as we put the right things in packages.txt | everything will work out fine. (I'm probably wrong though).
why not assemble the new [core] without doing any modifications on the [current]? creating a [extra2] that is replacing the extra and then just assemble these two new repos with the contents from the old ones you like. after finishing everything, just update pacman in the old repos to look for the new repos instead the old ones and release a new ISO.
this way, everything will work while you are migrating things and once done, the users can switch to the new repos. the old are dumped after a certain time.
i'm having absolutely no time for arch this weekend, sorry. good luck with the game!
- D
Am Freitag, 14. September 2007 00:50:32 schrieb Damir Perisa:
why not assemble the new [core] without doing any modifications on the [current]? creating a [extra2] that is replacing the extra and then just assemble these two new repos with the contents from the old ones you like. after finishing everything, just update pacman in the old repos to look for the new repos instead the old ones and release a new ISO.
imho that`s they only way to go. Working on a "living" repo is a really bad idea. What happens if we realise that we did something wrong or the creation of core isn`t that easy as expected?
On 9/13/07, Pierre Schmitz pierre@archlinux.de wrote:
Am Freitag, 14. September 2007 00:50:32 schrieb Damir Perisa:
why not assemble the new [core] without doing any modifications on the [current]? creating a [extra2] that is replacing the extra and then just assemble these two new repos with the contents from the old ones you like. after finishing everything, just update pacman in the old repos to look for the new repos instead the old ones and release a new ISO.
imho that`s they only way to go. Working on a "living" repo is a really bad idea. What happens if we realise that we did something wrong or the creation of core isn`t that easy as expected?
+1 especially for the core idea. Is it all that bad if we lose revision history on this stuff anyway (in the sense of moving it to a new cvs repo named core)? It will still be there in the old current repo if really necessary.
-Dan
Am Freitag 14 September 2007 schrieb Aaron Griffin: Hi
Put your ideas here, how to do it smoothly. the easies way to move the stuff in would be to put all in base. including kernel + modules.
I'm not sure if you mean the "base" directory or not, but that could work.
yes that's what i meant.
I would say if you want to organize the "troops" everyone grabs a directory and goes at that, so we don't have overlap, but you might have plans for this.
We also need to make sure to remember to move the packages to someone's staging dir, so we can run the db scripts and repopulate the mysql DBs and the repos (this includes /del in current and /add in extra). This is an important one that I could see overlooked.
yes
As for actually moving files via CVS, there are a few options... firstly, we can (possibly) move the raw RCS files from the backend. I have never done this but I think, in theory, it works. Can anyone confirm or deny that?
this cvs moving just on the main server did also come to my mind yesterday. This is the easiest and safest way (if it works) to still have the history. Sure we should tar the old cvs structure as backup before doing anything, that we can revert stuff easily if something goes wrong. Does anyone have good experience in CVS that can tell us how well this would work?
Moving the RCS files would be the *best* thing to do, but I don't know how practical it is...
Yeah. I thought of this. Our ftp installs will have problems. I don't know the current incarnation of our installer well enough, but what problems will this cause exactly? I was under the assumption that as long as we put the right things in packages.txt everything will work out fine. (I'm probably wrong though).
though i haven'T tried it, i think if modules are in base , they depend on kernel, which will cause the kernel to be installed during package installation. By having the kernel also in "base" it will be shown during package selection. The kernel will be installed twice then, but this could be fixed with a new iso and setup that is adapted to this. Old ftp installs should still work, though. This is only theory how i expect it to happen.
greetings tpowa
Aaron Griffin schrieb:
On 9/13/07, Tobias Powalowski t.powa@gmx.de wrote:
aaron is 7 hours behind germany.
Yeah 7 hour difference here. Ummm let me see, I will be available but at work from... hmmm 14:00-23:00 your time, so I can do what I can. Of course, as usual, I will be home around 24:00 or 1:00 your time, and can do whatever at that time.
I will be leaving around 19:30 and coming back at 24:00 or so (it's Friday, you know).
Put your ideas here, how to do it smoothly. the easies way to move the stuff in would be to put all in base. including kernel + modules.
I'm not sure if you mean the "base" directory or not, but that could work.
No, if we do it, we do it right. I have posted a possible categorization in the other thread, I am not completely pleased (the "support" category should be split again).
I am also in favor of creating a new repository for now instead of working with the existing one. This will give us more time to do it right.
On 9/14/07, Thomas Bächler thomas@archlinux.org wrote:
I am also in favor of creating a new repository for now instead of working with the existing one. This will give us more time to do it right.
I could agree with this - a new repository will help us flesh out categories and things like that.
Can we make sure we're all on the same page here?
Tobais, what time frame were you planning on doing this?
Who all is involved?
What is your current plan of attack?
I just want to make sure we all know the details of what's happening here.
Am Freitag, 14. September 2007 schrieb Aaron Griffin:
On 9/14/07, Thomas Bächler thomas@archlinux.org wrote:
I am also in favor of creating a new repository for now instead of working with the existing one. This will give us more time to do it right.
I could agree with this - a new repository will help us flesh out categories and things like that.
Can we make sure we're all on the same page here?
Tobais, what time frame were you planning on doing this?
Who all is involved?
What is your current plan of attack?
I just want to make sure we all know the details of what's happening here. _______________________________________________ arch-dev-public mailing list arch-dev-public@archlinux.org http://archlinux.org/mailman/listinfo/arch-dev-public
Hi we have core on ftp and also cvs now. all empty.
now we wanted to categorize first the packages and then copy in from the repostiory to new cvs-core.
greetings tpowa
arch-dev-public@lists.archlinux.org