Subject: [alpine-devel] Organizing Alpine Linux project

From: Natanael Copa <[email-masked]>
Date: Thu, 24 Feb 2011 16:10:54 +0100

Hi,

 So, we have experienced a growth recently and I think its about time 
 that we try have some official organization structure. I would like to 
 try avoid bureaucracy and strict rules. We want this to be a fun place 
 to be.

 Here is what I propose:

 We define the Alpine Linux goal.
 Suggestion:
 Provide an operating system that is (in priority order):
 1) Secure
 2) Small/non-bloated
 3) Simple
 4) Fast

 Of course there are trade-offs so consider the above as a general 
 guideline rather than a strict rule.

 We split us up in the following teams/subprojects:
 * Infrastructure Team
 * Developer Team
 * Documentation Team

 We also need a Security Team, but I'll come back to that later.

 = Infrastructure Team =
 The goal is to provide and maintain the needed hardware and services 
 that are needed to keep the Alpine Linux project running. This includes 
 web sites, bugtracker, mail servers, mailing lists, IRC channels etc. As 
 long as it possible and makes sense we want use Alpine Linux for this. 
 We should eat our own dog food.

 Currently its nangel that is the (un)official coordinator. I think we 
 have many candidates for people to join this team: clandmeter, jbilyk.

 Please let me know if you want help setup and run our infrastructure.

 = Developer Team =
 They do the developing work, build packages, bootscripts, installer, 
 package manager, etc. We can probably divide this in 
 subteams/subprojects later. For example package maintainers can be 
 splitted up in maintainer teams like "kernel maintainers", "base libs 
 (uclibc)", "python team", "perl team", etc. We will probably also have a 
 Release Team and a "stable maintainers" that comes here under.

 I suggest me as coordinator for this team. Those who have commit access 
 are automatically members here.

 = Documentation Team =
 Are responsible for the official documentation. (current in wiki)
 I suggest mattx86 as team coordinator here. Is this ok?
 There are many candidates for team members. (jbilyk, mhavela, etc)

 = Security Team =
 I think we need a security team which follows sec lists and figures out 
 what packages that are vulnerable to us. They create tickets and kicks 
 the developers in the rear part til they have fixed the issue. Ilemme 
 Haave that offered do this but have been totally missing so currently 
 there is nobody doing this important job so volunteers are welcome.

 Please let me know if you are interested beeing a part of the security 
 team or want be the security team coordinator.

 I suggest that all team members gets an official @alpinelinux.org email 
 address. We probably don't need to do mail hosting for this but can 
 forward to our current email addresses.

 We could also have Marketing team, Recruitment team and Art team but I 
 think its better we start small.

 If you feel you belong to the team or feel for be a coordinator of a 
 team, please let me know. I would prefer that the team coordinators are 
 active involved and reasonable responsive on requests.

 Maybe each team should have a subproject in the bugtracker? Maybe we 
 should have a separate email list for each team?

 Other ideas, thougts?

 -nc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Jeremy Thomerson <[email-masked]>
Date: Thu, 24 Feb 2011 22:51:33 -0600

On Thu, Feb 24, 2011 at 9:10 AM, Natanael Copa <[email-masked]>wrote:

> Hi,
>
> So, we have experienced a growth recently and I think its about time that
> we try have some official organization structure. I would like to try avoid
> bureaucracy and strict rules. We want this to be a fun place to be.
>
> Here is what I propose:
>
> Of course there are trade-offs so consider the above as a general guideline
> rather than a strict rule.
>
> The goal is to provide and maintain the needed hardware and services that
> are needed to keep the Alpine Linux project running. This includes web
> sites, bugtracker, mail servers, mailing lists, IRC channels etc. As long as
> it possible and makes sense we want use Alpine Linux for this. We should eat
> our own dog food.
>
> Currently its nangel that is the (un)official coordinator. I think we have
> many candidates for people to join this team: clandmeter, jbilyk.
>

I think for the next year or so at least, I will have more time to help with
this, and wouldn't mind assisting nangel, et al with whatever I can.

> package manager, etc. We can probably divide this in subteams/subprojects
> later. For example package maintainers can be splitted up in maintainer
> teams like "kernel maintainers", "base libs (uclibc)", "python team", "perl
> team", etc. We will probably also have a Release Team and a "stable
> maintainers" that comes here under.
>
> I suggest me as coordinator for this team. Those who have commit access are
> automatically members here.
>

I won't be much help with the kernel stuff, but wouldn't mind helping with
any java-oriented packages specifically.  I'm a java junkie.  I've created a
few general packages as well that I'll try to maintain better than I have
been.

> what packages that are vulnerable to us. They create tickets and kicks the
> developers in the rear part til they have fixed the issue. Ilemme Haave that
> offered do this but have been totally missing so currently there is nobody
> doing this important job so volunteers are welcome.
>
> Please let me know if you are interested beeing a part of the security team
> or want be the security team coordinator.
>
> address. We probably don't need to do mail hosting for this but can forward
> to our current email addresses.
>
> If you feel you belong to the team or feel for be a coordinator of a team,
> please let me know. I would prefer that the team coordinators are active
> involved and reasonable responsive on requests.
>
> Maybe each team should have a subproject in the bugtracker? Maybe we should
> have a separate email list for each team?
>

Subproject in the bug tracker would be useful for pulling up a list of "what
I need to work through".  In my monitoring of this mailing list, I don't
think we need separate mailing lists for them (yet).

> Other ideas, thougts?

Jeremy Thomerson