[arch-dev-public] we want to give x86_64 a new direction
after beeing an official port as a 100% i686 clone with a common cvs we have seen that we can handle the workload with only 2 man in not a bad way but with tons of hours of rebuilding and uploading the packages. but we don't want that anymore. it's simply too much workload and a task we are tired to do. bringing on new packagers is harder than expected. repo cleanups and a possible not to far away start of pacbuild/repoman will not drop down the workload we would need. i686 devs are not able to handle 32bit stuff very well so i don't count on crossbuilds anymore. that's one reason. the other one is beeing an i686 clone depending on its (not well defined) goals makes me sick. i miss any freedom in my work. at least the poor i686 testing procedure is something i don't want to follow anymore. i got more and more afraid how chaotic the developement is going on whithout the possebility to change it. now i see things start changing what is very good. but it seems most devs want to keep i686 the compromise of beeing bleading edge + at least some stability. i haved proved to build a system almost from scratch to the quality we now have. we are no more behind i686. a big part of that goes to the i686 devs and their most times simple and working packages and the easiness to port them. the Arch tools are great. but my personal goals have changed. together with Daniel we have found a few people that would support us if can go our own way. We have worked out some initial goals: - we want Arch x86_64 the more conservative sister distribution of Arch - less bleading edge - still a rolling system with up to date packages - strict rules how packages go through a testing cycle - we expect a significant lower workload due to longer update cycles and less post-release-fixing of broken stuff - only provide a basic core repo by the devs - setup some basic addon repos - open the addon repos to be maintained by the community and reviewed/released by the developers untill community members have proved to do it the same way. that's something where we are not sure where i686 wants to go and if we will adopt it. - it would not be prepared to have an x86 port. but only one x86(i586?) dev would be enough to rebuild that distro with some help by an automated build system. All in all it would be nothing significant different from the port we now have but packages would be more selected and hit the repos later to ensure the improved stability. we want to do this all together with the ArchLinux developers and community. we want to keep using all the great tools and resources Arch already offers. the first step that would need to be done is to splitout our scm. i cannot image to keep working with a common scm. that's what now makes it the clone we don't want to have any longer. if you agree to give us that freedom back, i already have one good candidate for becoming a new x86_64 developer and several community members promised to help out. they all like our goals. at least that we will have some. AndyRTR
Why did you start yet another thead on this? Why not use one of the old ones (I think there were 3) that were on the exact same topic?
On Thu, May 10, 2007 at 08:25:56PM +0200, Andreas Radke wrote:
after beeing an official port as a 100% i686 clone with a common cvs we have seen that we can handle the workload with only 2 man in not a bad way but with tons of hours of rebuilding and uploading the packages. but we don't want that anymore. it's simply too much workload and a task we are tired to do. bringing on new packagers is harder than expected. repo cleanups and a possible not to far away start of pacbuild/repoman will not drop down the workload we would need. i686 devs are not able to handle 32bit stuff very well so i don't count on crossbuilds anymore. that's one reason.
the other one is beeing an i686 clone depending on its (not well defined) goals makes me sick. i miss any freedom in my work. at least the poor i686 testing procedure is something i don't want to follow anymore. i got more and more afraid how chaotic the developement is going on whithout the possebility to change it. now i see things start changing what is very good. but it seems most devs want to keep i686 the compromise of beeing bleading edge + at least some stability.
i haved proved to build a system almost from scratch to the quality we now have. we are no more behind i686. a big part of that goes to the i686 devs and their most times simple and working packages and the easiness to port them. the Arch tools are great.
but my personal goals have changed. together with Daniel we have found a few people that would support us if can go our own way. We have worked out some initial goals:
- we want Arch x86_64 the more conservative sister distribution of Arch - less bleading edge - still a rolling system with up to date packages - strict rules how packages go through a testing cycle - we expect a significant lower workload due to longer update cycles and less post-release-fixing of broken stuff - only provide a basic core repo by the devs - setup some basic addon repos - open the addon repos to be maintained by the community and reviewed/released by the developers untill community members have proved to do it the same way. that's something where we are not sure where i686 wants to go and if we will adopt it.
- it would not be prepared to have an x86 port. but only one x86(i586?) dev would be enough to rebuild that distro with some help by an automated build system.
All in all it would be nothing significant different from the port we now have but packages would be more selected and hit the repos later to ensure the improved stability.
Eventually, this will be the huge difference.
we want to do this all together with the ArchLinux developers and community. we want to keep using all the great tools and resources Arch already offers.
What sorts of things do you want to "do all together"? Do you mean you just want to use the tools? If so, that's fine. Even frugalware does that.
the first step that would need to be done is to splitout our scm. i cannot image to keep working with a common scm. that's what now makes it the clone we don't want to have any longer.
if you agree to give us that freedom back, i already have one good candidate for becoming a new x86_64 developer and several community members promised to help out. they all like our goals. at least that we will have some.
If that's what you want to do, that's fine. No one is going to hold you here doing something you don't want to do. Eventually, with crossbuilding, it would be nice to have our own Arch64 distro following the same patterns, but maybe we're just not ready right now. I don't know what sorts of resources we could offer for you or what you're expecting. It would be better if things were totally separate. I also don't know about the name. If you want to keep calling it Arch64, you're going to have to make it apparent that it's not following Arch Linux anymore. Jason
On Thu, 10 May 2007 12:00:43 -0700 Jason Chu <jason@archlinux.org> wrote:
Eventually, this will be the huge difference.
not in our view. putting in packages later would happen also in the clone way when we 2 packagers would take our ethusiasm back to an usual level. we are just trying to make the best of our resources.
we want to do this all together with the ArchLinux developers and community. we want to keep using all the great tools and resources Arch already offers.
What sorts of things do you want to "do all together"? Do you mean you just want to use the tools? If so, that's fine. Even frugalware does that.
we want to keep it an official ArchLinux port having all the technical resources.
I don't know what sorts of resources we could offer for you or what you're expecting. It would be better if things were totally separate.
why won't you allow us some modifications in the developement process?
I also don't know about the name. If you want to keep calling it Arch64, you're going to have to make it apparent that it's not following Arch Linux anymore.
Jason
sad if you force the port going back to a community project or even a fork. Daniel Pierre
On Thu, May 10, 2007 at 10:36:08PM +0200, Daniel Isenmann wrote:
On Thu, 10 May 2007 12:00:43 -0700 Jason Chu <jason@archlinux.org> wrote:
Eventually, this will be the huge difference.
not in our view. putting in packages later would happen also in the clone way when we 2 packagers would take our ethusiasm back to an usual level. we are just trying to make the best of our resources.
That's fine though. You can do what you need to keep your enthusiasm, but it's going to be much more than just holding back package updates.
we want to do this all together with the ArchLinux developers and community. we want to keep using all the great tools and resources Arch already offers.
What sorts of things do you want to "do all together"? Do you mean you just want to use the tools? If so, that's fine. Even frugalware does that.
we want to keep it an official ArchLinux port having all the technical resources.
Which technical resources are you referring to?
I don't know what sorts of resources we could offer for you or what you're expecting. It would be better if things were totally separate.
why won't you allow us some modifications in the developement process?
The thing is that it'll be in a different tree, with different packages, different developers, etc. What exactly is in common? Where could we technically share anything?
I also don't know about the name. If you want to keep calling it Arch64, you're going to have to make it apparent that it's not following Arch Linux anymore.
Jason
sad if you force the port going back to a community project or even a fork.
I still don't see how it is anything except different. I don't know what sorts of technical resources would be shared but I don't see much in common, except that they're starting with the same set of packages. Jason
maybe the the topic was not the best that you missunderstand it. we don't want to become something completely different. we just want to put the x86_64 port 2-4 weeks behind i686. just too lower our workload that we not have to build all those "damn we have to fix this quickly" packages that hit the stable i686 repos without enough testing. we just want to "abuse" i686 as our testing tree :P and sometimes i want to leave out a few packages of less usage. but this is probably no more needed after the repo cleanup. nothing more. forcing us into the same scm tree makes us a bit unflexible. so i would prefer to have an own tree back again. but i could also imagine to keep one common scm where we just "tag" our versions a bit behind i686. so i don't see a big problem in allowing us these small changes. we don't want to turn arch64 into a completly different distribution. if you are fine with that i want to bring up 2 new packagers as a first step. AndyRTR
On 5/12/07, Andreas Radke <a.radke@arcor.de> wrote:
forcing us into the same scm tree makes us a bit unflexible. so i would prefer to have an own tree back again. but i could also imagine to keep one common scm where we just "tag" our versions a bit behind i686.
I don't see a problem with the updates lagging behind. You guys do have your own CVS tags so it should affect either side. If we tag something 'CURRENT', the db update scripts check only that tag - the 64bit scripts check only 'CURRENT-64' As far as I can tell, we should be able to keep everything exactly as is, and you guys just do your updates slower than us - that's not a big deal to me at all.
if you are fine with that i want to bring up 2 new packagers as a first step.
Sounds good to me.
2007/5/13, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/12/07, Andreas Radke <a.radke@arcor.de> wrote:
forcing us into the same scm tree makes us a bit unflexible. so i would prefer to have an own tree back again. but i could also imagine to keep one common scm where we just "tag" our versions a bit behind i686.
I don't see a problem with the updates lagging behind. You guys do have your own CVS tags so it should affect either side. If we tag something 'CURRENT', the db update scripts check only that tag - the 64bit scripts check only 'CURRENT-64'
As far as I can tell, we should be able to keep everything exactly as is, and you guys just do your updates slower than us - that's not a big deal to me at all.
Hm... The current SVN structure is: /<packagename>/trunk /<packagename>/repos/<reponame> Will slower updates fit this as well? Something like /<packagename>/branches/x86_64 ?
if you are fine with that i want to bring up 2 new packagers as a first step.
Sounds good to me.
sure, it's very good. -- Roman Kyrylych (Роман Кирилич)
On Sun, May 13, 2007 at 01:16:07PM +0300, Roman Kyrylych wrote:
2007/5/13, Aaron Griffin <aaronmgriffin@gmail.com>:
On 5/12/07, Andreas Radke <a.radke@arcor.de> wrote:
forcing us into the same scm tree makes us a bit unflexible. so i would prefer to have an own tree back again. but i could also imagine to keep one common scm where we just "tag" our versions a bit behind i686.
I don't see a problem with the updates lagging behind. You guys do have your own CVS tags so it should affect either side. If we tag something 'CURRENT', the db update scripts check only that tag - the 64bit scripts check only 'CURRENT-64'
As far as I can tell, we should be able to keep everything exactly as is, and you guys just do your updates slower than us - that's not a big deal to me at all.
I'm fine with that, I thought that you guys wanted to start doing a lot more than that. I would like to note that this isn't exactly something that i686 could do. If x86_64 waits for all the bugs from i686 to get cleaned up, i686 wouldn't have anyone to wait for ;)
Hm... The current SVN structure is: /<packagename>/trunk /<packagename>/repos/<reponame> Will slower updates fit this as well? Something like /<packagename>/branches/x86_64 ?
No, all you do is not svnmerge trunk into repos/{current, extra}-64 as often.
if you are fine with that i want to bring up 2 new packagers as a first step.
Sounds good to me.
sure, it's very good.
Yup, sounds fine.
2007/5/10, Andreas Radke <a.radke@arcor.de>:
after beeing an official port as a 100% i686 clone with a common cvs we have seen that we can handle the workload with only 2 man in not a bad way but with tons of hours of rebuilding and uploading the packages. but we don't want that anymore. it's simply too much workload and a task we are tired to do. bringing on new packagers is harder than expected. repo cleanups and a possible not to far away start of pacbuild/repoman will not drop down the workload we would need. i686 devs are not able to handle 32bit stuff very well so i don't count on crossbuilds anymore. that's one reason.
the other one is beeing an i686 clone depending on its (not well defined) goals makes me sick. i miss any freedom in my work. at least the poor i686 testing procedure is something i don't want to follow anymore. i got more and more afraid how chaotic the developement is going on whithout the possebility to change it. now i see things start changing what is very good. but it seems most devs want to keep i686 the compromise of beeing bleading edge + at least some stability.
i haved proved to build a system almost from scratch to the quality we now have. we are no more behind i686. a big part of that goes to the i686 devs and their most times simple and working packages and the easiness to port them. the Arch tools are great.
but my personal goals have changed. together with Daniel we have found a few people that would support us if can go our own way. We have worked out some initial goals:
- we want Arch x86_64 the more conservative sister distribution of Arch - less bleading edge - still a rolling system with up to date packages - strict rules how packages go through a testing cycle - we expect a significant lower workload due to longer update cycles and less post-release-fixing of broken stuff - only provide a basic core repo by the devs - setup some basic addon repos - open the addon repos to be maintained by the community and reviewed/released by the developers untill community members have proved to do it the same way. that's something where we are not sure where i686 wants to go and if we will adopt it.
- it would not be prepared to have an x86 port. but only one x86(i586?) dev would be enough to rebuild that distro with some help by an automated build system.
All in all it would be nothing significant different from the port we now have but packages would be more selected and hit the repos later to ensure the improved stability.
we want to do this all together with the ArchLinux developers and community. we want to keep using all the great tools and resources Arch already offers.
the first step that would need to be done is to splitout our scm. i cannot image to keep working with a common scm. that's what now makes it the clone we don't want to have any longer.
if you agree to give us that freedom back, i already have one good candidate for becoming a new x86_64 developer and several community members promised to help out. they all like our goals. at least that we will have some.
Few questions: What x86_64 users should do with those current/extra packages that won't go in your repo? What will be the status of AUR? Example: when there is package foobar-5.0 in AUR that depends on libabc-2.1 in our current/extra, but your arch64 repo will have only libabc-2.0 (which has incompatable API) - user will have to downgrade foobar PKGBUILD to 4.0 that compiles with libabc-2.0 (sorry if my explanation is confusing) Do x86_64 TUs agree to maintain separate set of PKGBUILDs compiled against your "stable" versions? And where to put those packages that are not in your current/extra, but are in ours, so they cannot go to Community? -- Roman Kyrylych (Роман Кирилич)
participants (5)
-
Aaron Griffin
-
Andreas Radke
-
Daniel Isenmann
-
Jason Chu
-
Roman Kyrylych