Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michael Orlitzky]

On 11/08/2015 10:53 AM, Michał Górny wrote:
> 
> No. This is going to be PITA to parse, and indefinite recursion is just
> wrong. Like you suddenly have to traverse the whole crazy structure to
> find a particular project.
> 

That's already true if you want the last project in the file =P

You're just traversing a list of linked lists rather than a linear list.
The indefinite recursion is already there: in the draft I can create an
infinite number of nested  pointers, or worse I could do,

  
Foo
f...@gentoo.org

  

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michał Górny]

On Sun, 8 Nov 2015 11:02:09 -0500
Michael Orlitzky  wrote:

> On 11/08/2015 10:53 AM, Michał Górny wrote:
> > 
> > No. This is going to be PITA to parse, and indefinite recursion is just
> > wrong. Like you suddenly have to traverse the whole crazy structure to
> > find a particular project.
> >   
> 
> That's already true if you want the last project in the file =P
> 
> You're just traversing a list of linked lists rather than a linear list.
> The indefinite recursion is already there: in the draft I can create an
> infinite number of nested  pointers, or worse I could do,
> 
>   
> Foo
> f...@gentoo.org
> 
>   

I meant finding project by e-mail. You don't have to care about
subprojects at all to do this. Subprojects are a side info.

-- 
Best regards,
Michał Górny



pgp0zl95GFGEy.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michael Orlitzky]

On 11/08/2015 11:07 AM, Michał Górny wrote:
>>
>>   
>> Foo
>> f...@gentoo.org
>> 
>>   
> 
> I meant finding project by e-mail. You don't have to care about
> subprojects at all to do this. Subprojects are a side info.
> 

What exactly gets harder? Finding an email address is same in emacs/grep
regardless of the nesting. If you wanted to write a script, it might get
one line longer:

#!/usr/bin/python

import sys

import xml.etree.ElementTree as ET
tree = ET.parse('metadata.xml')
for project in tree.findall('.//project'):
if project.find('email').text == sys.argv[1]:
   print(project.find('name').text)

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michael Orlitzky]

On 11/08/2015 02:41 AM, Michał Górny wrote:
>>
>> If everyone likes and wants to keep the name _sub_project, I think
>> _inherit_ is the wrong word to use, since children inherit from parents.
> 
> What do you suggest instead?
> 

Can a project be a subproject of more than one superproject? If not, is
it possible to use the structure of the XML to indicate the subness of
the subproject?

  
Bar
b...@gentoo.org

  
  
Foo
f...@gentoo.org
  

  

I know you mentioned the whole one value per key thing, but does anyone
actually want to have multiple inheritance for projects?

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michał Górny]

On Sun, 8 Nov 2015 10:38:17 -0500
Michael Orlitzky  wrote:

> On 11/08/2015 02:41 AM, Michał Górny wrote:
> >>
> >> If everyone likes and wants to keep the name _sub_project, I think
> >> _inherit_ is the wrong word to use, since children inherit from parents.  
> > 
> > What do you suggest instead?
> >   
> 
> Can a project be a subproject of more than one superproject? If not, is
> it possible to use the structure of the XML to indicate the subness of
> the subproject?
> 
>   
> Bar
> b...@gentoo.org
> 
>   
>   
> Foo
> f...@gentoo.org
>   
> 
>   
> 
> I know you mentioned the whole one value per key thing, but does anyone
> actually want to have multiple inheritance for projects?

No. This is going to be PITA to parse, and indefinite recursion is just
wrong. Like you suddenly have to traverse the whole crazy structure to
find a particular project.

-- 
Best regards,
Michał Górny



pgpjjjQqNSy5v.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Aaron Bauman]

On Tue, 2015-11-03 at 23:15 +0100, Michał Górny wrote:

> Please review, comment and answer the questions in TODOs ;-).
> 
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_stru
> cture
> 

A great improvement over the current implementation.  Thank you.

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Aaron Bauman]

On Tue, 2015-11-03 at 23:15 +0100, Michał Górny wrote:

> Please review, comment and answer the questions in TODOs ;-).
> 
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_stru
> cture
> 

A great improvement over the current implementation.  Thank you.

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michael Orlitzky]

On 11/03/2015 05:15 PM, Michał Górny wrote:
> 
> Please review, comment and answer the questions in TODOs ;-).
> 
> [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_structure
> 

Much more sane than what we have now, thank you.

My only question is about the name of the "subproject" element. If you
haven't read the GLEP, can you tell me whether Foo is a subproject of
Bar or vice-versa?

  
Foo
f...@gentoo.org

  

  
Bar
b...@gentoo.org
  

Putting the name aside, I expected the mapping to go in the other
direction by analogy with relational databases.

This is also misleading with the current name:

  

That looks like the subproject inherits the members of the parent
project, right? But it's the other way around:

  * optional inherit-members="" attribute whose non-empty value
indicates that subproject members are to be considered members of
the parent project as well.

If everyone likes and wants to keep the name _sub_project, I think
_inherit_ is the wrong word to use, since children inherit from parents.

Re: [gentoo-dev] pre-GLEP review: Maintainership structure

[Michał Górny]

On Sat, 7 Nov 2015 20:45:37 -0500
Michael Orlitzky  wrote:

> On 11/03/2015 05:15 PM, Michał Górny wrote:
> > 
> > Please review, comment and answer the questions in TODOs ;-).
> > 
> > [1]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Maintainership_structure
> >   
> 
> Much more sane than what we have now, thank you.
> 
> My only question is about the name of the "subproject" element. If you
> haven't read the GLEP, can you tell me whether Foo is a subproject of
> Bar or vice-versa?
> 
>   
> Foo
> f...@gentoo.org
> 
>   
> 
>   
> Bar
> b...@gentoo.org
>   

I don't see a problem with that. We have a  object that has
 and  elements -- sub-objects. Otherwise, it'd be
 or .

This could be made a little more clear if we wrapped all subprojects
around  element. But then, we should also wrap members
around , and maintainers around  ;-) for
consistency. And the last one would actually break backwards
compatibility, though it'd be consistent with how we do ...

> Putting the name aside, I expected the mapping to go in the other
> direction by analogy with relational databases.

Relational databases have technical limitation of having one value for
key which does not apply here. That's why most ORMs actually focus on
the opposite direction than the database itself.

> This is also misleading with the current name:
> 
>   
> 
> That looks like the subproject inherits the members of the parent
> project, right? But it's the other way around:
> 
>   * optional inherit-members="" attribute whose non-empty value
> indicates that subproject members are to be considered members of
> the parent project as well.
> 
> If everyone likes and wants to keep the name _sub_project, I think
> _inherit_ is the wrong word to use, since children inherit from parents.

What do you suggest instead?

-- 
Best regards,
Michał Górny



pgpKc_R1450aM.pgp
Description: OpenPGP digital signature