1 |
On Tuesday 13 October 2009 20:33:35 Mark Loeser wrote: |
2 |
> Mike Frysinger <vapier@g.o> said: |
3 |
> > On Tuesday 13 October 2009 19:30:52 Joshua Saddler wrote: |
4 |
> > > All that to say, Tommy (et al), is that the idea of expecting users to |
5 |
> > > magically know everything and not to offer any documentation *in |
6 |
> > > advance* . . . is a silly idea. Good lord, can you imagine the |
7 |
> > > shitstorm the X11 team would have gone through if they'd tried *that* |
8 |
> > > without first writing up xserver 1.5 and 1.6 migration guides?! |
9 |
> > |
10 |
> > we arent talking migrations that are forced onto everyone. we're talking |
11 |
> > about new code that users have to *opt in* for ("new net") that is only |
12 |
> > available in unstable. expecting everything in testing to be documented |
13 |
> > up front is unreasonable. no one is saying the stuff shouldnt be |
14 |
> > documented, just that complete user friendly coverage is not a |
15 |
> > requirement for unstable. your comments here dont really apply to |
16 |
> > bleeding edge -- they certainly apply to stable though. |
17 |
> |
18 |
> I'd say this isn't correct. Unstable isn't a pure testing playground. |
19 |
> its meant for packages that should be considered for stable. As such, |
20 |
> we should make sure that we get the documentation needed ready, so we |
21 |
> can make sure that it is correct for people that are testing the upgrade |
22 |
> path for us. It then gives us a chance to correct our documentation |
23 |
> before it goes stable. |
24 |
|
25 |
i disagree with this strict interpretation of stable vs unstable. while it's |
26 |
a noble ideal, it isnt realistic. we have plenty of versions that go into |
27 |
unstable with no plans of them going stable as they're good for vetting new |
28 |
issues on the way to a newer stable version. i'd prefer to have a bunch of |
29 |
smaller changes with minor issues in each than a large code dump which is hard |
30 |
to coordinate problems with actual changes. |
31 |
|
32 |
> All this comes down to is laziness in documenting changes, and forcing |
33 |
> stuff upon our users. Neither of those things is good, and if everyone |
34 |
> thinks that's the status quo...that really should change. |
35 |
|
36 |
then everyone in Gentoo is lazy because we always have things that lack 100% |
37 |
coverage. we also arent forcing anything onto users. the documentation hole |
38 |
here applies only to new code that is disabled by default. |
39 |
-mike |