| 1 |
On 14 January 2014 18:11, William Hubbs <williamh@g.o> wrote: |
| 2 |
|
| 3 |
> On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote: |
| 4 |
> > On 01/14/2014 05:33 PM, William Hubbs wrote: |
| 5 |
> > > On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote: |
| 6 |
> > >> On 01/14/2014 04:37 PM, William Hubbs wrote: |
| 7 |
> > >>> |
| 8 |
> > >>> 2. I would like to see the policy below applied to all arch's [2]. |
| 9 |
> > >> |
| 10 |
> > >> [ ] Yup |
| 11 |
> > >> [X] Nope |
| 12 |
> > > |
| 13 |
> > > The reverse of this would be to let maintainers stabilize on all arch's |
| 14 |
> > > after 90 days, then they are allowed to remove all but the latest |
| 15 |
> stable |
| 16 |
> > > version. This isn't good though because maintainers would be |
| 17 |
> stabilizing |
| 18 |
> > > packages on arch's where they can't test. |
| 19 |
> > > |
| 20 |
> > > The stable tree is significantly behind because the arch teams are so |
| 21 |
> > > short staffed, and this prooposal is an attempt to fix that. |
| 22 |
> > |
| 23 |
> > It's attempting to fix a headache with a bullet. The arch teams are |
| 24 |
> > lagging behind, you're annoyed, I get it. Give 'em hell. But don't break |
| 25 |
> > stable to make a point. |
| 26 |
> > |
| 27 |
> > For users, both options are worse than the status quo. |
| 28 |
> |
| 29 |
> The first option would start reverting things back to ~ and users would |
| 30 |
> have to unmask them. |
| 31 |
> |
| 32 |
> The second option would introduce new things to stable which may not be |
| 33 |
> stable due to not being tested on the arch. |
| 34 |
> |
| 35 |
> The second option is worse than the first imo, that's why I didn't |
| 36 |
> propose it first. |
| 37 |
> |
| 38 |
> The status quo is not good, because we are forced to keep old, and |
| 39 |
> potentially buggy, versions of software around longer than necessary. |
| 40 |
> |
| 41 |
> William |
| 42 |
> |
| 43 |
> |
| 44 |
|
| 45 |
|
| 46 |
I think the simplest short-term solution might be to add teams that are |
| 47 |
looking for ArchTesters to the Staffing Needs page on the wiki and promote |
| 48 |
that page like crazy. I'd be more likely to do a lot more stabilizations if |
| 49 |
it wasn't just me going on my experience and running through the AT |
| 50 |
procedures myself (they're also a bit lengthy if you follow them properly, |
| 51 |
which I prefer to). |
| 52 |
|
| 53 |
I do feel some arches should be a bit deprecated. Not quite as severely |
| 54 |
other arches the council deprecated a few months back, but something. |
| 55 |
|
| 56 |
Also, to ease the burden on Arches, it'd be nice if the maintainer would do |
| 57 |
some of the archtesting work on all their available arches rather than |
| 58 |
making the AT's/arch teams do it...For example, almost everyone who has a |
| 59 |
amd64 system, can easily make a x86 chroot (or VM) to test in. |
| 60 |
|
| 61 |
Another option (and I don't mean to step on any toes or call anyone out |
| 62 |
here, these are just examples) may be to just deprecate stabilizing certain |
| 63 |
software. Packages such as the stuff in app-vim/ or app-emacs/ or some |
| 64 |
games or some scientific software. For the editor plugins, most people do |
| 65 |
not get them from the package manager I feel and a Vim plugin requires |
| 66 |
almost as much arch testing work as a new version of grep, for example... |
Archives