[arch-dev-public] Core Issue in Multiple Architecture
So here's what I see as the most important counterfactor to Arch growing comfortably into a multi-architecture distro: HOW do we make it easy for OLD devs to TEST easily on MULTIPLE platforms? Building we have covered, at least in the long term. But time has shown that deploying packages without proper testing is not smart. This means (I think) at LEAST installing the package and running at least one program that is part of the package; for some packages, I know I put them up on one of my servers and let them run for a few days before pushing them to [extra]. So the next time I build the next release of dovecot, how can we make it easy for me to test it? So far, I see no good solution. What doesn't seem fair is to expect the devs who signed on with x hours of time to give per week to maintaining i686 packages to maintain packages on other architectures if it will require: 1) more hardware purchases 2) significantly more time Remember, we're all here scratching our own itches. I agree that the idea of multiple architectures is a nice one, but if I have to put in 2x hours per week maintaining packages when I already can barely find the x hours per week I need to maintain the ones I have, it's just not possible for me to take this on. So I see two solutions: 1) See if more developers come along for other architectures. This isn't something we can "make" happen, unless someone's got a rich uncle who's willing to pay them! We should make it clear we're looking for help, and if people want to help, they'll come. 2) Reduce that 2x to something smaller. This *is* something within our control.. we can try to solve the technical problems which currently make it hard to develop for multiple architectures. This is meant as a starting point for further discussion, and also a means of conveying, for instance, why I haven't started building for x86_64. I'm not even running an x86_64 box, even though most of my computers are Athlon64s. Since I have to choose between developing and testing on one or the other, the barrier is very high. Let's try to make it lower. - P
So I see two solutions:
1) See if more developers come along for other architectures. This isn't something we can "make" happen, unless someone's got a rich uncle who's willing to pay them! We should make it clear we're looking for help, and if people want to help, they'll come.
2) Reduce that 2x to something smaller. This *is* something within our control.. we can try to solve the technical problems which currently make it hard to develop for multiple architectures.
This is meant as a starting point for further discussion, and also a means of conveying, for instance, why I haven't started building for x86_64. I'm not even running an x86_64 box, even though most of my computers are Athlon64s. Since I have to choose between developing and testing on one or the other, the barrier is very high. Let's try to make it lower.
I see a potential third option. That is.. Separate the x86_64 branch into its own support structure, effectively creating a sister distribution. They would manage pkgbuilds for that architecture, again separate from i686. Still provide infrastructure, but maybe make them a bit more self operating. More like providing a 'project' status to it, than making it part of mainline. When that branch reaches enough critical mass, and has enough support devs, *then* merge it into more of a single umbrella distribution. At that point, the supporting tools and underlying workflow *should* be more capable of dealing with needs. My fear is that the x86_64 branch may have been brought on board before there was sufficient infrastructure and support for it in the core distribution. I am still new here though, so maybe this is just me not seeing all the pieces. Certainly correct any of my erroneous assumptions.
On Wed, 9 May 2007 16:32:12 -0700 (PDT) eliott@cactuswax.net wrote:
I see a potential third option. That is.. Separate the x86_64 branch into its own support structure, effectively creating a sister distribution. They would manage pkgbuilds for that architecture, again separate from i686.
Still provide infrastructure, but maybe make them a bit more self operating. More like providing a 'project' status to it, than making it part of mainline. When that branch reaches enough critical mass, and has enough support devs, *then* merge it into more of a single umbrella distribution. At that point, the supporting tools and underlying workflow *should* be more capable of dealing with needs. My fear is that the x86_64 branch may have been brought on board before there was sufficient infrastructure and support for it in the core distribution.
We can imagine that this could work. But then it must be totally seperated from the i686, even from the goals. Daniel
eliott@cactuswax.net wrote:
I see a potential third option. That is.. Separate the x86_64 branch into its own support structure, effectively creating a sister distribution. They would manage pkgbuilds for that architecture, again separate from i686.
Still provide infrastructure, but maybe make them a bit more self operating. More like providing a 'project' status to it, than making it part of mainline. When that branch reaches enough critical mass, and has enough support devs, *then* merge it into more of a single umbrella distribution. At that point, the supporting tools and underlying workflow *should* be more capable of dealing with needs. My fear is that the x86_64 branch may have been brought on board before there was sufficient infrastructure and support for it in the core distribution.
Agreed, this is a third option. The downsides are: 1) The i686 and x86_64 can go far afield. Essentially it can become two separate distros without some system for syncing up. 2) The x86_64 fork can't easily capitalize on much of the existing duplicative i686 developer work. 3) Eventually i686 will die. There will be no migration path for the core distribution. I suppose all those devs at that time can just jump over to the x86_64 project. But I would prefer a smoother migration. So yes, this is a viable option, but it potentially requires the most overall manpower of any of the solutions. - P
participants (3)
-
Daniel Isenmann
-
eliott＠cactuswax.net
-
Paul Mattal