Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
Am Sonntag, den 04.01.2009, 18:06 +0100 schrieb Jeroen Roovers:
> On Sun, 04 Jan 2009 17:02:21 +
> Mike Auty wrote:
>
> > According to [1], "When the file lists multiple entries, then you
> > assign the bug to the first maintainer, and CC the other
> > maintainer(s) and herd(s)." So it looks as though the file should go
> > through the maintainers first and herds second? Should be pretty
> > easy to fix...
>
> I spotted that too but didn't remember putting it in black and white. :)
>
> The order ("first maintainer as assignee" or "first maintainer/herd as
> assignee") is open to discussion and I think this is the proper forum to
> have that discussion.
I'd say that the correct way to fix this is to fix the metadata schema
to be able to write something like this:
foo
adev
bar
or
foo
adev
bar
Because having to write this:
foo
a...@gentoo.org
bar
is just nonsense.
Cheers,
Tiziano
--
---
Tiziano Müller
Gentoo Linux Developer
Areas of responsibility:
Samba, PostgreSQL, CPP, Python, sysadmin
E-Mail : dev-z...@gentoo.org
GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Re: Last Rites: app-portage/udept
On Mon, 15 Dec 2008 23:47:47 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> While I'm at it, is there anything useful to display metadata.xml?
> In particular, the long descriptions and use flags can be useful.
> With use.desc and especially the local version thereof going
> deprecated, and with additional info about global flags sometimes in
> the metadata...
md() {
cat "$(dirname $(equery w $1))/metadata.xml"
}
can also replace cat with less and metadata.xml with ChangeLog, etc.
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
[gentoo-dev] Re: reorganization of /var/lib gentoo-related files
On Wed, 31 Dec 2008 01:12:23 +0100 Fabio Rossi wrote: > I'm proposing to reorganize the files related to Gentoo > inside /var/lib. Currently we have this situation (at least on my > system): > > /var/lib/eselect > /var/lib/gentoo/enews > /var/lib/herdstat/ > /var/lib/module-rebuild > /var/lib/portage /var/lib/wxwidgets is also gentoo/eselect specific FWIW. > The main dir should be something like /var/lib/gentoo, so I'd see all > gentoo-related files as > > /var/lib/gentoo/eselect > /var/lib/gentoo/enews > /var/lib/gentoo/herdstat/ > /var/lib/gentoo/module-rebuild > /var/lib/gentoo/portage > > What do you think about? i kinda like it how it is. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robin H. Johnson wrote: > Neither set of rules is ideal. Ordering makes a lot of sense when you > just read it. Consider metadata with multiple maintainers and multiple > herds. Either you have to start assigning explicitly (requires editing > metadata.xml), or you need to fall back to ordering. If you're going to > do ordering further down, why not do it from the start and be done with > it. Ok, I'm convinced. 5:) I tend not to prefer having "hidden" meanings, but as you point out XML is ordered, and you definitely made the case that it won't have a large impact. Fine by me... 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkljaG4ACgkQu7rWomwgFXq53gCeMRe+n+S6N2za00zuHjrge/gw nUIAniyeVK/RTlVUaR2Q3Eqw+5cCMIoU =01UN -END PGP SIGNATURE-
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
On Sun, Jan 04, 2009 at 06:12:17PM +, Mike Auty wrote: > a) herds.xml per-herd priority flag (herd gets assigned) > b) metadata.xml priority element (can be opt-in or opt-out) > c) order of elements in metadata.xml > > I'm personally not keen on the order of elements, since adding meaning > to the order might mean a fair number of misassignments until people fix > the metadata.xml files. How many metadata files have the ordering wrong to start with? Of the packages I maintain, just looking at a handful, very few have it bad enough that I'd bother complaining rather than just changing them. > The herds.xml element isn't very specific, but if the herd-first rules > apply to the whole herd, then it's probably the least-impact solution. > > Finally, if we think we'll ever need something more specific than > herds.xml, we could add an extra element. or > could be added to the minority case (I'm > not sure which has fewer ebuilds, but if there's hard and fast rules > this should be relatively automatable). Neither set of rules is ideal. Ordering makes a lot of sense when you just read it. Consider metadata with multiple maintainers and multiple herds. Either you have to start assigning explicitly (requires editing metadata.xml), or you need to fall back to ordering. If you're going to do ordering further down, why not do it from the start and be done with it. For anybody that wants to complain that XML is unordered - it isn't, consider an HTML document that is also well-formed XML and validates against a DTD. You wouldn't want your paragraphs changing order on you. Count of total + elements and how many metadata.xml files have the count: 1 7842 2 4958 3 290 435 By number of herds: 026 1 12720 2 359 319 4 1 By number of maintainers: 0 8135 1 4730 2 241 319 If we assume that every metadata.xml with 2 or more items is wrong, thats at most 40% of the tree. I say go with ordering. I think it will affect less than 10% of packages in the end, and for large swaths it won't matter (dev-perl and dev-$LANG in general, which account for some 20% of the tree). Also, maintainers that don't want dupe assignments (normally because they in the herd) are going to be editing anyway, and I think that will cover a lot of the required edit cases as well. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpjPb7RMwP4M.pgp Description: PGP signature
Re: [gentoo-dev] [v4] Planning for automatic assignment computation of bugs
В Вск, 04/01/2009 в 18:57 +0100, Robert Buchholz пишет:
> On Sunday 04 January 2009, Mike Auty wrote:
> > Jeroen Roovers wrote:
> > > The order ("first maintainer as assignee" or "first maintainer/herd
> > > as assignee") is open to discussion and I think this is the proper
> > > forum to have that discussion.
>
> I actually implemented it this way before (only that I had all herds
> with higher priority than all maintainers, which is the reverse of your
> patch).
>
> Accepting the fact that different teams have different preferences, we
> need to find a solution for them to set theirs individually. This could
> either be the order of elements in metadata.xml (and would set the
> preference on a per-package basis) or some attribute in herds.xml
> (which would be a global setting per herd, and we'd need to find a
> default).
It looks like we really need some per-team configuration for default
assignment. Probably it's good idea to add 'weight' (or 'nice')
attribute for and elements both in herds.xml and
metadata.xml. Bug assignment field will be selected from the elements
with minimal weight (least nice ;)). IMO best is to assign on first
(any) maintainer in this list and on first (any) herd if there is no
maintainer elements there. If weight is defined in multiple places, per
category weight overrides weight from herd.xml and weight in
metadata.xml overrides everything. This allows easy way to define any
policy team wants but still allow maintainer to override team
preference. What do you think?
--
Peter.
Re: [gentoo-dev] Re: gentoo-x86 commit in app-forensics/memdump: memdump-1.0.1.ebuild ChangeLog
Daniel, answering you in this mail... Yes, probably sometimes we have to
discuss basic things in this mailing list but since developers do this
basic errors we have to. Technical problems in our portage tree are
perfectly valid for this mailing list.
В Пнд, 05/01/2009 в 13:55 +0530, Nirbheek Chauhan пишет:
> >> SRC_URI="http://www.porcupine.org/forensics/${PN}-1.01.tar.gz";
> >>
>
> Missing MY_PV I presume?
Hardcoded version makes version bumps harder. I'm not sure why ebuild
was versioned differently from tarbal but yes, in this case it's better
to use versionator eclass define PV.
> >> RDEPEND="virtual/libc"
> > ^^
>
> Useless deps which are already in @system?
Dependency on libc is completely useless since every usable system have
C library.
> >> S=${WORKDIR}/${PN}-1.01
> >
>
> Quotes and ${MY_PV} missing?
You don't need quotes in assignments. It hardcoded version again.
> >> src_compile() {
> >> cd ${S}/memdump-1.01
> > ""
>
> Quotes, and ${PN}-${MY_PV} ?
> Although, should this even be required since ${S} is already set correctly?
src_compile initial working directory is S so this line could (and
should) be just dropped.
> >> einfo "testing"
> >> if [ "`./memdump -s 344 | wc -c`" = "344" ];
> >> then
> >> einfo "passed test"
> >> else
> >> die "failed test"
> >> fi
>
> Here, why not use
>
> einfo "testing"
> [ "`./memdump -s 344 | wc -c`" = "344" ] || die "failed test"
> einfo "passed test"
Yup. It's shorter and does same thing.
--
Peter.
