FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 05-07-2010, 04:44 PM
Pierre Schmitz
 
Default repo

Hi all,

here is another crazy idea I was thinking about for some days. This should
improve our overall package quality and simplify our work flow. The
problem
with out current [testing] repository are these:
* it is only used by very few people. Most of the times we don't get much
feedback until packages are moved to core or extra
* it is often in a inconsistent state; especially during incomplete so
name bump rebuilds
* sometimes packages are known to be broken or unstable

On the other side we are sometimes in need of some intermediate
repository. For example single people stack a pile of packages in their
home dirs until they can be moved to a repo at once. We have also seen
temporary repos like jpng to manage larger rebuilds.

My idea is to redefine the testing repo and introduce a new staging one.
(remember the good old days? ;-))
With the implementation of the package pooling moving packages between
repos can be done with nearly no overhead. So ideally
we should be able to use testing more often, even for a very short period
like a
day.

proposal for [testing]
* never push any known-to-be-broken packages here (for example incomplete
rebuilds)
* candidates for core are put here
* ideally new builds of important/critical packages or major rebuilds can
be put here to test them by a larger audience.
* don't put any package in here which are never meant to be moved to
core/extra. (like experimental alpha software etc.)

proposal for [staging]
* this repo should only used by devs and tus
* it is not meant to be used on a production system
* it should only be enabled in a packages build environment (chroot)
* this could be even excluded from outbound rsync. Due to package pooling
packages would still be propagated. And moving those packages to other
repos will be "instantly".

Summing things up more packages should be passed through testing, more
users should be able to use testing without breaking their systems and we
don't have to make them reading the high traffic arch-dev-public list. We
also should be able to collaborate more in packaging: Dev A puts a new lib
into [staging] and another one can start rebuild other packages using that
lib. Another common use case would be large builds like KDE we usually
start packaging one week before release. Till now those were put into
users' staging dirs and the other devs had to manually download them,
create a local repo and install them.

So, what do you think about this idea?

Greetings,

Pierre

--
Pierre Schmitz, https://users.archlinux.de/~pierre
 
Old 05-07-2010, 04:50 PM
Aaron Griffin
 
Default repo

On Fri, May 7, 2010 at 11:44 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
> Hi all,
>
> here is another crazy idea I was thinking about for some days. This should
> improve our overall package quality and simplify our work flow. The
> problem
> with out current [testing] repository are these:
> * it is only used by very few people. Most of the times we don't get much
> *feedback until packages are moved to core or extra
> * it is often in a inconsistent state; especially during incomplete so
> *name bump rebuilds
> * sometimes packages are known to be broken or unstable
>
> On the other side we are sometimes in need of some intermediate
> repository. For example single people stack a pile of packages in their
> home dirs until they can be moved to a repo at once. We have also seen
> temporary repos like jpng to manage larger rebuilds.
>
> My idea is to redefine the testing repo and introduce a new staging one.
> (remember the good old days? ;-))
> With the implementation of the package pooling moving packages between
> repos can be done with nearly no overhead. So ideally
> we should be able to use testing more often, even for a very short period
> like a
> day.
>
> proposal for [testing]
> * never push any known-to-be-broken packages here (for example incomplete
> *rebuilds)
> * candidates for core are put here
> * ideally new builds of important/critical packages or major rebuilds can
> *be put here to test them by a larger audience.
> * don't put any package in here which are never meant to be moved to
> *core/extra. (like experimental alpha software etc.)
>
> proposal for [staging]
> * this repo should only used by devs and tus
> * it is not meant to be used on a production system
> * it should only be enabled in a packages build environment (chroot)
> * this could be even excluded from outbound rsync. Due to package pooling
> *packages would still be propagated. And moving those packages to other
> *repos will be "instantly".
>
> Summing things up more packages should be passed through testing, more
> users should be able to use testing without breaking their systems and we
> don't have to make them reading the high traffic arch-dev-public list. We
> also should be able to collaborate more in packaging: Dev A puts a new lib
> into [staging] and another one can start rebuild other packages using that
> lib. Another common use case would be large builds like KDE we usually
> start packaging one week before release. Till now those were put into
> users' staging dirs and the other devs had to manually download them,
> create a local repo and install them.
>
> So, what do you think about this idea?

I don't like it. It adds a lot of complexity.

For large rebuilds, the dbscripts DO allow us to make on-the-fly
repos, though currently the directory needs to be created by an admin
(that can be changed).

We've done this before with some releases, and I think it's a good
idea to use this capability, rather than define a testing-testing repo
(that's what this is - a testing repo before packages go to
testing...)
 
Old 05-07-2010, 05:02 PM
Pierre Schmitz
 
Default repo

On Fri, 7 May 2010 11:50:11 -0500, Aaron Griffin <aaronmgriffin@gmail.com>
wrote:
> I don't like it. It adds a lot of complexity.
>
> For large rebuilds, the dbscripts DO allow us to make on-the-fly
> repos, though currently the directory needs to be created by an admin
> (that can be changed).

Having a repo for just this purpose will make things easier and I don't
see where it would increase complexity.

> We've done this before with some releases, and I think it's a good
> idea to use this capability, rather than define a testing-testing repo
> (that's what this is - a testing repo before packages go to
> testing...)

No you got me wrong here. It's not meant to be to test packages before
moving them to testing. Most packages will still be moved directly to extra
or testing. The staging repo would be just a place where we assemble larger
builds or could coordinate building with other devs without destroying a
real repo like testing.

So, staging is no real repo, its not in a chain like
(staging->testing->extra) and our current work flow of directly putting
packages into testing or extra wouldn't be touched.

I hope I made my point this time; though you are still allowed to dislike
it. :P

--
Pierre Schmitz, https://users.archlinux.de/~pierre
 

Thread Tools




All times are GMT. The time now is 07:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org