[arch-dev-public] [staging] repository: Let's give it a try!
Hi devs, my last attempt for this didn't get much feedback so I try to keep it short this time...for more details see the old thread at: http://mailman.archlinux.org/pipermail/arch-dev-public/2010-May/016770.html This time I am just asking to give it a try. It's implementation is trivial and if we feel it wont work out we could easily remove it later. If there are no real objections I'd like to implement this soon; let's say next week. Even if you don't see the benefit right now I would be pleased to at least give it a try. The idea can be summed up like this: testing: * don't break packages intentionally * don't push incomplete rebuilds staging: * a global staging repository for collaboration its more similar to your ~/staging dir than a regular repository * mostly meant for incomplete rebuilds * will be excluded from mirroring (for now) I am open for any questions or suggestions. Thanks for reading, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 11.08.2010 17:29, schrieb Pierre Schmitz:
Even if you don't see the benefit right now I would be pleased to at least give it a try.
No. I want to see the benefit before giving it a try.
The idea can be summed up like this:
testing: * don't break packages intentionally * don't push incomplete rebuilds
staging: * a global staging repository for collaboration its more similar to your ~/staging dir than a regular repository * mostly meant for incomplete rebuilds * will be excluded from mirroring (for now)
So, we are adding an extra layer of confusion which there was no need for in the past. What is the problem you are trying to solve?
On Wed, 11 Aug 2010 17:34:30 +0200, Thomas Bächler <thomas@archlinux.org> wrote:
Am 11.08.2010 17:29, schrieb Pierre Schmitz:
Even if you don't see the benefit right now I would be pleased to at least give it a try.
No. I want to see the benefit before giving it a try. So, we are adding an extra layer of confusion which there was no need for in the past. What is the problem you are trying to solve?
I really don't know what to answer here. All this was described in detail in my mail and it just looks like you didn't even try to read it. So please be more specific. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Am 11.08.2010 17:52, schrieb Pierre Schmitz:
I really don't know what to answer here.
Just tell me why we need to confuse ourselves even more with yet another repository.
All this was described in detail in my mail and it just looks like you didn't even try to read it. So please be more specific.
Which mail do you mean? This one or the one from May?
On Wed, Aug 11, 2010 at 10:34 AM, Thomas Bächler <thomas@archlinux.org> wrote:
So, we are adding an extra layer of confusion which there was no need for in the past. What is the problem you are trying to solve?
As I understand it, the point is to help with overly large rebuilds, allowing for multiple developers to work in parallel better. Is this correct, Pierre?
On Wed, 11 Aug 2010 10:56:28 -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Aug 11, 2010 at 10:34 AM, Thomas Bächler <thomas@archlinux.org> wrote:
So, we are adding an extra layer of confusion which there was no need for in the past. What is the problem you are trying to solve?
As I understand it, the point is to help with overly large rebuilds, allowing for multiple developers to work in parallel better. Is this correct, Pierre?
Exactly. In fact we already used this idea somehow when we had a jpng repo to prepare the libjpeg/libpng rebuilds or when we virtually freeze testing for a while and warning people to not use it atm because a rebuild is going on. My approach is simplify this and make it easier for us; so we can even use it for small rebuilds with just a dozen of packages involved. Let me underline again that [staging] would be no regular repo that would be used by anyone directly. It mainly meant for collecting rebuilds. Till now we either had a special repo, broke testing or one dev had to do the rebuild completely on his own. Using a common use case for these should make our lives easier. It would also stabilize the testing repo and hopefully this will make more people use it. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 12/08/10 02:24, Pierre Schmitz wrote:
On Wed, 11 Aug 2010 10:56:28 -0500, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Aug 11, 2010 at 10:34 AM, Thomas Bächler <thomas@archlinux.org> wrote:
So, we are adding an extra layer of confusion which there was no need for in the past. What is the problem you are trying to solve?
As I understand it, the point is to help with overly large rebuilds, allowing for multiple developers to work in parallel better. Is this correct, Pierre?
Exactly. In fact we already used this idea somehow when we had a jpng repo to prepare the libjpeg/libpng rebuilds or when we virtually freeze testing for a while and warning people to not use it atm because a rebuild is going on.
My approach is simplify this and make it easier for us; so we can even use it for small rebuilds with just a dozen of packages involved.
Let me underline again that [staging] would be no regular repo that would be used by anyone directly. It mainly meant for collecting rebuilds. Till now we either had a special repo, broke testing or one dev had to do the rebuild completely on his own. Using a common use case for these should make our lives easier.
I think this is worth implementing. No matter how often we post to hold off updating from the [testing] repo while we do a big rebuild, people still do and break their system. A staging repo would avoid that. My only question is, how soon can this be rolled out? I intend the big, big, big python rebuild to start as soon as KDE is pushed to [extra]. Allan
On Thu, 12 Aug 2010 15:38:24 +1000, Allan McRae <allan@archlinux.org> wrote:
My only question is, how soon can this be rolled out? I intend the big, big, big python rebuild to start as soon as KDE is pushed to [extra].
I guess this could be done very soon (as in begin of next week). The biggest part is probably the package pool implementation which is at least feature complete. There are other improvements and refactoring I'd like to do but this can be done in smaller steps later. For the staging repo itself the needed dirs need to be created and the rsync modules need to be adjusted. Also dbscripts and devtools should know about this repo which is trivial. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Wed, 2010-08-11 at 17:29 +0200, Pierre Schmitz wrote:
testing: * don't break packages intentionally * don't push incomplete rebuilds
staging: * a global staging repository for collaboration its more similar to your ~/staging dir than a regular repository * mostly meant for incomplete rebuilds * will be excluded from mirroring (for now)
Looks fine to me, but before we implement this, I want to see the package pools implemented. That way stuff can move between testing/staging/extra/core without ever needing extra mirroring.
On Wed, 11 Aug 2010 18:43:15 +0200, Jan de Groot <jan@jgc.homeip.net> wrote:
On Wed, 2010-08-11 at 17:29 +0200, Pierre Schmitz wrote:
testing: * don't break packages intentionally * don't push incomplete rebuilds
staging: * a global staging repository for collaboration its more similar to your ~/staging dir than a regular repository * mostly meant for incomplete rebuilds * will be excluded from mirroring (for now)
Looks fine to me, but before we implement this, I want to see the package pools implemented. That way stuff can move between testing/staging/extra/core without ever needing extra mirroring.
Of course this depends on the package pool idea which makes moving packages a matter of creating symlinks. (this is more or less done btw.) -- Pierre Schmitz, https://users.archlinux.de/~pierre
participants (5)
-
Aaron Griffin
-
Allan McRae
-
Jan de Groot
-
Pierre Schmitz
-
Thomas Bächler