[gentoo-project] Metastructure: Dead projects (was: Call for agenda items - Council meeting 2013-11-12)

[gentoo-project] Metastructure: Dead projects (was: Call for agenda items - Council meeting 2013-11-12)

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 864 bytes --]

Am Dienstag, 29. Oktober 2013, 14:23:24 schrieb Andreas K. Huettel:
> 
> Please respond to this message with agenda items. Do not hesitate to repeat
> your agenda item here with a pointer if you previously suggested one (since
> the last meeting).
> 

The following projects seem to be (to me) not active anymore. Please protest 
if I'm misinformed, or volunteer to revive them!

If the projects are dead and remain so, I would like to propose archiving web 
pages and other data and removing them from the metastructure. 

* Gentoo/Alt Arch Testers (last page update 2007)
* Gentoo Support Everywhere (last page update 2009)
* Kolab2/Gentoo Groupware Project (last page update 2007, last overlay commit 
"Removed outdated packages" 2010)



-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-project] Metastructure: reorganization (Was: Call for agenda items - Council meeting 2013-11-12)

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1199 bytes --]

Am Dienstag, 29. Oktober 2013, 14:23:24 schrieb Andreas K. Huettel:
> 
> Please respond to this message with agenda items. Do not hesitate to repeat
> your agenda item here with a pointer if you previously suggested one (since
> the last meeting).
> 

If you look at our metastructure page, it's a bit of a mess. Some careful 
rearrangement might make sense... How about this:

1) top level project "Gentoo Programming Resources"
 - title in table is wrong, should be (according to project page) "Gentoo 
Resources for Programming Languages", or just "Programming Languages"
 - has subprojects ada, haskell, ruby
proposed action: move java, lisp, perl, php, python in there as additional 
subprojects

2) top level project "Community Resources"
 - has subprojects ComRel, Recruiters, Undertakers
proposed action: move PR, gse(dead?), Ops in there as additional subprojects 

3) propsed action: create top level project "server" (in analogy to "desktop")
move apache, kolab(dead?), scire, virtualization, vps, web-apps in there as 
subprojects

Opinions?
Best, Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-project] Metastructure: reorganization (Was: Call for agenda items - Council meeting 2013-11-12)

[Ulrich Mueller]

>>>>> On Tue, 29 Oct 2013, Andreas K Huettel wrote:

> If you look at our metastructure page, it's a bit of a mess. Some
> careful rearrangement might make sense... How about this:

> 1) top level project "Gentoo Programming Resources"
>  - title in table is wrong, should be (according to project page)
> "Gentoo Resources for Programming Languages", or just "Programming
> Languages"
>  - has subprojects ada, haskell, ruby
> proposed action: move java, lisp, perl, php, python in there as
> additional subprojects

GLEP 39 defines a project as "a group of developers working towards a
goal". 

I don't see what we would gain by collecting several unrelated
projects under an umbrella TLP. Are there any resources that can be
shared, or is there a large overlap between devs working in the
different language projects? In short, what problem are you trying to
solve?

> 2) top level project "Community Resources"
>  - has subprojects ComRel, Recruiters, Undertakers
> proposed action: move PR, gse(dead?), Ops in there as additional
> subprojects

> 3) propsed action: create top level project "server" (in analogy to
> "desktop")
> move apache, kolab(dead?), scire, virtualization, vps, web-apps in
> there as subprojects

Same arguments as above.

Ulrich

Re: [gentoo-project] Metastructure: reorganization (Was: Call for agenda items - Council meeting 2013-11-12)

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 2391 bytes --]

Am Dienstag, 29. Oktober 2013, 23:15:45 schrieb Ulrich Mueller:
> >>>>> On Tue, 29 Oct 2013, Andreas K Huettel wrote:
> > If you look at our metastructure page, it's a bit of a mess. Some
> > careful rearrangement might make sense... How about this:
> > 
> > 1) top level project "Gentoo Programming Resources"
> > 
> >  - title in table is wrong, should be (according to project page)
> > 
> > "Gentoo Resources for Programming Languages", or just "Programming
> > Languages"
> > 
> >  - has subprojects ada, haskell, ruby
> > 
> > proposed action: move java, lisp, perl, php, python in there as
> > additional subprojects
> 
> GLEP 39 defines a project as "a group of developers working towards a
> goal".
> 
> I don't see what we would gain by collecting several unrelated
> projects under an umbrella TLP. Are there any resources that can be
> shared, or is there a large overlap between devs working in the
> different language projects? In short, what problem are you trying to
> solve?

Actually for asking this question you've picked the best example...

Imagine the poor KDE guys sorting out the language bindings for Ruby, Python, 
Java, and C#. Each comes with its own approach to solve the same problems, and 
with its own completely disjunct eclass syntax. 

Imagine updating your system after a while and then remembering that you need 
to run python-cleaner and perl-updater (and what was the syntax there again?).

Maybe there isn't too much overlap right now, but people talking to each other 
would certainly help, and the problems are certainly related.


This is the most important thing, and similar ideas also apply to the two 
other proposals. (PR, CoC enforcement and Ops are certainly related tasks?)


There's two additional motivations from my side. 

One is my stereotypical German preference for cleanlyness and order. Or maybe 
it's just that part of leaving a professional impression is also that you 
don't just have a messy list of unordered projects. 

The other one is that on the long run we might reconsider the role of umbrella 
project leads. I'm not so sure yet what we should do there though... 
Strengthen, give them tasks? some loose oversight that subprojects follow 
formalities? Abandon?

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-project] Metastructure: reorganization

[Ulrich Mueller]

>>>>> On Tue, 29 Oct 2013, Andreas K Huettel wrote:

> Actually for asking this question you've picked the best example...

> Imagine the poor KDE guys sorting out the language bindings for
> Ruby, Python, Java, and C#. Each comes with its own approach to
> solve the same problems, and with its own completely disjunct eclass
> syntax.

> Imagine updating your system after a while and then remembering that
> you need to run python-cleaner and perl-updater (and what was the
> syntax there again?).

> Maybe there isn't too much overlap right now, but people talking to
> each other would certainly help, and the problems are certainly
> related.

> This is the most important thing, and similar ideas also apply to
> the two other proposals. (PR, CoC enforcement and Ops are certainly
> related tasks?)

The key question is if it is reasonable to organise things as a common
project. This only makes sense if devs of the (to be) subprojects are
working together to some degree. For example, do they have a common
mailing list? (Turns out that in case of programming languages there
is gentoo-dev-lang, but it seems to be inactive.) It is perfectly fine
if people want to work together and organise themselves under an
umbrella TLP. However, I don't expect that creating such a structure
artificially would work, unless there is initiative from the projects
themselves.

Also the council has no power to decree a new project structure.
GLEP 39 says that projects organise themselves, so we cannot force any
project to convert itself from a TLP to a subproject. This would also
mean that some of the language projects (like Common Lisp and Scheme)
would be downgraded to third level.

> There's two additional motivations from my side. 

> One is my stereotypical German preference for cleanlyness and order.
> Or maybe it's just that part of leaving a professional impression is
> also that you don't just have a messy list of unordered projects.

That can be solved without introducing additional organisational
structures. For example, by arranging the project list by some
categories instead of alphabetical.

> The other one is that on the long run we might reconsider the role
> of umbrella project leads. I'm not so sure yet what we should do
> there though... Strengthen, give them tasks? some loose oversight
> that subprojects follow formalities? Abandon?

Just ask them what they see as their role, and if the umbrella project
is functional.

Ulrich

Re: [gentoo-project] Metastructure: reorganization

[Rich Freeman]

On Wed, Oct 30, 2013 at 2:46 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
> The key question is if it is reasonable to organise things as a common
> project. This only makes sense if devs of the (to be) subprojects are
> working together to some degree.

++

> Also the council has no power to decree a new project structure.
> GLEP 39 says that projects organise themselves, so we cannot force any
> project to convert itself from a TLP to a subproject. This would also
> mean that some of the language projects (like Common Lisp and Scheme)
> would be downgraded to third level.

I'd worry more about what makes sense for Gentoo, and less about who
is allowed to make it happen.  I'm not suggesting the Council should
overstep its authority/etc.  If something makes sense for Gentoo we
can lead the way to it happening regardless of what it takes
(decisions, dev-wide votes, whatever).  If something doesn't make
sense, then what it takes is moot.

I think the real barrier to reconciling foo-cleaner with bar-updater
is devs talking to each other and general interest levels.  If
somebody is really interested in taking a leadership role here they're
welcome to step up.  If something takes off we can support it with the
right meta-structure.  However, I'm not a big fan of
build-it-and-they-will-come.

>
> Just ask them what they see as their role, and if the umbrella project
> is functional.

++

Would be interested in hearing from devs actually working on all of
these projects as to whether they think there is a benefit likely to
emerge/etc.

I'm completely supportive of this if the devs involved have interest
in making it happen/etc.

Also, thanks Andreas all the same for bringing up the topic.  I'm
interested in seeing where the discussion goes.

Rich

Re: [gentoo-project] Metastructure: reorganization

[Panagiotis Christopoulos]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On 22:55 Tue 29 Oct     , Andreas K. Huettel wrote:
> ... 
> 1) top level project "Gentoo Programming Resources"
>  - title in table is wrong, should be (according to project page) "Gentoo 
> Resources for Programming Languages", or just "Programming Languages"
>  - has subprojects ada, haskell, ruby
> proposed action: move java, lisp, perl, php, python in there as additional 
> subprojects
> 

that project probably is ancient history now (but only george can tell). The
only benefit I could see in such a project would be only for porting new
languages and/or giving manpower to a herd maintaining some rare flavors (compilers /
interpreters) (but there is a lang-misc herd, dont' know if it's
related to some project though). I can't find a reason atm for
example the lisp project to move as subproject of this and bug 151118[1]
does not convince me. Here[2] someone can find the original discussion
on this.

As for what you wrote about cleanliness and order, I understand what you
mean, but a web/wiki page listing all projects related to programming
languages would serve the same.  

[1] https://bugs.gentoo.org/show_bug.cgi?id=151118
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/43072/

-- 
Panagiotis Christopoulos ( pchrist )
    ( Gentoo Lisp Project )

[-- Attachment #2: Type: application/pgp-signature, Size: 291 bytes --]

[gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - pgp key handling

[Patrick Lauer]

On 10/29/2013 09:23 PM, Andreas K. Huettel wrote:
> In two weeks from now, the council will again have its regular monthly 
> meeting. Now is the time to raise and prepare items that the council should 
> put on the agenda to discuss or vote on.

Request: A minimal policy for pgp keys and key handling (for commit signing)

- Define the allowed key parameters:
	e.g. 2048bit RSA or DSA, validity at least 6 months

- Define a canonical location (e.g. in LDAP and on at least one
keyserver) where every dev's key is accessible (at least to gentoo infra)

- Define a location of a (signed, autoupdated) global keyring that is
accessible to all interested parties (e.g.
http://www.gentoo.org/keyring.txt )

That's the first stage that can be done now without big problems, and it
can be amended at any later time if there's any deficiencies.
(so if we agree that 2048 bit are not enough we just fix it to 4096 bit
and a three-month migration time)

With that in place we can make commit signing mandatory (because right
now we don't even have a way to fetch all keys, so it's worse than
useless).

And then as a third stage we can discuss things like, say, disabling
commit access when the key is less than a month valid (after sending
some automated warning mails, yes?) and other ways to make this meaningful.


But - let's not get carried away in a big debate about how the NSA has
infiltrated the minds of at least three devs, so we need four signatures
on every commit before it goes live, and other unrelated madness. Just
define the minimum set of rules to make signing useful, and then figure
out how to enforce it.

(As a sidenote, someone might want to figure out how to do remote signed
commits - last time this was discussed I think there were some minor
issues that should be worked out so that we're all not too affected with
workflow changes)

Thanks,

Patrick

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - pgp key handling

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 4341 bytes --]

++++++++++...

I have been working on the gentoo-keys project [1] to actively maintain
the gentoo gpg keys installation, validation, etc. for users, devs and
servers.  

On Wed, 2013-10-30 at 08:33 +0800, Patrick Lauer wrote:
> On 10/29/2013 09:23 PM, Andreas K. Huettel wrote:
> > In two weeks from now, the council will again have its regular monthly 
> > meeting. Now is the time to raise and prepare items that the council should 
> > put on the agenda to discuss or vote on.
> 
> Request: A minimal policy for pgp keys and key handling (for commit signing)
> 
> - Define the allowed key parameters:
> 	e.g. 2048bit RSA or DSA, validity at least 6 months
> 

I have it to a point that it would be easy to create a template to
semi-automate the process of creating/updating the keys.  But a spec is
needed for it.  That spec can be another file that can be updated and
downloaded automatically when ever that functionality is used.  No need
for a new release of the app with the changes.

> - Define a canonical location (e.g. in LDAP and on at least one
> keyserver) where every dev's key is accessible (at least to gentoo infra)
> 

I have code done which I run from woodpecker (or some other ldap
accessible system) for mining the gpg keys from ldap and creates the
seed file from that info.  Last I test ran it, there were still a number
of devs with mismatched keys and fingerprints. and one without a gpg key
or fingerprint.   Currently it is a little awkward to run from my dev
space due to the +x restriction.  It has to be run via "python2.x
ldap-seeds" currently.

Setting up some automation or having it installed is a next step that
needs discussion.  It will have a python interface that can be
incorporated into last summer's GSOC projects that mgorny and dastergon
were working on, which could do entry validation and trigger the seed
file updates.


> - Define a location of a (signed, autoupdated) global keyring that is
> accessible to all interested parties (e.g.
> http://www.gentoo.org/keyring.txt )
> 

The seed file will be made available similar to layman's
repositories.xml list 
eg: https://api.gentoo.org/overlays/repositories.xml

From the seed lists available there, any or all the dev or relaease
media keys can be installed (using the seed info to get the key from the
key server, check the fingerprints match, etc..))  the cli interface
will have convenience functions for checking and validating the release
media and other downloads.


I am in the process of updating mirrorselect's code to get it's lists
from:
MIRRORS_3_XML = 'https://api.gentoo.org/mirrors/distfiles.xml'
MIRRORS_RSYNC_DATA = 'https://api.gentoo.org/mirrors/rsync.xml'


> That's the first stage that can be done now without big problems, and it
> can be amended at any later time if there's any deficiencies.
> (so if we agree that 2048 bit are not enough we just fix it to 4096 bit
> and a three-month migration time)
> 
> With that in place we can make commit signing mandatory (because right
> now we don't even have a way to fetch all keys, so it's worse than
> useless).

Last I was actively working on it, I was about to start coding the git
commit validation hook.  But got injured/concussion that put that on
hold.

> 
> And then as a third stage we can discuss things like, say, disabling
> commit access when the key is less than a month valid (after sending
> some automated warning mails, yes?) and other ways to make this meaningful.
> 
> But - let's not get carried away in a big debate about how the NSA has
> infiltrated the minds of at least three devs, so we need four signatures
> on every commit before it goes live, and other unrelated madness. Just
> define the minimum set of rules to make signing useful, and then figure
> out how to enforce it.
> 
> (As a sidenote, someone might want to figure out how to do remote signed
> commits - last time this was discussed I think there were some minor
> issues that should be worked out so that we're all not too affected with
> workflow changes)
> 
> Thanks,
> 
> Patrick
> 


P.S.  I welcome anyone to join in and help with it's development.

 [1] http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git;a=summary

-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items - pgp key handling

[Rich Freeman]

On Wed, Oct 30, 2013 at 1:35 AM, Brian Dolbec <dolsen@gentoo.org> wrote:
>
> Last I was actively working on it, I was about to start coding the git
> commit validation hook.  But got injured/concussion that put that on
> hold.

I'd encourage discussion of this bit at least on the appropriate lists
(gentoo-scm?).  My only concern is that validating git commits
requires knowing what a valid git commit looks like, and that might
involve some number of assumptions about how we intend to use git.

This is actually one of the areas surrounding the migration that
hasn't been fully baked. I'm sure everybody has a sense in their head
of how things will work, but I'm not convinced that everybody's
notions are the same.  There has been discussion in the past about
merge vs rebase and so on, and that can have an impact on just what
commits actually end up in our tree, and who if anybody has signed all
of them.

Definitely don't want to slow you down.  I just don't want you to end
up getting burned if things don't go as you expected.  Also, I'm
interested in how you figured everything would work in part because it
might help the rest of us make up our minds...

Rich