| 1 |
Hi Troy |
| 2 |
|
| 3 |
Some new activity on this thread, cool! |
| 4 |
If I understand correctly your proposal you talk about supporting different |
| 5 |
ebuild stabiliyt/status levels by means of creating new branches for every |
| 6 |
stability level. |
| 7 |
This seems semantically very similar to my proposal (including use of shell |
| 8 |
variables). There are some technical discripances though which I would |
| 9 |
like to address here. |
| 10 |
I shell say that I am working now on writing a detailed proposal of multiple |
| 11 |
ebuild stability levels (and immediate submission visibilty). I will try to |
| 12 |
finish it and submit the link to this maillist as soon as possible. |
| 13 |
|
| 14 |
|
| 15 |
> George, |
| 16 |
> After reading the messages in this thread (particularly the last |
| 17 |
> two posted by you) I'd like to say that I agree with you and to add a |
| 18 |
> couple of thoughts of my own. |
| 19 |
> |
| 20 |
> I like the idea of having ebuilds submitted via bugs.gentoo.org being made |
| 21 |
> easily available to all gentoo users -- keeping one interface for |
| 22 |
> submission is a good idea. |
| 23 |
> |
| 24 |
> However instead of (as well as) your multiple package state levels how |
| 25 |
> about this (this is all just hypthesis, I don't know if it is possible, I |
| 26 |
> don't know enough about all the tools used): |
| 27 |
> |
| 28 |
> Multiple cvs branches along the lines of this: |
| 29 |
As I said semantically it seems very similar. Technically though, how |
| 30 |
exactly will this be represented in user (synced) portage tree? Will user |
| 31 |
have portage, portage-testing, portage-unstable, etc? I am afraid it will |
| 32 |
create more confusion especially if you take into account the need to update |
| 33 |
existing ebuilds. What about the package in the stable tree which was updated |
| 34 |
and new ebuild should get a "testing" status? If you want to keep things |
| 35 |
semantically consistent and secure you will end up with pieces of package in |
| 36 |
different trees. Is this then really different from additional suffix in |
| 37 |
ebuild name? I designed this change to ebuild name in order to be consistent |
| 38 |
with present ebuild processing scheme. It seems that it should require less |
| 39 |
modification to portage tools this way and it should keep the whole process |
| 40 |
as much as possible automated, not only on the user but also on maintainer |
| 41 |
side. I would guess that maintainers of the server will be unhappy about |
| 42 |
having to support additional trees. |
| 43 |
|
| 44 |
|
| 45 |
> |
| 46 |
> Testing Branch - primarily for use by developers. |
| 47 |
> - new ebuilds from bugs.gentoo.org come in here |
| 48 |
> - If there is no activity on an ebuild (it's bug) |
| 49 |
> for 14 days it get's moved to Unstable |
| 50 |
I personally would be quite opposed to automatic promotion on my system. I |
| 51 |
think it should require some user intervention, such as votes for |
| 52 |
intermediate stability level and core group revision before it gets marked as |
| 53 |
stable. This way you can get whatever stability you want for you setup. |
| 54 |
I will post the link to all the details as soon as I'll get enough time to |
| 55 |
finish it, I promise :-). |
| 56 |
|
| 57 |
> eg: |
| 58 |
> root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync |
| 59 |
> ... updating /usr/portage/unstable from cvs.gentoo.org/unstable |
| 60 |
Nice idea. I actually thought about inclusion of such flags into |
| 61 |
/etc/make.conf (and all other related files). It should definitely be |
| 62 |
possible to set this in command line as well. |
| 63 |
|
| 64 |
It is good to know that people think along the same lines generally WRT this |
| 65 |
issue. |
| 66 |
|
| 67 |
George |
Archives