[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-desktop
Subject:    Re: [gentoo-desktop] kill that crazy overlay
From:       "Andreas Sturmlechner" <andreas.sturmlechner () gmail ! com>
Date:       2008-12-27 14:36:36
Message-ID: 511a9d910812270636j10303aaj594a5ed28b25e4d3 () mail ! gmail ! com
[Download RAW message or body]

Hi all,

I also think that the split in kde-testing and kde-crazy is a good
idea, still. You can't avoid confusion though when a branch is
stabilizing and its ebuilds are moving from kde-crazy to kde-testing
(until they finally reach the main portage tree). It will be the same
again at the transition from 4.2 to 4.3, from 4.3 to 4.4, ...

The only way to prevent the confusion (of both users, and more
importantly, devs) would be to organize them differently. Let each KDE
development branch have its own overlay, e.g. kde42 and kde43. At the
beginning of its life span, that overlay would be highly experimental,
just as kde-crazy. During upstream development, both code and
eclasses/ebuilds stabilize simultaneously, and at beta time changes
would be minimal already. That's the time when ebuilds usually move
out from kde-crazy to kde-testing and questions such as the one above
emerge, but in the suggested structure, they would remain in their
overlay at least until the branch hits portage, and eventually, the
overlay would be removed and a new one created, as KDE development
goes on.

2008/12/26 Markos Chandras <hwoarang@silverarrow.gr>:
> On Friday 26 December 2008 03:54:54 Jorge Manuel B. S. Vicetto wrote:
>> Theo Chatzimichos wrote:
>> > Hello
>>
>> Hi
>>
>> > we are having a small issue here concerning the two overlays. Since the
>> > eclasses, the live ebuilds and the snapshots are in a good shape now (in
>> > fact eclasses are about to hit the tree), kde-crazy offers nothing but
>> > confusion now. There's no reason to have to sync eclasses between
>> > overlays every time, it's boring, time consuming and maintaining two
>> > overlays in a single system is very difficult (should i say impossible?)
>> > I can't test eclasses for the co-existence of snapshots and live in a
>> > single system at the moment for example. Furthermore, even devs don't
>> > know where is the right place to commit :) Initially i thought it would
>> > be better to have in a separate overlay all the ebuilds that are going to
>> > hit tree, but now i don't. I'd like to hear everybody's opinion,
>> > especially jmbsvicetto's since (iirc) he proposed the kde-crazy overlay
>>
>> I still think there's a place and purpose for both overlays.
> I agree with this
>> Let me
>> recall you the reasons for them:
>>
>>  * kde-testing - the purpose of this overlay is to be a stage for
>> ebuilds going into the tree and for having "reasonably" stable ebuilds
>> for packages that we don't want to put in the tree. For instance, the
>> bumps for 4.1.4 and 4.1.86/90 should be done here.
>>  * kde-crazy - overlay for hosting the live ebuilds and for doing the
>> really "wacky" experiments (features for long term). As an example, work
>> for 4.3 snapshots should start here.
>>
>
> I my mind , kde-testing is for kinda "stable" packages while kde-crazy is for
> experiments. For example , i keep chaning qt-4.5.0_beta ebuilds. I would feel
> really guilty if those packages were in kde-testing overlay cause I would not
> feel comfortable chaning them.
> See, kde-craze is like a kde/qt playgroun for development and testing while
> kde-testing offers kde packages that are consider *highly* testing to be in
> portage.
>> I think most of your problems are happening because having eclasses in
>> any of the overlays makes things harder. The reason any eclass should be
>> added to the kde-testing overlay is to get it final testing before
>> moving into the tree. Any major change on eclasses should start on
>> kde-crazy.
>>
>> > Regards,
>> > Theodore
>
> Markos
>
> --
> Markos Chandras (hwoarang)
>
>

[prev in list] [next in list] [prev in thread] [next in thread]