[18:59] <asac> hi! ^^^
[18:59] <JenFraggle> hi
[18:59] <Jazzva> hey hey
[19:00] <shirish> hi all
[19:00] <asac> hmm ... gnomefreak not here yet :/
[19:00] <Nafallo> hi
[19:01] <asac> rzr: RainCT: ping :)
[19:01] <Volans> hi all
[19:02] <fta> hi
[19:02] <fta> hm, it's crowded in here.
[19:02] <asac> yeah :) ... arena
[19:03] <Jazzva> I thought only few of them will be here. heh
[19:03] <asac> ok .... maybe lets get started.
[19:03] <asac> gnomefreak is not here, so lets push his topics back in case he appears late
[19:04] <fta> where is the agenda ?
[19:04] <Jazzva> Does that mean I go first? Ok...
[19:04] <Jazzva> fta: https://wiki.ubuntu.com/MozillaTeam/Meetings
[19:04] <asac> agenda https://wiki.ubuntu.com/MozillaTeam/Meetings
[19:04] <Tallken> the meeting is open right? I'm here just for the curiosity
[19:04] <Jazzva> Tallken: Sure...
[19:04] <asac> thanks to Jazzva and gnomefreak that actually made this meeting become true ;)
[19:04] <Tallken> :)
[19:04] <asac> s/that/who/
[19:05] <asac> its been quite some time since the last meeting so ... here we go :)
[19:05] <Jazzva> soren, first item is membership policy for the new team, mozilla-extensions-dev
[19:05] <asac> Tallken: feel free to listen, contribute, cheer, whatever :)
[19:05] <Tallken> ok :)
[19:05] <Jazzva> Um... that's supposed to be "so", not "soren". autocomplete...
[19:06] <asac> Jazzva: ok go ahead. maybe outline the options we have
[19:06] <Jazzva> I have few suggestions. First is to auto-accept new team members with some sort of trial period (1, 3 months, ...), during which they need to prove their skills with some sort of development for the team (packaging extensions, fixing current bugs in mozilla extensions, ...)
[19:07] <Jazzva> The second would be to ask new members to show some skills before being accepted in the team.
[19:08] <asac> personally, i prefer the first (open) option but would like to hear what others think?
[19:08] <Jazzva> Personally, I am more for the second option, since we probably will use mozilla-extensions-dev branches in development, according to extensions' LargeScaleDevelopment (am I right?).
[19:08] <fta> i prefer 2nd but it's less critical than for m-t
[19:08] <JenFraggle> i think the first option sounds best
[19:09] <asac> especially the current extension-dev members ;)
[19:09]  * RainCT is here
[19:09] <asac> yes ... LargeScaleDevelopment is later on the agenda, but since it somehow interferes with this agenda point, let me explain what we plan to do
[19:09] <Volans> in the first option after the trial period is needed a meeting for confirmation of the members
[19:09] <Volans> ?
[19:10] <Nafallo> second option is lots easier to manage, I'd say. people can always branch and ask for merges.
[19:10] <asac> to better scale the extension package maintenance and help extension packagers we want to provide a few "automated" services
[19:10] <asac> for instance: we will provide automatically tracked upstream branches
[19:10] <asac> and try to automagically upgrade the .ubuntu branches
[19:11] <asac> the result of that auto upgrade will end up in a .staging branch which is supposed to reside in the ~mozilla-extension-dev team
[19:11] <asac> so the only thing that extension contacts need to do is reviewing those .staging branches and resolving any eventual conflicts
[19:12] <asac> so basically the only harm someone can do is breaking the .staging branches before they get released to the archive
[19:13] <asac> for me that means that its an acceptable risk if it helps us to get more contributors by removing a barrier (e.g. entering the team)
[19:14] <asac> anyway. on the end both options are ok for me :)
[19:14] <Nafallo> asac: people can branch those branches anonymously (http) without any risk at all surely :-)
[19:14] <Nafallo> that also makes for needed reviews of the merges, since they have to ask for it :-)
[19:14] <Nafallo> I lean towards option 2.
[19:14] <Jazzva> Nafallo: Any m-e-d member can contribute to them, I suppose that's where the risk of breakage is... But what asac said sounds reasonable, too...
[19:16] <Jazzva> Maybe we can compromise. To try the first option for some period, and then if we don't get more contributors, then to fall back to the second option?
[19:16] <fta> asac, if we auto accept (option 1), how do we get rid of people doing nothing ? (ie, those who just collect team memberships)
[19:16] <asac> Nafallo: right. good point.
[19:16] <asac> fta: the idea was to have a trial-period
[19:16] <asac> like 3 month ... then looking if there is activity
[19:16] <fta> even for opt1 ?
[19:16] <asac> fta: only for opt1, Jazzva ?
[19:16] <asac> e.g. auto admission == trial
[19:17] <Jazzva> fta, asac: yes
[19:17] <asac> e.g. merio-admission == no trial
[19:17] <asac> merito :)
[19:17] <Volans> Jazzva: for the risk you tell maybe setting a team policy (best practice) that a contact must push only branches of the extensions he is the contact can help^
[19:17] <Jazzva> asac: Well, if we they contribute, I think they can be accepted to the team :)
[19:17] <asac> i think the question is if extension-dev members can sign off packages that then get automatically uploaded
[19:17] <asac> if there always is a review step by mozillateam members required, we can auto admit i guess
[19:18] <JenFraggle> would a mentoring option work?  Part of the trial would be working with someone who can monitor their contributions?  not sure how many people to expect to join
[19:18] <asac> JenFraggle: imo mentoring should be done in a non-dedicated fashion
[19:18] <Jazzva> asac: Is that possible in LP?
[19:19] <asac> the whole #ubuntu-mozillateam channel is aleays your mentor :)
[19:19] <Jazzva> (for review thingy...)
[19:19] <Nafallo> I think we are walking a thin line here... automatically accept people for packages that potentially gets auto-uploaded? there is a reason we have policys for getting upload rights in the first place. a reviewer can always miss things in branches.
[19:19] <asac> Jazzva: there is a feature where users can review/vote for patches
[19:19] <asac> we could say that "two positive" votes of m-e-d members would trigger upload
[19:19] <asac> or one positive by m-t members
[19:19] <asac> fta: you already saw that feature in action, didnt you?
[19:20] <Jazzva> But what if those two positive votes are from new, auto-approved m-e-d members?
[19:20] <asac> e.g. sign off merges
[19:20] <Jazzva> The "one positive m-t" sounds good...
[19:20] <asac> Jazzva: right. thats why i now lean a bit more to option 2 :)
[19:20] <rzr> hi
[19:20] <Jazzva> Hey, rzr...
[19:20] <asac> even if we dont implement that right from the beginning, i would at least keep the option open
[19:20] <asac> to do it :)
[19:21] <Nafallo> how do other teams to this?
[19:21] <Jazzva> Well, here's one more: Let's try option 1 for 3 months, with one-positive vote from m-t and see if that goes well. If it doesn't, we can go to option 2...
[19:21] <asac> the other option would be to not couple the "review-power" with team membership at all, but maintain a list of valid reviewers
[19:21] <Nafallo> surely there must be things like the desktop team that has contributors?
[19:21] <RainCT> m-t?
[19:21] <Jazzva> RainCT: ~mozillateam
[19:21] <asac> Nafallo: they go over sponsorship unless you can upload to ubuntu on your own
[19:21] <fta> asac, yes, the new voting system for branch merge requests
[19:21] <RainCT> ah ok
[19:22] <fta> asac, not sure it triggers an upload though
[19:22] <asac> fta: you tink its better to couple voting powers with team membership or by maintaining a manual list of reviewers?
[19:22] <asac> fta: sure it doesnt ... thats what we need to implement :)
[19:22] <Nafallo> hmm. option 2 is basically sponsorship, but with branches rather than debdiffs...
[19:22] <asac> (welll at least a merge to the release branch)
[19:22] <asac> Nafallo: right
[19:23]  * Nafallo likes option 2 :-)
[19:23] <Jazzva> Nafallo: Yes, for the beginning. Then we add that contributor to the team
[19:23] <asac> ok ... so what are the requirements for joining if we have criterias?
[19:23]  * rzr thinks branches is better thatn debdiff
[19:23]  * asac assumes that we settle on option 2
[19:23] <Jazzva> Anyone against option 2?
[19:24] <rzr> 3, 2, 1
[19:24] <fta> asac, i'm not sure lp could restrict voting powers. I stand for option 2
[19:24] <Jazzva> I suppose that we're for option 2...
[19:24] <rzr> 0 ; opt 2 is sold for 1000$
[19:24] <asac> no objection. lets go for iut
[19:24] <Jazzva> :)
[19:24] <asac> ACTION: someone to draft m-e-d team requirements
[19:24] <asac> for admission :)
[19:25] <Jazzva> We might want them to package an extension ;). That would be the best :).
[19:25] <Jazzva> as a criteria
[19:25] <asac> ok ... what are the requirements?
[19:25] <asac> no strict rules, but a vote during mozillateam meeting?
[19:25] <asac> Jazzva: well. i guess that packaging an extension is a basic requirement for sure
[19:25] <Jazzva> Hehe :)
[19:25] <Volans> PROPOSAL: make a branch in the personal LP page with a funcional extension and the debian folder?
[19:25] <asac> but i doubt that packaging an extension just once and then going away is not good enough
[19:26] <fta> package an extension, or update an existing extension needing love
[19:26] <Nafallo> work with the reviewer and he would then be the best to tell when the individual is considered ready?
[19:26] <Volans> in this way mozillateam members can check the work
[19:26] <Jazzva> asac: Sure... Maintaining it is also good :)
[19:27] <rzr> 1 package + 1 bug fix would be show that he's confortable with the process
[19:27] <Jazzva> Nafallo: I think it would be good if more people could say that one is ready...
[19:27] <rzr> + n bug fix
[19:27] <asac> i really think updating extensions should get in the equation
[19:27] <asac> otherwise we will end up with zillions of branches, that nobody updates :)
[19:28] <Nafallo> asac: +1
[19:28] <Jazzva> Nafallo: That would go in accordance with "whole #ubuntu-mozillateam is your mentor". That way more people get to meet a prospective developer
[19:28] <rzr> +2
[19:28] <asac> so maybe: at least 1. new extension, and 3 updates?
[19:28] <Nafallo> Jazzva: good point
[19:28] <JenFraggle> having less extensions but updated ones is better than lots of unloved extensions
[19:28] <Jazzva> asac: +1 on that... with "maintaining extension" requirement
[19:28] <asac> ok.
[19:29] <asac> how about expiring anyway? e.g. if there is no activity for 6 month we should probably expire members too (with the option to join back whenever they want)
[19:29] <fta> asac, maybe we should recommend newcomers to work in ~id/+junk/branchname instead of in the project tree, to avoid pollution.
[19:29] <Jazzva> asac: Sounds good...
[19:29] <Volans> IMHO there will be two different kind of members: those who help packaging extensions just for help the packaging process and those who package and mantein their own extension (extension developer). You can require that the first kind of members when package an extension have also to maintan the same extension
[19:29] <asac> fta: good point
[19:29] <asac> fta: can all submissions for merging be done in +junk?
[19:29] <fta> asac, no idea
[19:30] <fta> worth a try
[19:30] <shirish> hi all, I hate to say this but the documentation lacks at many a places, could something be done about that?
[19:30] <Jazzva> asac, fta: Well, it can be copied to other branch, if it can't be merged from +junk, right?
[19:30] <ubuntu-laptop> i  need a few before i can talk
[19:30] <fta> Jazzva, right
[19:30] <asac> Volans: shirish we have an agenda item about that later :)
[19:30] <ubuntu-laptop> my connection is not working. only wireless is working it seems
[19:30] <shirish> I dunno if this is time or perhaps at the end of the meet, asac, fta ?
[19:30] <Jazzva> shirish: Doc? Wiki pages? That's also on agenda :)
[19:31] <shirish> Jazzva: yup
[19:31] <shirish> :)
[19:31] <asac> Volans: right. i think extension authors (as in upstream) that want to maintain their package can be added to the team after they finished their own package
[19:31] <Jazzva> Hey, gnomefreak. Welcome :)
[19:31] <fta> shirish, add your idea in https://wiki.ubuntu.com/MozillaTeam/Meetings, we'll see
[19:31] <asac> gnomefreak: \o/
[19:31] <gnomefreak> hi Jazzva
[19:31] <gnomefreak> hi asac
[19:31] <asac> ok .... lets sign off the procedure:
[19:31] <gnomefreak> im pissed and working on a conection atm
[19:31] <asac> 1 package + 3 updates
[19:32] <gnomefreak> brb
[19:32] <asac> after that regular contributions of not defined amount ;)
[19:32] <asac> for upstream extension authors we have an exception that they just need to have finished their own extension package
[19:32] <asac> is that high enough bar for joining m-e-d?
[19:33] <asac> any objectsions?
[19:33] <Jazzva> Fine by me.
[19:33] <Nafallo> sounds shiny :-)
[19:33] <fta> asac, ok for "1 package + 3 updates", but coupled with resignation after 3 (6?) months of inactivity
[19:33] <asac> 3
[19:33] <Volans> sounds good
[19:33] <asac> fta: i think 6 month of inactivity is ok
[19:33] <Jazzva> 3 updates of their packages, or any packages?
[19:33] <asac> Jazzva: well ... doesnt really matter i'd say
[19:33] <Jazzva> Cool :)
[19:33] <fta> 6 months is a full cycle, may be too much
[19:34] <asac> fta: so you want to put more pressure on m-e-d members?
[19:34] <asac> :)
[19:34] <Nafallo> fta: and if the extension they are interested doesn't get updated for the period?
[19:34] <asac> we could align the review with the release time.
[19:34] <fta> i just want people to feel concerned
[19:34] <Jazzva> I think 6 would be better. That way people are not under pressure of working :)
[19:34] <Nafallo> would we need to tie this to a working extension for current firefox maybe? + track upstream
[19:34] <asac> e.g. review 1 month before we release ... to give contributors an incentive to do their housekeeping :)
[19:34] <JenFraggle> i say 6 rather than 3
[19:35] <asac> fta: i'd say that 6 is ok if we dont really have dedicated maintainers ... e.g. everybody can work on any extension
[19:35] <asac> with dedicated maintainers 6 would be too long
[19:36] <asac> ok have we reached a consent?
[19:36] <asac> pointer: we have a bunch of other items on agenda :)
[19:36] <Jazzva> I'm ok with this :)
[19:36] <fta> i'm ok with 6 if there's nothing to do on the extension the user worked on. but if we detect new upstream versions, but no work from 3 months, i find that quite long..
[19:37] <gnomefreak> can someone post results on the meeting agenda or email me the logs
[19:37] <fta> -from+after
[19:37] <asac> fta: right. i'd say we review before release and decide case-by-case ... with the 6 month rule-of-thumb
[19:37] <Jazzva> gnomefreak: I can do it...
[19:37] <fta> asac, ok
[19:37] <Nafallo> asac: +1
[19:37] <gnomefreak> Jazzva: thanks
[19:38] <asac> anyone against having a rule-of-thumb of 6 month that can be changed by meeting decision?
[19:38] <Jazzva> gnomefreak: No problem. Are you gonna stay for your agenda items?
[19:38] <asac> gnomefreak: we are still on first item: "extension dev membership"
[19:38] <asac> ok lets do it that way then for now
[19:38] <asac> next item :)
[19:38] <gnomefreak> i doubt it i need to get a working pc other than this laptop
[19:39] <gnomefreak> asac: 6 & 3????
[19:39] <Jazzva> gnomefreak: If you can, we can do your agenda items now... or at the end of the meeting.
[19:39] <asac> i'd say since gnomefreak is now here we go directly to his items (which are the first on the agenda)
[19:39] <Jazzva> Sure...
[19:39] <asac> TOPIC: Team Tags and Status changes
[19:40] <fta> which is "We need a set of tags to keep and others to remove or combine in other tags also i would like feedback on what wikis to update since most are old. Feedback on these wikis would be great or some ideas and i will save everything as notes for a to do list and go from there "
[19:40] <gnomefreak> ok with tags i was thinking of ones we need to remove or add
[19:40] <asac> i think its agreed that the current bug procedures are too formal and we should come to something more simple
[19:40] <gnomefreak> correct
[19:41] <Jazzva> MT tags: https://wiki.ubuntu.com/MozillaTeam/Bugs/Tags
[19:41] <asac> my vision is: keep it really simple and let most of the bug work be done by the bugsquad and bugcontrol (QA) team
[19:41] <Jazzva> MT states: https://wiki.ubuntu.com/MozillaTeam/Bugs/States
[19:41] <gnomefreak> i want bug triagers to use mt-confirm instead of marking confirmed
[19:41] <gnomefreak> or other tags
[19:42] <gnomefreak> im seeing alot of bugs being closed for no reason lately
[19:42] <asac> in preparation of this meeting - based on discussion we had with bdmurray - i did setup https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook
[19:42] <fta> so far, we are really bad with mt-upstream and mt-postupstream :(
[19:42] <asac> right
[19:43] <fta> not sure the QA team wants to do that
[19:43] <asac> fta: they want to help
[19:43] <asac> (with support of mozillateam)
[19:43] <asac> the upstream procedure is a topic on its own
[19:43] <asac> based on UDS discussion i drafted https://wiki.ubuntu.com/MozillaTeam/Bugs/UpstreamBugProceduresIntrepid
[19:44] <gnomefreak> WE should push to upstream IMHO since we know what needs to be dpone
[19:44] <asac> the current topic is ment to fix the horrible situation for bug triage _before_ bugs actually get forwarded
[19:44] <asac> the handbook above tries to support the upstream triage, by introducing a "standard format" of bug summaries/descriptions
[19:45] <asac> (look at requirements for confirmed on https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook)
[19:45] <Jazzva> Well, TriagersHandbook looks good to me. It's quite simple - when it's confirmed, notify upstream :)
[19:45] <shirish> shouldn't it be both bugs and patches in a way that is easier for upstream to work with
[19:45] <asac> shirish: patches are a rare case i guess
[19:45] <asac> how dont they fit in the triagers handbook?
[19:46] <fta> patches need to be attached to bugs, so it's covered
[19:46] <Jazzva> shirish: We might not be able to produce patches if they're deep in the code. Maybe it would be better if upstream plays with it
[19:46] <Jazzva> (at least, that's my opinion :))
[19:46] <asac> even if we have a patch that fixes something, a bug still needs to be of the proper form as upstream certainly wants a good description on what get actually fixed
[19:47] <shirish> true
[19:47] <asac> ... so imo patches dont make the handbook unapplicable
[19:47] <asac> do we want to add a hint about what to do with patches to that handbook?
[19:48] <Jazzva> asac: It might be good
[19:48] <asac> ok
[19:49] <asac> ACTION: add how to upstream patches to the triagers handbook and how it fits in the general procedure :)
[19:49] <fta> asac, what about when a user contributes a patch, then it's posted upstream but upstream wants changes. how will the initial user know ?
[19:49] <shirish> it might also fit in with ubuntu-marketing to let other people know of ubuntu's contribution to packages.
[19:50] <asac> fta: good question. i think one requirement is to CC the<EMAIL_ADDRESS>users on forwarded bugs upstrewam
[19:50] <asac> we can tehn setup a mailing list that will get the traffic
[19:51] <asac> so if there are questions we can react; bug the initial submitter; or look for someone who can work in what upstream has asked for
[19:51] <asac> fta: is that good enough?
[19:51] <fta> yes
[19:51] <JenFraggle> i've got to go guys, sorry
[19:51] <asac> Jazzva: cu. thanks!
[19:51] <Jazzva> Ok, JenFraggle... See you :)
[19:52] <asac> ok. i think the topic "bug states" is well covered as we are already improving the wiki
[19:52] <asac> and the general direction to tap more bugsquad and QA members for general triage is also consent i guess
[19:52] <Jazzva> anyone have something to add, before we move on to the next topic?
[19:52] <shirish> wait
[19:53] <asac> lets move ahead. if anyone gets more ideas we can also move it to mailing list
[19:53] <asac> shirish: ?
[19:53] <shirish> what about wikis that need to be updated
[19:53] <shirish> wasn't that part of the 1st topic as well.
[19:53] <asac> shirish: we are already working on new documents that finally will replace the current pages
[19:53] <Jazzva> shirish: It's coming later ;)... It's MozillaTeam Wiki item.
[19:53] <shirish> ok, a link to sneak-peak ?
[19:53] <asac> is that what you are asking for?
[19:54] <asac> shirish: i posted them above :)
[19:54] <Jazzva> shirish: This was about bugs tags, states and triaging
[19:54] <asac> https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook
[19:54] <shirish> no no
[19:54] <asac> https://wiki.ubuntu.com/MozillaTeam/Bugs/UpstreamBugProceduresIntrepid
[19:54] <shirish> ok, what I meant if there is some finished work I could see of a wiki docuement
[19:54] <gnomefreak> i need people to look for issues with them and let me know what needs to be worked out. we have too many wikis for me to go through and look on my own
[19:54] <asac> shirish: dont understand what you mean?
[19:55] <asac> ok, arte we on next topic now?
[19:55] <asac> shirish: ?`
[19:55] <gnomefreak> asac: that needs to be updated with UDS results
[19:55] <shirish> asac: I meant how the new wiki is being structured or what things are being looked at
[19:55] <asac> is your question about "Team Tags and Status changes " or "MozillaTeam Wiki "
[19:55] <asac> ?
[19:55] <gnomefreak> asac: mozilla wikis in general for topic 2
[19:55] <asac> ok ... i am fine to move to that topic
[19:55] <gnomefreak> read my post above
[19:55] <shirish> "MozillaTeam Wiki:
[19:55] <asac> Though next one would have been "Thunderbird Extension"
[19:56] <shirish> asac: i can wait
[19:56] <gnomefreak> asac: we can work out tags and status' more on ML or in #u-m-t
[19:56] <asac> ok, lets push that back and go ahead with "MozillaTeam wiki"
[19:56] <asac> gnomefreak: right
[19:56] <asac> ok
[19:56] <asac> TOPIC: "MozillaTeam wiki"
[19:56] <asac> RATIONALE: We need to clean up the wikis for the MozillaTeam, for example taking a wiki that has conversations posted should be changed to a complete wiki, this will help users understand it more. All MozillaTeam's and ExtensionTeams's wikis should have CategoryMozillaTeam, CategoryBugSquad at the bottom of wiki page
[19:56] <gnomefreak> asac: im not looking at agenda page
[19:57] <asac> i think nobody will disagree that we should add the Category everywhere
[19:57] <asac> anyone volunteers to do this work?
[19:57] <gnomefreak> asac: thats about the jist of it, also need old wikis that freddy and alex were working on need to be updated also davids wikis
[19:57] <Jazzva> If it's not important atm, I can help in a week or two...
[19:57] <gnomefreak> asac: i will
[19:57] <asac> e.g. every mozillateam page gets CategoryMozillaTeam and every MozillaTeam/Bugs/ page gets CategoryBugSquad as well?
[19:58] <gnomefreak> asac: i need to get things worked out before hacking the hell out of them though
[19:58] <shirish> can help with that.
[19:58] <gnomefreak> asac: no
[19:58] <gnomefreak> well maybe
[19:58] <asac> shirish: great.
[19:58] <asac> ok so
[19:58] <shirish> there is one thing more which bites me though
[19:58] <asac> ACTION: properly categorize MozillaTeam wiki pages
[19:59] <shirish> many of the pages don't follow a particular structure
[19:59] <gnomefreak> asac: you want to use cat.bugsquad and mozillateam  cats.?
[19:59] <gnomefreak> shirish: thats why i have been working on them
[19:59] <shirish> please note this is not just with the mozillateam but with all.
[19:59] <shirish> gnomefreak: thanx
[19:59] <gnomefreak> shirish: we had 2 people doing wikis and they left
[19:59] <asac> gnomefreak: al pages that belong to mozillateam get MT cat ... the Bugs/ pages get bugsquad category on top of that
[19:59]  * gnomefreak only concerned with our at this time
[19:59] <gnomefreak> asac: ok
[20:00] <shirish> it would be nice if we had a place for people to know what or how they are expected to write, some structure documentation is good.
[20:00] <asac> shirish: want to become the official wiki lead for the mozillateam?
[20:00] <asac> :)
[20:00] <gnomefreak> ours need more work than bugsquad
[20:00] <shirish> asac: thanx for the offer, but would decline, of course would help with whatever little I know or can do.
[20:00] <asac> shirish: i ment: "take the lead on wiki cleanup" :)
[20:01] <shirish> gnomefreak: perhaps we can collaborate on this
[20:01] <gnomefreak> asac: i got the lead once i have a working connections the power outage burned up something
[20:01] <asac> basically means: going through, looking if things still apply; if in doubt ask on ubuntu-mozillateam
[20:01] <gnomefreak> shirish: yes that is fine :)
[20:01] <asac> and remove outdated things
[20:01] <asac> ok
[20:01] <shirish> asac: right, that's not an issue
[20:01] <asac> ACTION: gnomefreak and shirish work together on initial MozilaTeam wiki cleanup :)
[20:01] <gnomefreak> biggest wikis are membership, bugs, states, tags
[20:02] <shirish> asac: apart from that
[20:02] <shirish> if we could have just some idea for a newbie who wants to put stuff on the wiki what goes where, how and what
[20:02] <gnomefreak> asac: just need an outline of what tags you would like to keep. and what ones to dump so get with me on this once im on my desktop
[20:03] <gnomefreak> shirish: wiki in general orformat of ours?
[20:03] <asac> shirish: we can offer to help users to find the right place in #ubuntu-mozillateam or on mailing list
[20:03] <shirish> gnomefreak: ?
[20:03] <asac> i think its hard to write a proper documentation that covers enough cases to be really useful
[20:03] <shirish> right. Lemme explain what I mean
[20:03] <gnomefreak> shirish: if we could have just some idea for a newbie who  wants to put stuff on the wiki what goes where, how  and what
[20:04] <shirish> lots of wiki pages which are there are disconnected to the projects from where they came from or what's happening there.
[20:04] <shirish> gnomefreak: I meant ur answer "wiki in general orformat of ours?"
[20:04] <asac> shirish: thts why we want to add the categories
[20:04] <asac> shirish: https://wiki.ubuntu.com/CategoryMozillaTeam
[20:04] <asac> those are all pages that claim themselves that they belong to mozillateam
[20:05] <asac> you basically add that to the bottom of the page
[20:05] <shirish> asac: I know that
[20:05] <asac> ah :)
[20:05] <gnomefreak> be right back erin is having connection issues as well :(
[20:05] <shirish> what I meant was more precise let me take an example to explain what I mean
[20:05] <shirish> now let's say w.u.c/wiki/Webkit
[20:06] <shirish> now while Webkit gives a surmise of what it is, it doesn't give any link to www.webkit.org or any blogs or anything of the developer who's developing upstream
[20:06] <Jazzva> shirish: There's a link at the end of the page :)
[20:06] <shirish> now while Webkit wiki page gives a surmise of what it is, it doesn't give any link to www.webkit.org or any blogs or anything of the developer who's developing upstream
[20:06] <asac> ok
[20:07] <asac> shirish: i think such quality standards should be enforced outside the mozillateam
[20:07] <asac> we can only come up with policies that are mozillateam specific
[20:07] <shirish> right but there could be many more so it makes for people interesting for the project.
[20:07] <asac> e.g. if you make a firefox extension page, do this, that and whatever :)
[20:07] <asac> shirish: i think the right group to enforce and draft such general policies would be the Documentation Team
[20:07] <Jazzva> asac: +1 on that
[20:08] <shirish> ok cool
[20:08] <asac> shirish: could you look which pages of the MOzillaTeam might fall into a category that could benefit from such general procedures?
[20:09] <shirish> asac: not at the top of my mind, but yes for sure.
[20:09] <asac> good
[20:09] <asac> ok. i think thats it for wiki cleanup topic for now?
[20:09] <asac> gnomefreak: ?
[20:10] <asac> as it fits to this discussion, I'd suggest to move to "Extensions related wiki pages "
[20:10] <asac> TOPIC: Extensions related wiki pages
[20:10] <fta> he said something about connection issues
[20:10] <asac> Jazzva: ?
[20:10] <Jazzva> Right :)
[20:10] <asac> fta: ok. lets discuss this with him outside the meeting and followup on mailing list
[20:11] <fta> k
[20:11] <asac> Jazzva: what do you suggest regarding extension pages?
[20:12] <Jazzva> I was thinking of setting up extensions' related wiki pages under MozillaTeam/Extensions/, so they're not mixed with the general MozillaTeam pages. For example. Current MozillaTeam/Firefox3Extensions/Packaging would be MozillaTeam/Extensions/Packaging, and MozillaTeam/Firefox3Extensions could be ... dunno, MozillaTeam/Extensions/List
[20:12] <asac> Jazzva: so you want to remove "Firefox" from the context?
[20:12] <gnomefreak> we should do that but in sense of a firefox one a tbird one ect... as main pages
[20:12] <asac> e.g. remove it from wiki name
[20:13] <asac> gnomefreak: +
[20:13] <Jazzva> That would also apply to the rest of the pages that are related to extensions' stuff. I don't think there will be many pages to go to the MozillaTeam/Extensions/, on the other hand
[20:13] <gnomefreak> this way we dont have ff and tb messed in one page
[20:13] <Jazzva> asac: gnomefreak's idea is good
[20:13] <gnomefreak> Jazzva: just keep our heading and add to that
[20:13] <asac> so MozillaTeam/Extensions/Packaging (e.g. for general mozilla extension packaging)
[20:13] <Nafallo> ehrm. so s/3//g ? :-)
[20:14] <asac> and MOzillaTeam/Extensions/Firefox/List (for firefox 3 extension list) ?
[20:14] <gnomefreak> leave MozillaTeam/firefox/extensions band so on
[20:14] <Nafallo> ah
[20:14] <Jazzva> Yep, something like that...
[20:14] <gnomefreak> asac: replace list with the autual pages
[20:14] <asac> gnomefreak: one page per extensions?
[20:14] <gnomefreak> actual
[20:14] <asac> hmm
[20:14] <Volan1> and for other mozilla programs? (seamonley, ecc..)
[20:14] <asac> i like the table
[20:14] <Jazzva> Thought, we need to know what to do with extensions which both work in FF and TB
[20:14] <gnomefreak> asac: no one page per firefox extensions
[20:15] <asac> Volan1: what kind of information would be on a Seamonkey page?
[20:15] <fta> drop firefox, it's also valid for thunderbird, seamonkey, prism, flock, songbird, and who knows what
[20:15] <gnomefreak> no not all are for the same
[20:15] <asac> fta: for the Packaging page i concur
[20:15] <Jazzva> I'm with asac on this, there are not many info for an actual page, and it already fits in the table layout.
[20:15] <asac> but also for the List page?
[20:15] <Volan1> asac: I mean for extension list... the extensions that work only for FFor for example for FF and Flock and SeaMonkey
[20:15] <gnomefreak> seamonkey extensions may not work with ff i have seena  few of these
[20:16] <asac> Volan1: ok. i think that info could be added to the table
[20:16] <gnomefreak> songbird ones wont work with ff
[20:16] <Volan1> package instruction unified and separeted list can be a solution?
[20:16] <gnomefreak> so instead of bunching them on one page make separate pages
[20:16] <asac> ok. so i think the initial suggestion by jazzva is the one that is best maintainable
[20:16] <asac> e.g. drop firefox from the page name completely
[20:17] <asac> and have an attribute in the table that declares which applications are supported
[20:17] <Jazzva> Maybe we don't need special table for every program. Many extensions work in more than one program. So, it would be easier to track them, if we add a new "works with programs" column
[20:17] <asac> e.g. a new colum
[20:17] <gnomefreak> yes and use ff if the page is a ff related page
[20:17] <asac> Jazzva: ack. thats what i mean
[20:17] <asac> so MozillaTeam/Extensions == the grand unified table page
[20:17] <asac> and MOzillaTeam/Extensions/Packaging == packaging instructions
[20:18] <Jazzva> That's another part of the item :)..
[20:18] <gnomefreak> maybe instead of that why not use a separate heading
[20:18] <asac> gnomefreak: example?
[20:18] <Jazzva> Should we keep MT/Extensions as the homepage with pointers to the other sections, and leave the list apart from that, or to just add the list there?
[20:18] <asac> Jazzva: what other information would we have there?
[20:18] <gnomefreak> heading Thunderbird extensions under it add the same tables that are there
[20:19] <asac> Jazzva: maybe link to packaging, largescalemaintenance, list
[20:19] <gnomefreak> like we did with dont work header and such
[20:19] <asac> Jazzva: ok, i think we have enough to move the list out of that page
[20:19] <Jazzva> asac: That's good. Now that I think of it, only few pointers are needed :)
[20:19] <asac> Jazzva: well. there might be more in future
[20:19] <Jazzva> Right...
[20:20] <asac> there might be various variants, like backports procedure, SRU procedure
[20:20] <asac> and so on
[20:20] <Jazzva> soren, we can go for MT/Ext/List...
[20:20] <asac> Jazzva: yes
[20:20] <Jazzva> autocomplete again, sorry...
[20:20] <fta> lol
[20:20]  * Jazzva turns autocomplete off ...
[20:21] <asac> anyone voluteers to do the renaming of the extension pages
[20:21] <Nafallo> finally :-)
[20:21] <asac> like discussed?
[20:21] <Jazzva> asac: I'll take care of it...
[20:21] <asac> Jazzva: maybe you should glue your finger to not hit "tab" whenver you start an IRC line :)
[20:21] <Jazzva> asac: it autocompletes with "," after first word :)
[20:21] <Volan1> lol
[20:22] <Nafallo> autoautocompletion :-P
[20:22] <Jazzva> I don't know why I turned that on in the first place... stupid thing ... :sighs:
[20:22] <asac> ACTION: jazzva to reorganize extension wiki pages :)
[20:22] <Jazzva> Anyway, anyone have something to add?
[20:22] <asac> if so, lets go for mailing list :)
[20:22] <Jazzva> Or can we move to the next topic :)...
[20:23] <asac> TOPIC: Thunderbird extensions
[20:23] <Volan1> Jazzva: use icons in the copatible program column ;)
[20:23] <asac> i think that topic is not really a topic as everybody concurs that we should have that
[20:23] <gnomefreak> are we getting them?
[20:23] <Jazzva> Volan1, good idea :)...
[20:23] <asac> we already discussed that the information which applications are supported to into a column of the extensions table
[20:23] <gnomefreak> this was talked about at UDS i thought
[20:23] <asac> personally, I'd say we should not start to maintain tbird extensions manually (like we did for ffox3 extensions atm)
[20:24] <shirish> I have a query but don't know if this is time or the place for the same?
[20:24] <gnomefreak> asac: wait for tb3?
[20:24] <asac> but wait till we have the intiial prototype of LargeScaleMaintainence in place
[20:24] <asac> gnomefreak: no. just wait for our support infrastructure to be available
[20:24] <Jazzva> I think it's just a little change to the default XPI.TEMPLATE to get TB extensions to work. If we want, we can setup XPI.TEMPLATE.TB, too...
[20:24] <asac> shirish: we will have "other business" at the end
[20:24] <shirish> ok cool
[20:24] <Nafallo> ububird? :-)
[20:24] <asac> Jazzva: we can think about it :)
[20:24] <Jazzva> Nafallo, lol :)
[20:25] <asac> Jazzva: but i think we can adapt the documentation as required, e.g. once someone starts a tbird extension
[20:25] <gnomefreak> asac: that would than make tbird ext. not to share a page with others since we are gonna have 2 different proceedure pages, a how to build
[20:25] <Jazzva> asac, imagezoom is a TB extension too, and I'm maintaining it ;)
[20:25] <asac> gnomefreak: i dont think that the procedures are different enough to justify a separate page
[20:25] <fta> i agree
[20:26] <asac> yeah. so imagezoom already supports thunderbird
[20:26] <gnomefreak> in other words keep build instrucions/help pages separate if they are not the same
[20:26] <asac> Jazzva: but you already know how to do it :) ... so you probably dont rely on the docs ;)
[20:26] <Jazzva> (that is, if I included that patch... I think I did, if not I have to :))
[20:26] <gnomefreak> as in it uses a separate XPI template
[20:26] <asac> gnomefreak: if they are different enough
[20:26] <Jazzva> (nope, it's gonna be sorted in next upload)
[20:26] <gnomefreak> ick patching extesions?
[20:26] <asac> gnomefreak: in our case we can better add a few example lines in the template rules:
[20:27] <gnomefreak> asac: true
[20:27] <asac> ok. so the only action i see is to improve the XPI.TEMPLATE to also cover thunderbird
[20:27] <asac> is that right?
[20:27] <asac> and once there is demand add a section about thunderbird to the Packaging page
[20:27] <Jazzva> Yep. And document that on Packaging wiki page
[20:28] <gnomefreak> since they dont use a patch system at all and are relativly nothing to hem why patch it instead add fixes to upstream builds and make a diff for upstream to add
[20:28] <asac> ok, i volunteer to do that :)
[20:28] <Nafallo> no ububird? :-(
[20:28] <asac> ACTION: asac to add thunderbird examples to XPI.TEMPLATE and document that on Packaging page :)
[20:28] <asac> Nafallo: thats not on the agenda (yet) :)
[20:28] <asac> ok lets see
[20:28] <Nafallo> hehe :-)
[20:28] <asac> anything else to add for thunderbird extensions?
[20:29] <Volans> sorry for my ignorance but now an extension compatible both with FF and TB necessite 2 different source packages?
[20:29] <asac> Volans: no. thats not always true
[20:29] <gnomefreak> Nafallo: good idea as long as its not added to suggestions since apt now installs suggestions
[20:29] <asac> Volans: there are extensions like imagezoom that work in tbird + ffox
[20:30] <asac> the intersection of thunderbird vs. firefox extensions should be quite small though ... more probably exist for seamonkey vs. firefox
[20:30] <fta> adblock+ works almost everywhere
[20:30]  * Nafallo stabs apt
[20:30] <Jazzva> Volans, and it will depend on firefox | firefox-3.0 | firefox-2 | thunderbird... that way dependencies are sorted out. If user has TB, it will install
[20:30] <gnomefreak> asac:  as i understand there are char. limits that is liked in packaging ext. we should really raise them
[20:30]  * shirish loved apt
[20:30] <Jazzva> the extensions, and will not complain if no FF package is present
[20:30] <Volans> Jazzva and asac thankd for the clarification
[20:30] <Jazzva> np :)
[20:30] <asac> ok
[20:31] <asac> gnomefreak: can we discuss that in #ubuntu-mozillateam later?
[20:31] <asac> otherwise lets move on ...
[20:31] <asac> TOPIC: Meetings
[20:31] <gnomefreak> asac: sure that was just a comment. it may not be today unless i get pcs wprking
[20:31] <fta> asac, maybe we can rely on mozilla-devscripts to install the links to the various extensions dirs, instead of have to that in each ext
[20:31] <asac> SUMMARY: We should have a meeting at least once a month or whatever we can decide on. This will help in membership approval as well as keeping everyone updated and keeping our support docs up to date. Once a month is just a suggestion.
[20:31] <asac> fta: we already do that
[20:32] <gnomefreak> asac: atleast once a month and always a week or 2 after UDS
[20:32] <asac> fta: we could try to introduce more automation
[20:32] <asac> gnomefreak: you think its realistic to have monthly meetings?
[20:32] <asac> a month is quite short.
[20:32]  * gnomefreak trying to think of best times to meet about current devel ect
[20:32] <asac> I'd be happy to do that, but someone needs to organize them :)
[20:32] <gnomefreak> asac: im thinking about it atm
[20:33] <gnomefreak> asac: maybe when we reach a certain amount of agenda points?
[20:33] <asac> if we have monthly meetings then i dont think we need special meeting after UDS
[20:33] <Jazzva> brb
[20:33] <gnomefreak> asac: thats why im thinking about it
[20:33] <asac> gnomefreak: well. imo we should try to get a regular meeting in place
[20:33] <Volans> proposal: once a month if there is something in the agenda...
[20:33] <gnomefreak> maybe every 6 weeks
[20:33] <Nafallo> gnomefreak: +1
[20:33] <asac> yeah, problem is that people are always lazy to add agenda items
[20:33] <asac> even though there are things to discuss
[20:34] <asac> so Id like to get a regular schedule
[20:34] <gnomefreak> that will give us enough time to get what this meeting needs done
[20:34] <asac> 6 weeks sounds reasonable
[20:34] <asac> anyone disagrees?
[20:34] <Volans> +1
[20:34] <shirish> +1 on that
[20:34] <asac> who volunteers to prepare the schedule for the next half year or so?
[20:34] <gnomefreak> EVERYONE  add points to agenda as you think of them please
[20:34] <asac> and get that on the fridge and wiki?
[20:34] <gnomefreak> this way its not thrown together like this time
[20:34] <asac> at best the same person would send multiple reminders as well :)
[20:35] <gnomefreak> asac: set it on wiki and i will get it on  fridge 2 weeks before meeting
[20:35] <Volans> asac: what permission are needed to set meetings?
[20:35] <asac> like 2 weeks in advance "early" notice to mailing list .... 1 week and a day before meeting to mailing list and all team members :)
[20:35] <gnomefreak> asac: i can do that as normal
[20:35] <Jazzva> _1
[20:35] <Jazzva> +1
[20:35] <asac> Volans: none. you need to fridge admins to add them
[20:35] <asac> i never did that ;)
[20:35] <gnomefreak> i had one ready to send to planet but sister came down and i forgot
[20:35] <asac> gnomefreak is probably the best candidate; anyone wants to be his backup?
[20:35] <Nafallo> topic here as well I guess. or is that automagic?
[20:35] <Volans> if nobody can I can help for that
[20:36] <asac> Nafallo: thats the meeting bot
[20:36] <asac> Nafallo: depends on what you got added to the fridge calendar
[20:36] <Nafallo> shiny :-)
[20:36]  * gnomefreak has a few people i talk with regularly from fridge dev tema
[20:36] <asac> Volans: ok thanks
[20:36] <gnomefreak> asac:  was the bot fixed to post minutes?
[20:36] <asac> ACTION: gnomefreak and Volans to create meeting schedule for next 6 month and take care of getting those meeting on fridge and sending preannouncements :)
[20:37] <asac> gnomefreak: no the bot is gone today :(
[20:37] <asac> gnomefreak: i wanted to use the MootBot, but it disappeared
[20:37]  * gnomefreak wonders if its worth looking into
[20:37] <asac> gnomefreak: we should
[20:37] <gnomefreak> asac: it didnt post minutes anyway
[20:37] <asac> gnomefreak: yes, but TOPCIS and ACTIONS
[20:37] <asac> and so on
[20:37] <asac> not tha bad
[20:37] <asac> and logs afaik
[20:38] <gnomefreak> we need a place to post them and than i will talk with the admins of it to see if we can add plugins on where to post them
[20:38] <asac> gnomefreak: ok. mayber suggest your findings on mailing list once you have options :)
[20:38] <gnomefreak> asac: ok that works
[20:38] <asac> ok
[20:38] <asac> lets move on :)
[20:38] <asac> TOPIC: Large scale Extensions - Next steps
[20:38] <gnomefreak> whos is htat?
[20:39] <gnomefreak> that?
[20:39] <Nafallo> asac
[20:39] <asac> i think there is not much to say exept that its not yet ready and that we will keep you updated on mozillateam mailing list
[20:39] <asac> maybe a reminder to subscribe to that list if you havent done so yet
[20:39] <gnomefreak> asac: what is it?
[20:39] <asac> its really low traffic
[20:39] <gnomefreak> what list?
[20:39]  * gnomefreak so lost
[20:39] <asac> gnomefreak: mt list
[20:39] <asac> gnomefreak: https://wiki.ubuntu.com/MozillaTeam/Firefox3Extensions/LargeScaleMaintenance
[20:40] <asac> i talked a bit about this in the beginning of this meeting
[20:40] <asac> gnomefreak: maybe read the log of this channel
[20:40] <Nafallo> baah. low traffic is what they all say in the beginning, then you have to change MUA to keep up :-P
[20:40] <asac> Nafallo: look at the stats
[20:40] <asac> its like 15 mails a month or so
[20:40] <gnomefreak> ah ok
[20:41] <Jazzva> asac, 15 mails/month is a lot of traffic afaics ;)
[20:41] <gnomefreak> Nafallo: pretty much 1 topic every couple of months
[20:41] <asac> https://lists.ubuntu.com/mailman/listinfo/ubuntu-mozillateam
[20:41] <asac> Jazzva: you must be kidding
[20:41] <asac> Jazzva: a lot in terms of MT mailing list :)
[20:41] <asac> https://lists.ubuntu.com/archives/ubuntu-mozillateam/2008-June/thread.html
[20:41] <asac> thats june so far
[20:41] <asac> quite active
[20:41] <asac> month
[20:41] <asac> https://lists.ubuntu.com/archives/ubuntu-mozillateam/2008-May/thread.html
[20:41] <Jazzva> Oh, my... didn't notice :)
[20:41] <asac> may was more silent :)
[20:42] <gnomefreak> asac: ok work needs to be done on that wiki
[20:42] <gnomefreak> ?
[20:43] <gnomefreak> before its ready for wide spread?
[20:43] <asac> gnomefreak: you mean largescale maintenance?
[20:43] <asac> it needs to be updated while we implement it
[20:43] <asac> its not ment to be wide spread
[20:43] <gnomefreak> asac: yes that would e it
[20:43] <gnomefreak> be
[20:43] <asac> gnomefreak: i think that document is not ment for consumption by extension maintainers
[20:44] <gnomefreak> widespread as in people using it to help with our extensions
[20:44] <asac> its more ment to outline the details of what needs to be done from a technical pov
[20:44] <gnomefreak> what is it for than?
[20:44] <shirish> gnomefreak: thanx, for I haven't been able to understand much of it. +1 on cleaning up LargeScaleMaintainance Wiki
[20:44] <gnomefreak> ah ok
[20:44] <asac> once its working we will have to udpate the Packaging page to reflect the new workflow
[20:44] <gnomefreak> ok i see what you are doijng now
[20:44] <asac> shirish: its not ment for consumption by package maintainers
[20:44] <gnomefreak> thanks
[20:45] <asac> shirish: the packaging page will have the high-level view onto the semi-automatic workflow
[20:45] <gnomefreak> shirish: its a behind the seans for outlines until posted to the packaging ect... pages
[20:45] <asac> s/seans/scenes/ :)
[20:46] <gnomefreak> yeah that thanks brain fart
[20:46] <asac> so to summarize this agenda item:
[20:46] <gnomefreak> oh asac if i find out that network manager is causing my issues im gonna fly to where you are with my pcs and tell you to fix :(
[20:47] <asac> next steps are: finish the largescalemaintenance infrastrcuture
[20:47] <shirish> couldn't that be worked with having some nice illustration perhaps? Would make sense to some more people perhaps?
[20:47] <asac> then document high-level view of workflow in Packaging
[20:47] <asac> shirish: the high-level view?
[20:47] <gnomefreak> \sh: for what?
[20:47] <gnomefreak> damn
[20:47] <gnomefreak> shirish: ^^^
[20:47] <asac> shirish: i think having illustratinos would be helpful :)
[20:47] <asac> to illustrate the workflow
[20:47] <asac> but someone has to do that ;)
[20:48]  * gnomefreak can help someone once they decide what they want
[20:48] <gnomefreak> but i will not take lead on that
[20:49] <gnomefreak> too much to do with wikis as is
[20:49] <asac> gnomefreak: shirish: lets defer the Packaging documetnation details until we are doing them :)
[20:49] <gnomefreak> asac: +1
[20:49] <asac> ok, i think we have two items left on agenda :)
[20:49] <Jazzva> I can help with picking out the packaging related details from LargeScaleMaintenance and copying them to Packaging :)
[20:49] <Jazzva> Yay :)
[20:49] <asac> TOPIC: Extension Team Marketing
[20:49] <asac> is anyone here who likes to blog?
[20:49] <asac> :)
[20:49] <gnomefreak> oh crap thats gonna be fun
[20:50] <gnomefreak> asac: i blog more than most
[20:50] <Jazzva> asac, from time to time... When I get an idea ;)
[20:50] <asac> wat i have in mind is to post monthly reports on the extension packaging process
[20:50] <gnomefreak> if someone writes an outline of what they want i can edit and post
[20:50] <asac> what
[20:50] <asac> for that we have to find someone who publishes them
[20:50] <gnomefreak> asac: monthly?
[20:50] <asac> and more importantly we need to decide on what metrics to include in that report
[20:51] <gnomefreak> my blog is connected to ubuntu planet
[20:51] <Jazzva> Well, would be good if blog has Planet Ubuntu access...
[20:51] <asac> my initial suggestion would be:
[20:51] <Jazzva> gnomefreak, yay :)
[20:51] <asac> 1. extensions updated this month
[20:51] <asac> 2. new extensions suggested this month
[20:51] <asac> 3. new extensions released this month
[20:51] <asac> 4. extensions that need to be updated (here a list to the extensions that have a new upstream version)
[20:51] <gnomefreak> Jazzva: can you outline a page or a set of notes on the suggestions from asac
[20:52] <Jazzva> gnomefreak, ok. I will tell you when I'm done :)
[20:52] <gnomefreak> thanks
[20:52] <asac> 5. total extensions maintained by m-e-d
[20:52] <Jazzva> np :)
[20:52] <asac> any other metrics?
[20:52] <Volans> asac: for me +1, very complete stats
[20:52] <gnomefreak> Jazzva: im gonna need a few days atleast to fix PCs and hav e abirthday to myself
[20:52] <Jazzva> 6. don't hesitate to join the team and help out ;)
[20:52] <asac> we could also include a "medal of honour"  :)
[20:53] <asac> for the m-e-d member that updated most packages :)
[20:53] <Nafallo> asac: sounds like UWN material :-)
[20:53] <gnomefreak> asac: that looks good  and add section for Jazzva idea
[20:53] <gnomefreak> Jazzva: do we have a wiki on joining the team?
[20:53] <asac> Jazzva: yeah. we should include a link to our team and some nice docs in the report
[20:53] <Nafallo> at least part of that
[20:53] <Jazzva> gnomefreak, no, we formed the requirements on this meeting, and it will be turned into a wiki page
[20:53] <asac> Nafallo: yeah. UWN could definitly republish it
[20:54] <gnomefreak> who can script for greasemonkey? offtopic i know
[20:54] <gnomefreak> Jazzva: thanks :)
[20:54] <asac> ACTION: write scritps that gather stats for 1. 2. 3. 4. 5.
[20:54] <asac> fta: ?
[20:54] <asac> i guess your script is already prepared  for some of those :)
[20:54] <asac> (e.g. extensions that need updated=
[20:54] <Volans> asac: written in what languages?
[20:54] <asac> Volans: for now i wouldnt pitch too high :)
[20:55] <Nafallo> Volans: ASM ;-)
[20:55] <Volans> thanks Nafallo
[20:55] <asac> Volans: english ... and if there are volunters feel free to translate and publish in other forums
[20:55] <fta> asac, yes, but that will change. it was a quick hack in shell.
[20:55] <fta> yet, it was enough to impress Jazzva ;)
[20:55] <gnomefreak> asac: scripts for what?
[20:55] <Volans> asac: sorry, I meant "script language" ;)
[20:55] <asac> we could also use the launchpad blog
[20:55] <shirish> guys, what is the mozillateam's take on other browsers? Are they part of mozillateam or not?
[20:55] <Jazzva> fta, the output was cool :P
[20:56] <gnomefreak> your points dont need scripts do they?
[20:56] <asac> e.g. m-e-d team blog
[20:56] <asac> ACTION: gnomefreak to blog about stats
[20:56] <Jazzva> fta, and the script looked impressive :). I'm no good at scripting... :)
[20:56] <gnomefreak> shirish: depends on what ones you mean
[20:56] <asac> ACTION: figure out if we can blog on launchpad :)
[20:56] <fta> gnomefreak, no, but a script to gather those stats for you would definitely help
[20:56] <Volans> for the maketing side of the stats the e-m-d start page should have an introduction that explain what the team do, hoiw to join, etc...
[20:56] <gnomefreak> asac: atm no you cant
[20:56] <Jazzva> asac, I think we can blog on LP.
[20:56] <gnomefreak> fta: right
[20:56] <gnomefreak> Jazzva: i havent found a way
[20:57] <gnomefreak> we can talk to #lp about that
[20:57] <asac> Volans: so maybe add a MozillaExtensionDevTeam page?
[20:57] <gnomefreak> they are helpful
[20:57] <Jazzva> gnomefreak, I'll take a look. I read an announcement for that feature
[20:57] <shirish> gnomefreak: say all the browsers which are mentioned therein www-browser package
[20:57] <gnomefreak> Jazzva: thanks i only saw mailing list from lp updated lately
[20:58] <fta> asac, ok for this ACTION. anyway, it will come with the rest
[20:58] <gnomefreak> shirish: no we cant as desktop team has thier own that they maintain i think epiphany is released by gnome anyway
[20:58] <asac> fta: right. but some hackish stats so we can start thigs month would be great :)
[20:58] <shirish> gnomefreak: thanx
[20:58] <gnomefreak> we need to find out what vrowsers and who maintains them atm but dont get hopes up
[20:58] <Volans> asac: also yes, or /MozillaTeam/Extension/Team page
[20:58] <asac> ACTION: target initial m-e-d report for end of July (or if we are good June)
[20:59] <gnomefreak> shirish: can you make a list and push talk to mailing list
[20:59] <asac> Volans: ++
[20:59] <shirish> gnomefreak: sure +1 say tomorrow or day after, but can definitely do that
[20:59] <Volans> or DevTeam
[20:59] <asac> ACTION: someone to create a /MozillaTeam/Extensions/Team page that includes a) short intro, b) requirements to join (as discussed)
[20:59] <gnomefreak> shirish: i wont get to see it until as late as thurs\day
[21:00] <fta> asac, ok
[21:00] <asac> ... and links to the most important resources (e.g. Packaging, etc.)
[21:00] <asac> ok anything else to add to this item?
[21:00] <gnomefreak> moday i work on connection tuesday is birthday so im off and  wednesday i take grandmother to hospital for tests
[21:01] <Volans> maybe we can use gobby for write those wikis all togheter
[21:01] <gnomefreak> we should really add links to the other pages on the joining team pages
[21:01] <asac> Volans: not sure. gobby is useful if you write while discussing
[21:01] <asac> Volans: for that we would need to organize wiki sessions ;)
[21:01] <asac> for me it works to just use editmoin :)
[21:02] <gnomefreak> +1 asac
[21:02] <Volans> ok
[21:02] <gnomefreak> i wget the page and edit it alot
[21:02] <gnomefreak> that way i dont lock the wiki up
[21:02] <asac> yes, editmoin works quite well here ... maybe test that package
[21:02] <asac> lets move on :)
[21:02] <asac> (2h already)
[21:02] <gnomefreak> last item?
[21:02] <asac> i see two topics left: 1. Proposed members for Ubuntu-MozillaTeam
[21:02] <asac> 2. Otherw Business :)
[21:03] <gnomefreak> go to l2 first
[21:03] <Volans> I can help for those pages but not for texts (due to my not so good english ;))
[21:03] <gnomefreak> i want smoke
[21:03] <asac> gnomefreak: i think there are a lot of people waiting for an accept/decline.
[21:03] <asac> TOPIC: Proposed members for Ubuntu-MozillaTeam
[21:03] <gnomefreak> asac: we need to remove them if they dont answer the post we give them
[21:03] <asac> we have one candidate for this meeting
[21:03] <gnomefreak> but how long to give them to reply?
[21:03] <asac> Stephen Lau
[21:03] <asac> steveA[A[A[A[A
[21:03] <asac> steveups
[21:04] <gnomefreak> is he here?
[21:04] <asac> i think he is flock upstream
[21:04] <gnomefreak> we dont have flock yet
[21:04] <gnomefreak> are we adding it to intrepid?
[21:04] <asac> in general i would be fine to add upstreams to mozillateam if they maintain their own packaging branch
[21:04] <fta> (i hope so)
[21:04] <asac> but i think he didnt do that yet
[21:04] <gnomefreak> asac: agreed
[21:04] <Jazzva> asac: +1
[21:05] <gnomefreak> upstream should be accepted
[21:05] <asac> ok, so decline his application asking him to actively contribute to packaging for some time
[21:05] <asac> he could help fta with packaging flock for instance
[21:05] <gnomefreak> asac: lets  find out how upstream he is
[21:05] <asac> fta: do you want to carry that message to him?
[21:05] <asac> gnomefreak: he is flock (or songbird)
[21:05] <asac> fta: ?
[21:06] <gnomefreak> example what he does and last fix he produced
[21:06] <Jazzva> asac, Songbird... that's what his wiki page says
[21:06] <gnomefreak> as in is he workoing the front or is he bug working....
[21:06] <asac> ah ok
[21:06] <asac> fta: do you want to mentor stevel?
[21:06] <Jazzva> asac, actually Songbird Developer Advocate... dunno what that actually means :)
[21:07] <fta> he helped me once, to triage some error messages from Songbird, but that hardly qualified for membership imho
[21:07] <gnomefreak> songbird devs we need badly. for example the license issue with songbird been worked out?
[21:07] <gnomefreak> fta: agreed
[21:07] <asac> fta: ok. i think we should explain to him that he needs to contribute as ~mozillateam only makes sense if he needs write access to branches
[21:07] <asac> fta: and that we would be willing to help him get started on packaging if he still is interested :)
[21:08] <gnomefreak> asac: sounds good but i would love to not run him off if possible
[21:08] <fta> asac, i agree
[21:08] <asac> fta: nevertheless, he can just stay in channel and contribute without being member
[21:08] <asac> at some point we could setup a team: "mozillateam-supporters" :)
[21:08] <gnomefreak> atleast as upstream contact
[21:08] <asac> or mozillateam-community ;)
[21:09] <gnomefreak> atleast as upstream contact)
[21:09] <asac> where everyone who feels the need to be affiliated with Mozillateam can join without requiring active packaging work
[21:09] <gnomefreak> ;)
[21:09] <shirish> +1 on that ;)
[21:09] <gnomefreak> and we move them as we see fit
[21:09] <asac> gnomefreak: right
[21:09] <gnomefreak> move up to kmain team
[21:09] <gnomefreak> -k
[21:09] <Nafallo> asac: he can branch and poke for merge is he needs write access :-)
[21:10] <gnomefreak> lets get us fixed first
[21:10] <asac> ACTION: setup mozillateam-community team and add applicants that do not need branch access or havent otherwise contributed considerably to mozillateam
[21:10] <gnomefreak> we have alot of work to do as it is trying to reconfig our team
[21:10] <asac> mozillateam itself as well as m-e-d should be part of tha team Id say
[21:10] <gnomefreak> yes
[21:10] <fta> +1
[21:10] <asac> gnomefreak: we dont need to reconfig our team
[21:10] <Jazzva> +1 on the idea, it's nice :)
[21:11] <gnomefreak> before that can happen we need to fix our membership pages to have a process
[21:11] <asac> ok great :)
[21:11] <gnomefreak> other wise we have nothing for that team
[21:11] <asac> i think we are through this lengthy, but fruitful agenda :)
[21:11] <asac> next topic would be "Other Business" :)
[21:11] <gnomefreak> who can work on the membership pages for e-d and mt
[21:11] <Jazzva> Other business? :)
[21:12] <Jazzva> asac, oh, right :)
[21:12] <gnomefreak> asac: we need to break that down to topics for next meeting
[21:12] <shirish> I'm all out of stuff
[21:12] <gnomefreak> i think that is there as a guide
[21:12] <asac> gnomefreak: i think we already have an action for the m-e-d page
[21:12] <shirish> so will see u all l8ter guys
[21:12] <asac> gnomefreak: the mozillateam page can stay the same
[21:12] <asac> shirish: thanks!
[21:12] <shirish> bye all :)
[21:12] <Jazzva> Have fun, shirish :)
[21:12] <gnomefreak> asac: ok than i will remove david version 2 from it and clean it up (i havent looked at it in awhile)
[21:13] <asac> gnomefreak: we can add the info that applicants that dont qualify for mozillateam will be automatically redirected to mozillateam-community
[21:13] <gnomefreak> ok
[21:13] <gnomefreak> i like it
[21:13] <asac> ACTION: asac to document redirection procedure to mozillateam-community on mozillateam membership page
[21:13] <asac> TOPIC: other business
[21:13] <asac> anything?
[21:13] <gnomefreak> should we have a LP mailing list for the communtiy team?
[21:13] <asac> gnomefreak: for now mozillateam should be enough
[21:13] <gnomefreak> ok
[21:14] <asac> i have one thing for other businesses: minutes ;)
[21:14] <asac> can someone please safe the log of this channel in case ubuntulog failed?
[21:14] <Jazzva> asac, gnomefreak: Maybe we could have a separate LP list and to post announcements like "New FF is in the archive"?
[21:14] <asac> s/safe/save/
[21:14] <asac> Jazzva: we could also use LP blog for that
[21:14] <Jazzva> asac, I do the auto-logging ;)
[21:14] <asac> Jazzva: good
[21:15] <fta> me too
[21:15] <asac> so given that we get a complete log from this meeting, is there anyone who can write up minutes from this meeting?
[21:15] <Jazzva> asac, gnomefreak: As for the blog, I took a quick look through mail archive, haven't found that announcement...
[21:15] <gnomefreak> Jazzva: we need to see if we can blog on LP first i would think instead of list for the moment
[21:15] <asac> its mostly just pasting TOPICS + ACTIONS
[21:15] <gnomefreak> Jazzva: see  #launchpad tomorrow :)
[21:15] <asac> and maybe take a brief look if there are actions we didnt mark as ACTIONS :)
[21:16] <Jazzva> asac, if no one wants to, I'll do it...
[21:16] <Jazzva> gnomefreak, k
[21:16] <gnomefreak> are we done with meeting?
[21:16] <asac> gnomefreak: almost :)
[21:16] <asac> just need a minutes drafter.
[21:16]  * gnomefreak needs to figure this crap out
[21:16] <asac> Jazzva: would be great. but just a brief notes thing
[21:16] <asac> for details just attach the log
[21:16] <Jazzva> asac, cool :)
[21:17] <gnomefreak> be back in a few
[21:17] <asac> we can blog(announce)
[21:17] <asac> https://edge.launchpad.net/firefox-extensions/+announce
[21:17] <asac> its per-team, but per projet
[21:17] <asac> so most likely the drafter of announcements must be driver for that project
[21:17] <asac> or something
[21:17] <fta> "Sorry, you don't have permission to access this page. "
[21:17] <Jazzva> The same...
[21:18] <asac> fta: ok good. can you test on xulrunner project?
[21:18] <asac> fta: try now please
[21:18] <asac> i made mozillateam the driver
[21:18] <asac> Jazzva: ^^
[21:18] <fta> same
[21:18] <Jazzva> nada...
[21:19] <asac> ok let me flip the maintainer then
[21:19] <asac> Jazzva: fta: better?
[21:19] <Jazzva> works now
[21:19] <asac> good. so apparently only the maintainer can post blog entries for the project
[21:19] <asac> fine
[21:19] <asac> i think firefox-extensions news could go through that project for now
[21:20] <Jazzva> Would be good if we could have that function for teams :).
[21:20] <asac> and aggregated on our blogs (e.g. mine, gnomefreaks)
[21:20] <asac> Jazzva: right
[21:20] <Jazzva> Is it possible to be added? Just to know if it's ok to post a bug report :)
[21:20] <asac> Jazzva: well ... why not
[21:20] <asac> Jazzva: open a bug and subscribe me to it
[21:20] <asac> and let me know :)
[21:20] <Jazzva> Sure
[21:20] <asac> so i can confirm this request
[21:21] <asac> "e.g. Please support Team announcements"
[21:21] <asac> ok any other business?
[21:21] <asac> 3
[21:21] <asac> 2
[21:21] <asac> 1
[21:22] <asac> thanks for the last 2.5 hours ;)
[21:22] <asac> was nice to have a meeting again!
[21:22] <Jazzva> Yep... good job :D
[21:22] <asac> if there are open points you felt not be properly dealt with, go ahead and mail mailing list :)
[21:23] <Jazzva> See you in #ubuntu-mozillateam :)
[21:23] <asac> see you
[21:23]  * asac takes a short break
[21:28] <Volans> see you


[09:12] <qbd> hello Odd_Bloke, just some feedback here that removing the 'groups' for that borg user worked and I can now login
[09:18] <qbd> what would be the recommended way to assemble a two disk mdadm raid0 array using cloud-init ?
[12:14] <kryl> Hi, is it possible to have "conflict" between cloud.conf and configs in cloud.cfg.d/* files ?
[12:14] <kryl> I want to debug what's happening? I put files in this directory but I didn't get any actions.
[12:40] <meena> kryl: if there was a conflict, you should have gotten an error
[13:01] <kryl> meena, I hope, but where :-p It will be cool to "debug" cloud-init files before to launch them in a blind server without KVM.
[13:16] <kryl> is there a module to setup "locales" in debian/ubuntu systems ?
[13:16] <kryl> or a place where I can find existing modules ?
[14:21] <Odd_Bloke> kryl: Check out https://cloudinit.readthedocs.io/en/latest/topics/modules.html
[14:22] <Odd_Bloke> (More specifically: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#locale)
[15:59] <Odd_Bloke> smoser: Thoughts on https://bugs.launchpad.net/cloud-utils/+bug/1912904?
[16:00] <Odd_Bloke> Seems like a reasonable addition to me, but I'm not familiar with how cloud-localds is used (or if we already have a way of doing this).
[16:12] <Krikke> there's an option to add ssh keys in the user config
[16:12] <Krikke> users.ssh_authorized_keys
[16:13] <Krikke> though I'm using terraform to include the file
[16:14] <Krikke> https://github.com/ixevix/bootstrap-vm-terraform-libvirt
[16:25] <kryl> I can setup locale module in cloud_config_modules section in cloud.cfg, but what about adding locale: ar_AE as an example. Do I need to write that in cloud.cfg.d/xxx.cfg ? or I can add them in cloud.cfg directly (before or after cloud_config_module section ?)
[16:26] <kryl> Odd_Bloke, I saw it but it's not so clear. And what about UTF8 ?
[16:27] <minimal> Odd_Bloke: its writing a complete user-data file so only really of use to people to already creating their own user-data with more contents. I'd expect the majority of people using an ISO for cloud-init would be specifying more things in their user-data
[16:27] <minimal> s/people to already/people not already/
[16:27] <kryl> I'm wondering what's the best option to run "ansible" local playbooks. I saw there is something for chef, puppet, saltstack ... but nothing for ansible actually.
[16:41] <Odd_Bloke> minimal: So I do think there's a set of people who want to debug An Image, but have never heard of cloud-init; they want a way to backdoor it, and nothing more.
[16:44] <Odd_Bloke> Some of those folks will have figured something out, but others will have been put off by the variety of tools required to just get in.
[16:45] <Odd_Bloke> To be clear, I'm not saying we therefore must include something to cater to them, but I think that's a use-case that we could serve better.
[16:49] <minimal> in the case of that script it'll mean that that defaults will be used for various c-i modules, and (I assume) fallback to DHCP for network as no network YAML specified. No sure what the end result of the various modules' default setting would be.
[16:50] <minimal> i.e. is the result unsafe (is the default account password-less and accessible via SSH? etc)
[17:45] <Odd_Bloke> Hmm, so one consequence that I've noticed of releasing a hotfix upstream release is that the versions produced by our Ubuntu daily builds now sort _lower_ than the versions in the archive.  The 20.4.1 tag isn't in the main branch's history (because it's on a forked branch with only the fix on top of 20.4), so the most recent tag is 20.4.  (And 20.4 < 20.4.1.)
[18:01] <Odd_Bloke> I have some thoughts on how to address this: add an epoch to all of the recipe builds, so this will never be an issue again; or, temporarily prefix the recipe versions with something which will sort them above 20.4.1 which we can drop once 21.1 is out; or, add a tag like "20.4.2-not-really" to HEAD.
[18:01] <Odd_Bloke> (I don't like that last one.)
[18:02] <Odd_Bloke> I've also realised that this means that we presently have an upgrade issue to the devel release: as 20.4.1 > 20.4, the 20.4 snapshot in hirsute will not be upgraded to.
[18:03] <Odd_Bloke> (We'll release and upload 21.1 before hirsute releases, so this won't be an issue by release time/FF.)
[18:04] <blackboxsw> Odd_Bloke: So I'm wondering as well in the future we we actually don't bump the 20.4.X revision but instead just bump ~18.04.2
[18:04] <blackboxsw> that way the extra releases into ubuntu/xenial|bionic|etc don't actually cause concern versus the upstream daily recipe builder
[18:05] <Odd_Bloke> blackboxsw: I think we want it to be very clear that the Ubuntu stable releases have a bugfix that was important enough to merit an upstream hotfix release.
[18:05] <powersj> then why not call it 21.1 or 20.5
[18:06] <powersj> when we choose semantic-like versioning we said the .x, x would increment as we did releases. I'd need to look, but I don't think we talked much about doing patch versions
[18:06] <blackboxsw> In this case we didn't go through an official upstream release in master, just hotfix releases direct to the ubuntu/<series> branches
[18:07] <powersj> ah
[18:07] <Odd_Bloke> powersj: I think we'd have this same problem: the 21.1 or 20.5 tags would still not be in history.
[18:07] <blackboxsw> so daily build recipes wouldn't "see" that release tags
[18:07] <powersj> yeah
[18:07] <blackboxsw> ... on master
[18:08] <Odd_Bloke> And 20.4.1 _is_ an official upstream release, but it was a cherry-pick directly on top of 20.4 to minimise the delta to the one required by the fix.
[18:08] <Odd_Bloke> (If this had been Ubuntu-only, we'd have cherry-pick'd into the release branches and this would be a non-issue.)
[18:10] <blackboxsw> right... I'm not quite sure what to do in this particular case. I'm trying to wrap my head around the epoch suggestion to walk through version matrix fallout.
[18:12] <blackboxsw> Odd_Bloke: and at the moment new-upstream-snapshot releases into hirsute will still be something like 20.4-71-ga9c904dc-0ubuntu1 so we'd have to change our tooling too
[18:12] <blackboxsw> right?
[18:12] <blackboxsw> because we need hirsute releases to be 20.4.1-71......
[18:13] <rick_h> Is this an issue because once we cut a release we've not revved to the next release? For instance, once 20.4 was cut daily should have been a pre-release of 21.1? 21.1-alphaX maybe?
[18:26] <kryl> Please how to use metadata variables (from ec2) I can get them well listed with cloud-init query ds.... but I want to use them to setup my hostname :-) I tryied with runcmd and {{ varName }} but it doesn't work ! I put this config in cloud.cfg.d directory
[18:26] <kryl> it looks simple but I don't understand why to use an external script who will parse again the metadata url ?
[18:32] <blackboxsw> Correct me please Odd_Bloke: this is an issue because we hotfixed a release (20.4 + a single cherrypick) as 20.4.1 directly into ubuntu/<release> branches. Master never saw this upstream release tag 20.4.1 because the commit that we added to master to revert happened along with a bunch of other commits so tagging that "release 20.4.1" would not be representative in master of what was hotfixed into
[18:32] <blackboxsw> ubuntu/<release>
[18:39] <blackboxsw> kryl: you'll need to provide a ## template: jinja line at the beginning of the #cloud-config that you provide to declare your cloud-config userdata as a template that needs var substitution.
[18:40] <kryl> before or after #cloud-config ?
[18:40] <blackboxsw> kryl: you can check on your booted system `sudo cloud-init query userdata` to see if the first line has that header  Example here https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html#using-instance-data
[18:40] <kryl> I don't provide them as global config it's just additionals files in cloud.cfg.d directory
[18:41] <blackboxsw> kryl: ahh hrm checking that approach
[18:42] <kryl> one more question this module: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#resolv-conf won't work for debian sys in any way ?
[18:42] <blackboxsw> I'm not certain if we handle jinja template processing of separate cloud.cfg.d files but I'm checking now.
[18:42] <kryl> alright
[18:43] <blackboxsw> kryl: what's your file content in /etc/cloud/cloud.cfg.d/<custom>.cfg
[18:43] <blackboxsw> if you can share some of it
[18:44] <blackboxsw> https://paste.ubuntu.com is a good sharing tool if needed
[18:52] <kryl> something like that : https://paste.ubuntu.com/p/jvdwt9KM4Q/
[18:52] <kryl> and preserve_hostname must be at false.. but it's not the pb here.
[18:53] <blackboxsw> kryl: I'm still checking about inability to provide ## template: jinja in cloud.cfg.d custom config files. But minimally you could provide an /etc/cloud/cloud.cfg.d/99-myname.cfg like the following: https://paste.ubuntu.com/p/vVsPyM5X5Q/
[18:54] <blackboxsw> generally ## template: jinja has to be before #cloud-config
[18:55] <kryl> got it for usage of cloud-init app
[18:55] <kryl> thank you
[18:59] <blackboxsw> kryl: would you please file a short bug/feature request for supporting jinja templates in /etc/cloud/cloud.cfg.d files? I think that would be a useful feature. : https://bugs.launchpad.net/cloud-init/+filebug.
[19:00] <kryl> ok I'll do that tomorrow
[19:00] <blackboxsw> kryl: also if your images provide any config directives on disk (like runcmd) note that any user specifying their own runcmd in #cloud-config at launch time will drop any config options on disk
[19:00] <blackboxsw> thanks kryl
[19:00] <blackboxsw> will override the config you provided on disk and prefer the runcmd that the admin launching the VM provided instead.
[19:03] <kryl> any idea what about resolv_conf module ?
[19:03] <kryl> I'm wondering if it will apply on debian sys because in the documentation it seems to be dedicated to other OS
[19:21] <Odd_Bloke> blackboxsw: rick_h: So for our daily build versioning, we don't do "next release minus", we do "last release plus"; this is easier to do in LP recipe builds (because it can use git tags to determine "last release"; there's no canonical source of "next release" available there).
[19:22] <blackboxsw> kryl: in the docs generally we don't recommend using this module on Debian as network configuration should really be handled /etc/network/interfaces configuration which is handled properly by systemd-resolved services on the system. So, I believe that config module is disallowed on debian/ubuntu to allow the network and DNS rendering backplane to render the right config from a single source of truth.
[19:22] <Odd_Bloke> So yeah, the problem is that "20.4 plus" sorts lower than "20.4.1".
[19:23] <kryl> blackboxsw,ok thank you for your search
[19:24] <Odd_Bloke> But to get recipes to build with "pre-release" versioning, I think we'd have to manually modify the recipes after each release, rather than them just rolling forward automatically with no intervention.
[19:24] <blackboxsw> kryl: I say that with too many words and I might be incorrect. but generally I think there are enough networking edge-cases on Debian and Ubuntu with using cc_resolve_conf that using the primary network config files /etc/network/interfaces or /etc/netplan/* (or metadata services providing network_confing) are the preferred mechanism to describe such DNS config
[19:24] <blackboxsw> kryl: np
[19:25] <kryl> IT's for a special use case, I have to prevent dhcpclient (used from ENI / debian) to change the file resolv.conf... :-) and ideally fix it manually, maybe with cloud-init
[19:27] <Odd_Bloke> blackboxsw: There's an upstream/20.4.1 branch: https://github.com/canonical/cloud-init/tree/upstream/20.4.1
[19:27] <Odd_Bloke> Perhaps we should just merge that back into master?
[19:30] <Odd_Bloke> A quick test indicates that would solve the problem: https://paste.ubuntu.com/p/5CBN49kPjw/
[19:32] <Odd_Bloke> (And that is what you do with hotfix branches in gitflow, at least.)
[19:33] <kryl> I have to leave, GL for next steps ;)
[19:43] <blackboxsw> Odd_Bloke: confirmed. I think merging your upstream/20.4.1 will bump our version in master above 20.4 based and it'll pull in that annotated tag that'll get our `git describe` reporting properly
[19:44] <blackboxsw> only interesting caveat with that is that our git descr offset will not really be comparable in master vs ubuntu/X|B|F series really
[19:45] <blackboxsw> let me rethink that last statement of mine as I don't think that is actually true...
[19:45] <Odd_Bloke> Only until 21.1, then everything will be realigned, I think.
[19:46] <blackboxsw> Odd_Bloke: +1 on that. once 21.1 annotated upstream tag is cut in master all alignment of git describe commit offsets from a given signed tag will be properly aligned. I'm checking ubuntu/xenial's git desc vs master and also what happens with next new-upstream-snapshot
[19:52] <blackboxsw> Odd_Bloke: ok, so +1 on git merge origin/upstream/20.4.1 into master. I'd like us to augment that commit message though with the reason for why we now have the merge marker ,accounting for the hotfix release that needed to by sync-d "up" into master. Does that make sense?
[19:53] <blackboxsw> because I know future-me isn't going to remember why specifically we approached this in master "next time"
[19:54] <blackboxsw> Odd_Bloke: it might also be worth us noting "hotfix" procedure in https://github.com/canonical/uss-tableflip/blob/master/doc/ubuntu_release_process.md or https://github.com/canonical/uss-tableflip/blob/master/doc/upstream_release_process.md
[19:56] <blackboxsw> Odd_Bloke: one issue is that git describe on ubuntu/xenial is currently 20.4.1-426-gb889283c which will still sort higher than master at 20.4.1-72-g28cb7f03  right?
[19:57] <blackboxsw> I presume though, that our daily build recipe will actually just bump the base version 20.4 to 20.4.1 for all ubuntu releases. So maybe this is a non-issue https://code.launchpad.net/~cloud-init-dev/+archive/ubuntu/daily
[19:58] <blackboxsw> because daily recipes are still building {latest-tag}  which will change/increment from 20.4 -> 20.4.1 for all builds
[20:01] <Odd_Bloke> blackboxsw: The version we need to care about isn't the one that `git describe` in ubuntu/xenial produces, but the version in xenial itself (which is the version in debian/changelog in ubuntu/xenial: 20.4.1-0ubuntu1~16.04.1).
[20:05] <rick_h> Odd_Bloke:  looking at the CLA process, do you recall what's meant by the "Please add the Canonical Project Manager or contact"? Is that meant for the group signings using the same form vs individual contributor?
[20:06] <rick_h> oh lol it's in the doc, nvm
[20:09] <blackboxsw> blackboxsw: +1. Ok you are right  daily recipes to construct their own deb versioning based in {latest-tag}-{revno} sort of like `git describe` behavior (though through launchpad build recipes. So `git describe` not used for daily PPA builds. And for our real releases, right we rely on debian/changelog solely for that published version. new-upstream-snapshot creates that debian/changelog version.
[20:09] <blackboxsw> Odd_Bloke: ^ oops. I'm talking to myself again
[20:10] <blackboxsw> so as long as we are cognizant of new-upstream-snapshot release on next xenial/bionic/etc upload we need to make sure we are still dropping the <patchrev> version from 21.1.<patchrev> during that upload if new-upstream-snapshot isn't smart enough on that front
[21:56] <Odd_Bloke> OK, so unless someone objects before tomorrow, I'm going to get Rick to lift the squash-only requirement on the cloud-init repo for long enough for us to merge the upstream/20.4.1 branch into master.  It has to be a _merge_ (rather than a squash) to get the 20.4.1 tag into master's history, which fixes `git describe` (and by extension Ubuntu daily builds).  (It also represents what happened: we briefly
[21:56] <Odd_Bloke> forked cloud-init for a release; that fork has now been reintegrated into master.)