| 1 |
On 22/11/2007, Elias Pipping <pipping@g.o> wrote: |
| 2 |
> On Thu, Nov 22, 2007 at 06:10:03AM +1000, Peter Ansell wrote: |
| 3 |
> > On 22/11/2007, Fabian Groffen <grobian@g.o> wrote: |
| 4 |
> > > On 21-11-2007 07:55:04 -0600, Jeremy wrote: |
| 5 |
> > > > True, and we are adding more obscure platforms often. I don't know how |
| 6 |
> > > > many people use ia64-hpux for example, but it *seems* that I am one of |
| 7 |
> > > > the few if only besides haubi because he has done alot of work on the |
| 8 |
> > > > tree for me. I don't have time or resources to maintain a stable branch |
| 9 |
> > > > by myself and report back to you. |
| 10 |
> > > > |
| 11 |
> > > > Maybe here is a better solution: |
| 12 |
> > > > Make the "auto-sync" script mark everything ~arch until it has been |
| 13 |
> > > > tested by some members of the community then we could create a stabilize |
| 14 |
> > > > request on b.g.o. - if people want to devote some time to it, they can |
| 15 |
> > > > and they can lead the effort. |
| 16 |
> > > |
| 17 |
> > > That's sort of the current solution without stable keywords. If there |
| 18 |
> > > are people that want to do the job, fine with me, syncing will always |
| 19 |
> > > produce a new ~arch ebuild, not sure what I should do for the updates |
| 20 |
> > > inside an ebuild (like an added patch - could break). Something tells |
| 21 |
> > > me I should keep it stable if it was, otherwise I probably break the |
| 22 |
> > > deptree. |
| 23 |
> > |
| 24 |
> > It is not as likely that patches to "stable" ebuilds will break in |
| 25 |
> > most cases, though it is always possible. I would go with keep a given |
| 26 |
> > version stable after patching unless someone reports a bug with it, as |
| 27 |
> > there aren't the resources to do rechecks on every patch on every |
| 28 |
> > ebuild for the prefix. |
| 29 |
> |
| 30 |
> Isn't the whole purpose of stable keywords not having to report a bug |
| 31 |
> first? People on stable don't want to hit bugs, that's why they pay the |
| 32 |
> price of being a little outdated. So stable keywords should make it as |
| 33 |
> unlikely for such an incident to occur |
| 34 |
|
| 35 |
I don't understand what you said about not having to report a bug |
| 36 |
first. Stabilisation "bugs" are the first thing I think about when you |
| 37 |
say that, but that may be a different issue. Issues do come up on |
| 38 |
stable ebuilds, and rather than having an unstable keyword it may be |
| 39 |
better to simply stay at stable, seeing also as the prefix tree |
| 40 |
doesn't always have control over the -rX numbers, because they may |
| 41 |
need to stay in sync with the main portage tree. |
| 42 |
|
| 43 |
> If a bug is reported for an ebuild masked as testing, it's masked and |
| 44 |
> the bug is worked on. That might not help the guy who hit the problem, |
| 45 |
> though, who might now need to rebootstrap. |
| 46 |
|
| 47 |
Gentoo doesn't inherently give any guarantees to people. I have never |
| 48 |
been in the situation with my ~x86 server that I can't get around the |
| 49 |
bug somehow without re-bootstrapping. The expat issue was the closest |
| 50 |
I came to that in my 4 years of running Gentoo. Okay, given the ~x86 |
| 51 |
tree does collapse sometimes but that is the price you pay for |
| 52 |
complete customisability. |
| 53 |
|
| 54 |
I would rather make people see the risk up front, at least to |
| 55 |
encourage them to be active in reporting when something is stable on |
| 56 |
their architecture as a benefit to the rest of the community, rather |
| 57 |
than having them think that the community owes them some level of |
| 58 |
support that it can't give with limited resources. If you get enough |
| 59 |
people doing this reporting then maybe stable versions wouldn't be a |
| 60 |
resource blocker. |
| 61 |
|
| 62 |
Peter |
| 63 |
-- |
| 64 |
gentoo-alt@g.o mailing list |
Archives