On Wed, 04 Nov 2009 16:02:16 -0500
Joseph Jezak <josejx@gentoo.org> wrote:

> Ben de Groot wrote:
> > What about ppc64? They are MONTHS behind on stabilization,
> > even for security bugs (see bug 281821 for example). The Qt team
> > feels this is no longer acceptable. We propose that any arch that
> > can't keep up will be demoted to experimental status.
> >
> >
> ppc is also fairly far behind (much thanks to nixnut for keeping us
> going!). Part of the problem is that when I do get time to catch up,
> we're so buried in bugs, it's time consuming just to triage and figure
> out what to do next, and even to remember where I left off last.
>
> I would really help if there were better communication about what bugs
> absolutely need to be done ASAP and what can slide by for now.
>
> That said, please be a bit more patient with us, we just don't have the
> manpower to fix every single keywording bug immediately.

Is there any interest in allowing certain packages to be stabilized by the
maintainer without going through the arch teams? I always feel guilty when i
file stabilization bugs for app-doc pkgs.


--
fonts, Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Hi!

On Wed, 04 Nov 2009, Ryan Hill wrote:
> Is there any interest in allowing certain packages to be stabilized by the
> maintainer without going through the arch teams? I always feel guilty when i
> file stabilization bugs for app-doc pkgs.

I think for bugs which only install passive files (i.e. stuff
that doesn't "power" anything else), Keywording can be done by the
maintainer. Pure doc files (like selfhtml) are in that category.

Naturally, if a new version needs a new doc processing toolchain,
things are a bit different.

But as far as alpha is concerned: go ahead.

Regards,
Tobias

PS: I considered allowing the doc processing stuff, too, but it's
astoundingly easy to break some fairly important stuff just my
messing up DTDs.

--
printk("Pretending it's a 3/80, but very afraid...
");
linux-2.6.19/arch/m68k/sun3x/prom.c

Ryan Hill posted on Wed, 04 Nov 2009 21:48:23 -0600 as excerpted:

> Is there any interest in allowing certain packages to be stabilized by
> the maintainer without going through the arch teams? I always feel
> guilty when i file stabilization bugs for app-doc pkgs.

Weren't there already arrangements for this in some cases? I distinctly
recall a thread on it some time ago, with the conclusion being that
various maintainers can get permission from the arch teams to keyword
their own packages.

Now that was in the /general/ context of having access to the arch either
directly/personally or thru available testing resource machines, but (as
klausman accounts for in his post) that really doesn't apply to (for
example) docs packages that don't require fancy build-chains or (with
some sanity margin) where the build chain dependencies have been long
stable, so "required testing resources" are virtually zero.

Thus, I'd say it's probably an extension of the previous arrangement --
but of course that does still require an initial one-time permission
grant per arch, either per-package, or depending on arch/pkg-maintainer
trust level, possible per category or similar.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Tobias Klausmann wrote:
> Hi!
>
> On Wed, 04 Nov 2009, Ryan Hill wrote:
>> Is there any interest in allowing certain packages to be stabilized by the
>> maintainer without going through the arch teams? I always feel guilty when i
>> file stabilization bugs for app-doc pkgs.
>
> I think for bugs which only install passive files (i.e. stuff
> that doesn't "power" anything else), Keywording can be done by the
> maintainer. Pure doc files (like selfhtml) are in that category.
>

In the past when smaller arches were not that active we used to mark
Java packages stable after testing by at least one arch team. The
probability to find arch specific issues in something like Java is not
so high so I think arrangements like this are acceptable when the arch
teams have problems keeping up.

Regards,
Petteri

> In the past when smaller arches were not that active we used to mark
> Java packages stable after testing by at least one arch team. The
> probability to find arch specific issues in something like Java is not
> so high so I think arrangements like this are acceptable when the arch
> teams have problems keeping up.
>
I do know that for Java stuff, I certainly wouldn't mind if the Java
team marked for ppc/ppc64. The only thing that I'd need to know is that
it was tested with the IBM JVM since there certainly are differences
between that and the Sun one most people use on x86/amd64 and we've seen
issues in the past.

-Joe

On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> In the past when smaller arches were not that active we used to mark
> Java packages stable after testing by at least one arch team. The
> probability to find arch specific issues in something like Java is not
> so high so I think arrangements like this are acceptable when the arch
> teams have problems keeping up.
>

I think the same should be extended to other languages such as Perl
and Python (unless they have portions which are C/C++)


--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> > In the past when smaller arches were not that active we used to mark
> > Java packages stable after testing by at least one arch team. The
> > probability to find arch specific issues in something like Java is not
> > so high so I think arrangements like this are acceptable when the arch
> > teams have problems keeping up.
>
> I think the same should be extended to other languages such as Perl
> and Python (unless they have portions which are C/C++)

Sounds like we could benefit from the "noarch" approach known in the RPM
world, such that all these packages can also be immediately keyworded
and stabilised for all arches. Would greatly simplify things for a
great deal of packages, maybe?


--
Fabian Groffen
Gentoo on a different level

On Sat, Nov 7, 2009 at 3:18 AM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:

> In the past when smaller arches were not that active we used to mark

> Java packages stable after testing by at least one arch team. The

> probability to find arch specific issues in something like Java is not

> so high so I think arrangements like this are acceptable when the arch

> teams have problems keeping up.

>



I think the same should be extended to other languages such as Perl

and Python (unless they have portions which are C/C++)



*You can't really, although Perl has a vm of sorts,* the per-arch differences that occur as a side effect of endianness, different floating point/integer math ( 32bit vs 64bit ) , and all those differences impact code.


and XS modules of course, they're prone to everything C is prone to.

--
Kent

perl -e *"print substr( "edrgmaM *SPA NOcomil.ic@tfrken", $_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"


http://kent-fredric.fox.geek.nz

On Fri, Nov 6, 2009 at 9:30 PM, Kent Fredric <kentfredric@gmail.com> wrote:
> On Sat, Nov 7, 2009 at 3:18 AM, Nirbheek Chauhan <nirbheek@gentoo.org>
>> I think the same should be extended to other languages such as Perl
>> and Python (unless they have portions which are C/C++)
>>
>
> You can't really, although Perl has a vm of sorts,* the per-arch differences
> that occur as a side effect of endianness, different floating point/integer
> math ( 32bit vs 64bit ) , and all those differences impact code.
>

What kind of modules are affected by such differences? Mostly
math-heavy ones? This is something that the herd should be able to
judge.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

On Fri, Nov 6, 2009 at 8:15 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> Sounds like we could benefit from the "noarch" approach known in the RPM
> world, such that all these packages can also be immediately keyworded
> and stabilised for all arches. *Would greatly simplify things for a
> great deal of packages, maybe?
>

This is a good idea; themes, wallpapers, fonts, game-data (stuff that
mostly installs into /usr/share) could easily fall in this category. A
lot of python modules are arch-independant as well (upstream has been
thinking of splitting the install structure to put such things in
/usr/share/python2.6/<etc>).

Examples of packages:
gnome-extra/gnome-games-extra-data
x11-themes/gnome-icon-theme
kde-base/kdebase-wallpapers
games-fps/quake3-data
app-text/poppler-data
media-fonts/dejavu

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team