[arch-dev-public] SCM branch plans [was: Killing CVS]
On 10/23/07, Andreas Radke <a.radke@arcor.de> wrote:
Please make sure we will have an easy way to add more "branches" (so i would call them in svn) from trunk. Right now we have the various repos for two architectures. But a few devs have (serious?) plans or better certain ideas to add more branches in the future. Right now our infrastructure and manpower is the limit that prevents playing with more stuff.
I'm a little curious about what plans you speak of. I've never heard of of these plans like this, and it'd be nice to share thoughts and ideas here.
Am Tue, 23 Oct 2007 13:19:01 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
I'm a little curious about what plans you speak of. I've never heard of of these plans like this, and it'd be nice to share thoughts and ideas here.
We all like the ArchLinux rolling release way. That's our big advantage in many ways. But there are situations where many users including me need a system "that just works(TM)". Think off servers, routers, semicorporate usage in bigger setups, your mom's pc far away... Also many open source application projects have reached a state where you are satisfied with the current release and don't need to stay on the risky bleading edge. What distribution would you choose if you still like pacman and the way Arch works(KISS, boot process and so on)? I don't want to be forced to switch to the Frugalware stable release. So the idea to create and maintain a stable tree/port of ArchLinux was born. Several ideas how to do it are possible and have been discussed with some devs from Germany and the one from the Netherlands. We are calling the idea "ArchRock" - the rockstable distribution based on ArchLinux. It's not a hard task but need to be good designed to ensure its quality. While talking about various possible ways to build a stable product we came to the kernel and what we call our core - the gnutools and glibc. The are many inconsistencies in kernel development and what has been collected around. Too often changed abis and unneeded regressions caused by the splitted developement. So another project was born in our mind: a product based in the current FreeBSD 7.x core - managed with pacman. I liked what I have seen there. Pacman 3.0 got ported and was working in most parts. It's always a great challenge to start something new and to be part of it in the early days. Around such a BSD based product we can also imagine a userland based on the ArchLinux packages. Not sure if it would be a rolling release or a stable one depending on the BSD release, also both is possible. Right now it's just for fun but seems to be worth to grow. Ok, now beat me that I've thrown away all the basic rules from former ArchLinux. But hey, it's your fault - the task to define them never got finished :D Andy
On 10/23/07, Andreas Radke <a.radke@arcor.de> wrote:
What distribution would you choose if you still like pacman and the way Arch works(KISS, boot process and so on)? I don't want to be forced to switch to the Frugalware stable release. So the idea to create and maintain a stable tree/port of ArchLinux was born. Several ideas how to do it are possible and have been discussed with some devs from Germany and the one from the Netherlands. We are calling the idea "ArchRock" - the rockstable distribution based on ArchLinux. It's not a hard task but need to be good designed to ensure its quality.
Well. Erm, no offense or anything, but why are you trying to plan Archlinux to support your side project? It's fine and all, but a few things you've said regarding the repo design are assuming you're going to be using gerolde to run your custom distribution as well. I'm not sure if we want to do that. It's already taxed enough as is, and no one seems to be working on fixing that that doesn't already have their hands in 400 other code projects at the same time. I'll make you a deal. You help us with the CPU and IO load on gerolde, and we can look into supporting your project as well. Until then, though, it's just not feasible - too much load on this single machine will make BOTH projects look bad.
While talking about various possible ways to build a stable product we came to the kernel and what we call our core - the gnutools and glibc. The are many inconsistencies in kernel development and what has been collected around. Too often changed abis and unneeded regressions caused by the splitted developement. So another project was born in our mind: a product based in the current FreeBSD 7.x core - managed with pacman. I liked what I have seen there. Pacman 3.0 got ported and was working in most parts. It's always a great challenge to start something new and to be part of it in the early days. Around such a BSD based product we can also imagine a userland based on the ArchLinux packages. Not sure if it would be a rolling release or a stable one depending on the BSD release, also both is possible. Right now it's just for fun but seems to be worth to grow.
The above applies here as well, BUT, I wanted to know where this was being discussed. If pacman was ported to BSD, I've never seen, nor heard of, patches for it. This would be valuable information for us. Not only would it save us work, but Dan is doing this _right now_. Why is this all so cloak and dagger? I think many of us would love to participate in discussions like this, but it seems like it's all behind the scenes and hush-hush. Is there any reason this couldn't be brought up publicly?
Am Tue, 23 Oct 2007 16:03:34 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
Well. Erm, no offense or anything, but why are you trying to plan Archlinux to support your side project? It's fine and all, but a few things you've said regarding the repo design are assuming you're going to be using gerolde to run your custom distribution as well.
Why do you call it a custom distribution or a side project? The intention was to prepare something good in mind we could offer later officially. No serious work has been done so far. Right now I only want to say we should keep the option to maintain something more than what Arch is now. We should have an eye on that when switching away from cvs.
I'll make you a deal. You help us with the CPU and IO load on gerolde, and we can look into supporting your project as well. Until then, though, it's just not feasible - too much load on this single machine will make BOTH projects look bad.
No problem. I think it wouldn't be that hard to get another system sponsored by our community once we can offer one more product they like. Remember the last donation round. For playing like we did it in the past with Arch64 a private server or one of the local community servers (hey greetings to archlinux.de!) should be enough.
The above applies here as well, BUT, I wanted to know where this was being discussed. If pacman was ported to BSD, I've never seen, nor heard of, patches for it. This would be valuable information for us. Not only would it save us work, but Dan is doing this _right now_.
Hm. Jan could menage to compile pacman 3.0.x on a FreeBSD 7.x prerelease within one evening. In our forum was an old thread about a ported pacman 2.x version. We haven't seen any serious attempt on porting pacman over last two years or any other new architecture port. Also afaik no answer to the PackageKit threads from the pacman devs. And we had issues with md5sums calculating always giving segfaults. Why do you want to integrate portability code (that was there in the past) back again if you are unsure to support it? Our work so far seems lost due to Jan's broken notebook. But we were talking to try it again when FreeBSD7 comes into its final testing state where it right now goes.
Why is this all so cloak and dagger? I think many of us would love to participate in discussions like this, but it seems like it's all behind the scenes and hush-hush. Is there any reason this couldn't be brought up publicly?
Most developers seem to be busy with work and only have few time to work on certain Arch projects. These projects grow very slowly. I remember some discussion about the kernel 2.6.16 as a stable alternative in extra. We had more stability related discussions in meetings and mailing list threads in the past. Jan and me were only thinking loud about those project together with some devs at Linuxtag and FrosCon. A few kept working and talking on that from time to time looking for a new task/challenge. Doing massive packaging work for both architectures over a long period I was in the expection to give other devs the freedom to speedup the coding of a good package building architecture. At least something that would take load of us. But nothing important has changed. So it's not the time to discuss another big plus of workload that early. These are just plans for future projects I'd like to see later officially around Arch. Andy
On 10/23/07, Andreas Radke <a.radke@arcor.de> wrote:
Am Tue, 23 Oct 2007 16:03:34 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
Well. Erm, no offense or anything, but why are you trying to plan Archlinux to support your side project? It's fine and all, but a few things you've said regarding the repo design are assuming you're going to be using gerolde to run your custom distribution as well.
Why do you call it a custom distribution or a side project? The intention was to prepare something good in mind we could offer later officially. No serious work has been done so far.
The way I read it, I thought you HAD work done, and WERE working on it, and just wanted to moves things over to gerolde. Either way, I wouldn't feel comfortable just saying "hey lets start supporting this" because one or two devs wanted it. We have a semi-large base now, and decisions that weighty should be decided on by all of us.
Right now I only want to say we should keep the option to maintain something more than what Arch is now. We should have an eye on that when switching away from cvs.
That's fine. Keeping things open for _potential_ is always a good thing, but I read what you said as if you were ready to move forward with things as soon as we switched - it was a timing thing that made me a little scared.
Hm. Jan could menage to compile pacman 3.0.x on a FreeBSD 7.x prerelease within one evening. In our forum was an old thread about a ported pacman 2.x version.
Ah, so it was older. For the record, Dan is doing some work so that pacman 3.X compiles on FreeBSD. If anyone has anything to add to this, please let us know.
Also afaik no answer to the PackageKit threads from the pacman devs.
http://archlinux.org/pipermail/arch/2007-October/015885.html Pacman will not support PackageKit, PackageKit will support ALPM. Right now, I'm unconcerned. It looks like another fad. If the PackageKit devs want our help, all they have to do is contact us. Right now, however, it will not give us ANY benefit, so it would simply raise our workload.
Why do you want to integrate portability code (that was there in the past) back again if you are unsure to support it?
Because pacman is not ArchLinux. What ArchLinux does and what pacman does are two different things. pacman is just a tool that HAPPENS to be used by Arch, but does not define Arch.
Most developers seem to be busy with work and only have few time to work on certain Arch projects. These projects grow very slowly. I remember some discussion about the kernel 2.6.16 as a stable alternative in extra. We had more stability related discussions in meetings and mailing list threads in the past.
Well, keep us informed. There's nothing better one can do than to garner interest in these projects. Nothing more motivating than having other people interested in your ideas and wanting to help. Let us know what you're up to. 8)
Doing massive packaging work for both architectures over a long period I was in the expection to give other devs the freedom to speedup the coding of a good package building architecture. At least something that would take load of us. But nothing important has changed. So it's not the time to discuss another big plus of workload that early.
This is hard. The workload will always be heavy, that's the way this works. I'm going to see what I can do to automate more of these tasks for us, so that rebuilding all these packages isn't as much of a strain as it is now.
Am Tue, 23 Oct 2007 17:21:43 -0500 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
This is hard. The workload will always be heavy, that's the way this works. I'm going to see what I can do to automate more of these tasks for us, so that rebuilding all these packages isn't as much of a strain as it is now.
http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-tools.git;a=tree I wonder how that small group of also busy people can do so many innovative things: build bots, autorebuilder, livecds, a stable tree, graphical tools (we don't want).... Aaron, please have a look at their portpkg script. Maybe you/we can hack something similar together to make dumb architecture rebuilds obsolete. I could offer some build hardware up 24/7. Our repoman is still far away I guess. Andy
On 10/23/07, Andreas Radke <a.radke@arcor.de> wrote:
Aaron, please have a look at their portpkg script. Maybe you/we can hack something similar together to make dumb architecture rebuilds obsolete. I could offer some build hardware up 24/7. Our repoman is still far away I guess.
Why don't you take a stab at it and I can look it over? Why am I the only one coding here?
Wednesday 24 October 2007, Aaron Griffin wrote: | On 10/23/07, Andreas Radke <a.radke@arcor.de> wrote: | > Aaron, please have a look at their portpkg script. Maybe you/we | > can hack something similar together to make dumb architecture | > rebuilds obsolete. I could offer some build hardware up 24/7. | > Our repoman is still far away I guess. | | Why don't you take a stab at it and I can look it over? Why am I | the only one coding here? you know what? you are also the only one leading here. :) ... this however is good to be alone... the other one is not. where are all the other coders? :) - D (only java and php "coder" *fg* ... i wish i would find some time to learn a real language ;) -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On 10/23/07, Damir Perisa <damir.perisa@solnet.ch> wrote:
Wednesday 24 October 2007, Aaron Griffin wrote: | On 10/23/07, Andreas Radke <a.radke@arcor.de> wrote: | > Aaron, please have a look at their portpkg script. Maybe you/we | > can hack something similar together to make dumb architecture | > rebuilds obsolete. I could offer some build hardware up 24/7. | > Our repoman is still far away I guess. | | Why don't you take a stab at it and I can look it over? Why am I | the only one coding here?
you know what? you are also the only one leading here. :) ... this however is good to be alone... the other one is not. where are all the other coders? :)
Don't forget Dan and Thomas. They do a lot as well.
Wednesday 24 October 2007, Aaron Griffin wrote: | On 10/23/07, Damir Perisa <damir.perisa@solnet.ch> wrote: | > Wednesday 24 October 2007, Aaron Griffin wrote: | > | On 10/23/07, Andreas Radke <a.radke@arcor.de> wrote: | > | > Aaron, please have a look at their portpkg script. Maybe | > | > you/we can hack something similar together to make dumb | > | > architecture rebuilds obsolete. I could offer some build | > | > hardware up 24/7. Our repoman is still far away I guess. | > | | > | Why don't you take a stab at it and I can look it over? Why | > | am I the only one coding here? | > | > you know what? you are also the only one leading here. :) ... | > this however is good to be alone... the other one is not. where | > are all the other coders? :) | | Don't forget Dan and Thomas. They do a lot as well. hey guys... show what you do! (how else can we praise you?) :) ... why not announce what you did in a summary for the weekly SR? - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
On 10/23/07, Andreas Radke <a.radke@arcor.de> wrote:
http://git.frugalware.org/gitweb/gitweb.cgi?p=pacman-tools.git;a=tree
I wonder how that small group of also busy people can do so many innovative things: build bots, autorebuilder, livecds, a stable tree, graphical tools (we don't want)....
They have people who write code.
participants (3)
-
Aaron Griffin
-
Andreas Radke
-
Damir Perisa