It was <2013-12-09 pon 14:28>, when Ylinen, Mikko wrote: > On Mon, Dec 9, 2013 at 11:22 AM, Łukasz Stelmach > <[email protected]>wrote: > >> My proposal to solve the above problems is to assign smaller groups >> of people to maintain every package who would get notifications about >> changes. The rest of members of the domain groups would keep their >> rights to the repositories (I am not sure how this would play with >> the greater responsibilities of the "maintaining teams") but they >> won't be notified automatically. The "maintaining teams" should >> (IMHO) comprise: > > AFAIR, detailed subdomain structure has been discussed. However, I > haven't seen any proposals so far, though. > > Since I've spent some time thinking this earlier (from the > architecture perspective), I'm sharing my proposal what these 'smaller > groups' (subdomains) could be: > > https://wiki.tizen.org/wiki/Tizen_Platform_Architecture_Overview#Tizen_Subdomain_Proposal > > some subdomains may not be ideal but most Tizen/system functionality > should be covered.
Nope, subdomainsa are not what *I* mean. I am fine with domains as they are, dividing them further in a formal way based on topics is IMHO not necessary. What I think is moot is that everyone in a domain receives requests for review of every package in that domain. Membership in domains gives people *rights* to do stuff with repositories. I would like *duties* to be assigned to smaller teams. Besides, while I'd like to keep maintainership of platform/upstream/lrzsz and I think I could help with reviewing (or maybe even maintanence) of "Network & Connectivity" packages, I think that if someone requests a new package and wants to be it's maintainer, one should not automatically become a mamber of a "Maintainers" group for a domain. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpqLH8ez73sB.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
