== Log == TZ UTC -4 {{{ [10:59] hi elmo [11:00] I pinged sabdfl and mako also, although I'm not sure that mako is up already [11:02] https://wiki.ubuntu.com/CommunityCouncilAgenda is empty afaics [11:02] is here anybody with other business for the CC meeting? [11:12] hello all [11:12] ah hi sabdfl! :) [11:12] sorry for the delay [11:12] https://wiki.ubuntu.com/CommunityCouncilAgenda is empty and I got no AOB from the people in here [11:13] nothing from me [11:13] elmo: anything from you? [11:13] do folks want an update on archivereorg? [11:13] that would be interesting [11:13] i think it is quite a big step from a community structure / management / leadership / organisation perspective [11:14] yes? no? [11:15] I agree [11:15] ok, i'll do a quick summary [11:15] the goal is to help scale our developer communit(ies), while at the same time removing unnecessary fragmentation [11:16] we hope to achieve the scaling by allowing groups of developers with specific interests to collaborate around sets of packages in ubuntu [11:16] for example, xfce folks around the set of packages that represent xfce in ubuntu, or documentation folks around the content packages [11:17] access to those groups should be easier for new developers, because they will need to demonstrate a rigorous understanding of a subset of ubuntu, rather than the whole [11:17] also, they will be evaluated and approved by the leaders of those specific communities [11:17] with some provisions for maintaining a high standard across the board [11:18] so, hopefully we have a better match of interests and permissions for more new developers [11:18] all developers that have upload to ubuntu will be considered ubuntu developers, and get a vote in the developer community [11:18] for example, in the TB elections [11:19] separately, we will unify the "generalist developer teams", currently split into -core and -motu [11:19] do you anticipate that we will have an explosion of councils, or that the existing MOTU Council will evaluate applications taking input from those leaders? [11:19] so, there will only be one team of generalist developers [11:19] some of current motu folks will start out in a focused team, others will start out in the new unified generalist team [11:19] we agreed to be conservative in unleashing the new force of potential fragmentation :-) [11:20] so, we will probably have 5-10 focus areas initially [11:20] gnome, kde, xfce, documentation, mozilla/xul, toolchain, java, etc [11:20] there hasn't been a decision-making conversation about that initial set [11:20] finally, there will be some portions of the archive where you will need specialised knowledge to have immediate write access [11:21] there's no final spec as to which areas they are [11:21] but they will not be concentric (i.e. we won't have a simplistic "more trusted, less trusted" approach) [11:21] kernel team gets kernel, and so on [11:22] we will try to facilitate participation in those areas by others, too [11:22] so any ubuntu developer will be able to upload to the kernel [11:22] but the upload will need to be reviewed [11:22] and there is a commitment to make sure those reviews happen timeously [11:22] that's about it [11:22] is that review something that could be extended across the board? [11:23] otherwise we need a good way of asking "can I upload this package directly?" [11:23] james_w: well, if someone from the xfce team uploads something that's defined as being part of gnome, or not part of anything, it would get queued for review, yes [11:23] in other words, the general meme is "don't reject uploads, either send them to the builds or queue them for review" [11:23] thanks, that's interesting [11:24] that describes the layer of "package upload permissions", really [11:24] i think w e will see a second layer emerging around access control to the branches that people use for package version control [11:24] sabdfl, This mechanism might replace some of the current sponsoring mechanisms more generally? [11:24] james_w's work around NoMoreSourcePackages [11:25] * dholbach hugs james_w [11:25] persia: yes. if you have someone who is an expert in a field, and is doing good work with that set of packages, it should be possible to empower them to upload those packages directly [11:25] so, we will have VCS for casual or specialist or upstream participation [11:25] and a richer model for sharing the archive between collaborating teams [11:25] with a more level playing field for folks who are trusted as generalists [11:25] I meant rather for those that weren't. Currently, we use subscription to special sponsoring teams, but the queued upload solution seems like a better model for those who do not (yet) have upload to a given package. [11:26] I think encouraging non-trivial uploads to be submitted as merge proposals would be sensible, as that is a better interface for review than pulling a package out of the unapproved queue [11:26] persia: at this stage, i'd prefer there to be a difference between the queue for review of packages uploaded by people who are already ubuntu developers SOMEWHERE (i.e. -studio or -xubuntu) [11:26] sabdfl, That makes sense. Thank you for the clarification. [11:26] vs package reviews for someone who is not [11:26] and avoids clashes where you wish to upload something that is awaiting review [11:27] james_w: yes, i don't think our current queue system is up to it, that's where we'll need to do some work [11:27] okdokey! [11:27] any other questions? or should we wrap? [11:27] thanks sabdfl [11:27] nothing from me [11:27] thank you dholbach :-) [11:27] we could always make the uploads in the queue available as branches of course [11:28] thank you sabdfl, interesting stuff [11:28] I'm sure there will be plenty more discussion on this topic [11:29] OK, adjourned :) }}}