16:31:31 <terceiro> #startmeeting
16:31:31 <MeetBot> Meeting started Fri Apr  3 16:31:31 2020 UTC.  The chair is terceiro. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:31:31 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:31:45 <terceiro> #topic roll call
16:31:55 <terceiro> hello, welcome to the Ruby team meeting
16:31:59 <terceiro> say hi if you are around
16:32:01 <boutil> hi there!
16:32:03 * utkarsh2102 waves
16:32:05 * kanashiro waves
16:32:09 <Manaskashyap[m]> hi
16:32:12 <uwabami> hi
16:32:17 * dleidert waves
16:32:35 <terceiro> uwabami: thanks for staying up so late! :)
16:32:44 <Duck> Unit193: quack
16:32:51 <Duck> quack folks
16:32:56 <Duck> sooo sleepy
16:33:10 <uwabami> terceiro: you'are welcome
16:33:12 <terceiro> Duck you are awake pretty late too
16:33:25 <kanashiro> hey Duck, try not to sleep during the meeting :)
16:33:36 <terceiro> I hope everyone is safe and healthy
16:33:39 <utkarsh2102> Keep quackin' ;)
16:33:41 <Duck> I'm already half sleeping :-)
16:33:46 <srud[m]> Hi
16:33:51 <PiratePraveen[m]> hi
16:33:51 <Duck> usually I can stay longer but...
16:34:22 <terceiro> let's go
16:34:34 <terceiro> #info meeting agenda is at https://pad.riseup.net/p/ruby_team_irc_metting_20200403
16:34:35 <peoplesmic> Riseup Pad (at pad.riseup.net)
16:34:51 <terceiro> #topic default branch protection in the salsa
16:35:11 <terceiro> should the default branch protection in the salsa ruby-team be changed to half-protection
16:35:11 <terceiro> background: developers can create repos but not push to them (example @hacks-guest)!
16:35:11 <terceiro> pro: allows maintainers and developers push access
16:35:11 <terceiro> pro: prevents force-push for both
16:35:11 <terceiro> alternatively:
16:35:12 <terceiro> create ruby-team/wnpp namespace
16:35:14 <terceiro> lower default branch protection here fully
16:35:15 <terceiro> developers can create reps
16:35:17 <terceiro> if one gets uploaded to NEW, move it to ruby-team (dev will already have permissions then)
16:35:19 <terceiro> we collect unused ITP/RFP attempts in one place and don't pollute ruby-team
16:35:25 <terceiro> dleidert: I think this item is yours?
16:35:28 <dleidert> yes
16:35:59 <terceiro> FWIW I think your proposal makes sense
16:36:05 <dleidert> background is, that our developers can create repos, but cannot push to them. We can either remove their abilityx to create repos or lower the protection or do something else
16:36:53 <dleidert> The wnpp idea has the background, that we currently have ~20 repos with packaging attempts which are several years old
16:37:09 <PiratePraveen[m]> ruby-team/mentors ? as it is mostly for new
16:37:13 <dleidert> so we could collect these efforts, see developers work ...
16:37:20 <dleidert> I'd fine with that too
16:38:47 <terceiro> does anyone disagree, or have questions?
16:38:50 <boutil> will everybody (even "owners") push new repos there until they hit the archive?
16:39:02 <PiratePraveen[m]> as these are not work needing (wn of wnpp)
16:39:09 <boutil> if yes, then "wnpp" is more suitable than "mentors"
16:39:27 <dleidert> nope. I'd say that maintainers onwards, being able to create repos and push, have enough reponsibility, no?
16:39:42 <PiratePraveen[m]> boutil I don't think that is required
16:39:49 <boutil> ok, then "mentors" is fine indeed
16:39:58 <boutil> I think it is a great move forward
16:40:15 <dleidert> so let deveopers put their ITPs/RFPs in mentors then?
16:40:30 <terceiro> fine by me
16:40:58 <dleidert> Then we should remove the ability for developers to create repos in ruby-team
16:41:36 <PiratePraveen[m]> dleidert only ITPs how would RFP work there?
16:42:10 <terceiro> from the point of view of who is packaging, aren't ITP and RFP the same thing?
16:42:20 <Duck> fine
16:42:28 <dleidert> I'd say that every Maintainer or owner is suaully working on smething he plans to upload. So there is not much risk that we end up with orphaned repos in ruby-team. I'd suggest that only for developers
16:43:08 <dleidert> so for example hacksk[m] could have created his repos there and push to them
16:43:08 <Duck> only for developpers or that's going to be annoying
16:43:19 <PiratePraveen[m]> terceiro not how I think about it, RFP is usually when you cannot package it
16:43:40 <Duck> yep, RFP is when you ask others to do it
16:43:43 <PiratePraveen[m]> and ITP when you are planning to
16:43:48 <Duck> Request
16:43:56 <Duck> vs. Intent
16:44:32 <utkarsh2102> P.S. someone will need to take care of the VCS fields accordingly..
16:44:33 <terceiro> I know
16:44:43 <dleidert> I think, if owners or maintainers pick up an RFP, they can do this in ruby-team's main namespace, because they usually pick this up to upload it.
16:45:19 <kanashiro> +1
16:45:37 <PiratePraveen[m]> there is no repo for rfp and you are supposed to retitle rfp to itp when you start working on it
16:45:42 <dleidert> utkarsh2102: not really. If the package gets uplaoded to new, just move it into the main namespace.
16:45:53 <boutil> VCS should be the expected final location, right?
16:46:05 <dleidert> boutil: yes, that's how I see it
16:46:34 <kanashiro> PiratePraveen[m], the RFP itself should be sent to the mailing list, there is no need for a git repo
16:46:44 <PiratePraveen[m]> utkarsh2102 vcs filed can just remain the same always like how people have it in personal name space too - the field it still ruby-team
16:47:17 <terceiro> maybe we don't have to think about all of the small details now, and agree on the general direction?
16:47:26 <PiratePraveen[m]> kanashiro yes, that is what I'm saying too
16:47:27 <dleidert> +1
16:47:37 <kanashiro> if a git repo is needed is because the RFP became an ITP
16:48:45 <dleidert> However: we still need to decide if we want to lower the protection to half-protected (push allowed, force-push not allowed), because our developers currently cannot push to any package repository, independent if in Debbian, ITPed or RFPed
16:48:53 <terceiro> so do we agree on this: NEW packages from recent team members (developers in salsa terms) should go into ruby-team/mentors/; developers should have permission to create repos there
16:48:55 <sbadia> hi here! (sorry for the delay…)
16:49:08 <PiratePraveen[m]> like saying upload to mentors.debian.net, we can say upload to salsa.debian.org/ruby-team/mentors
16:49:21 <dleidert> terceiro +1
16:49:47 <boutil> terceiro +1
16:49:48 <Duck> terceiro: we can try that and adjust if it does not work well but seems fine
16:49:50 <kanashiro> +1 on terceiro's proposal
16:50:22 <PiratePraveen[m]> dleidert I think we can give people maintainer access to specific repos than lowering requirement
16:50:35 <terceiro> #agreed NEW packages from recent team members (developers in salsa terms) should go into ruby-team/mentors/; developers should have permission to create repos there
16:50:41 <terceiro> PiratePraveen[m]: yes!
16:50:54 <terceiro> #info we can always raise the privilege of developers to maintainer on specific repos
16:51:10 <terceiro> now, on the question of the default branch protection
16:51:25 <terceiro> half-protected looks good to me. what do people think
16:51:26 <terceiro> ?
16:51:40 <boutil> preventing force-push is good
16:52:04 <dleidert> half-protect does not allow force-push
16:52:12 <boutil> half-protected seems the right setting
16:52:17 <dleidert> but allows developers to push to master
16:52:22 <PiratePraveen[m]> I think giving maintainer access to specific repos is better than removing protected branch
16:52:47 <dleidert> maintainers can always push (just not force-push)
16:52:48 <PiratePraveen[m]> dleidert why? when we can give for specific repos
16:52:58 <dleidert> True
16:53:30 <dleidert> Say you upload hacksk[m] packages you would adjust the protection settings for him?
16:53:49 <dleidert> ... for the affected packages
16:54:12 <PiratePraveen[m]> dleidert yes, I do that always
16:55:13 <boutil> I am fine with either choice, as long as *I* can push :)
16:55:29 <terceiro> heh
16:55:35 <Duck> it depends how open we're with unsuppervised outside contribs. I think teams usually expect people to join but liking the id of the 'debian' group (how was it called already), I wonder…
16:55:49 <PiratePraveen[m]> so when moving from mentors, the access should be updated
16:56:09 <terceiro> do we agree on half-protected then?
16:56:28 <kanashiro> yep
16:56:29 <Duck> fine
16:56:31 <dleidert> I think PiratePraveen[m] is vorting for full-protection
16:56:49 <boutil> PiratePraveen[m]: it seems to me to be more bureaucraty than we actually need
16:56:49 <PiratePraveen[m]> #info when moving a package from mentors, the access should be adjusted so they can push to master
16:57:08 <Duck> to me too much ACLs are a barrier to contributions
16:57:31 <boutil> upload + moving from mentors + adjusting ...
16:57:55 <dleidert> full protection: devs cannot push new commits, maint can. No force-push or delete for both.
16:58:20 <dleidert> half protect: devs and maint can push new commits, neither can force-push or delete
16:59:01 <boutil> I think half-protect is safe, and "welcoming"
16:59:20 <terceiro> seems easier, and safe enough
16:59:24 <kanashiro> I am fine trusting developers
16:59:26 <Duck> boutil: :-)
16:59:28 <terceiro> half-protected I mean
16:59:42 <PiratePraveen[m]> I think when someone is trusted, they should be made a maintainer
16:59:54 <dleidert> so practically with lowering the protection devs could import new versions, could change master and upstream
17:00:56 <terceiro> PiratePraveen[m]: do you have strong feelings against half-protected?
17:01:03 <PiratePraveen[m]> but if I'm the only one wanting this way, I'll not press it any more
17:01:40 <dleidert> Well I feel with PiratePraveen[m] a bit. Some dev could import a major update and push it
17:01:46 <Duck> I would prefer NMUs to be uploaded in the repo too than having to be done when the maint or a owner thinks about it later on
17:02:12 <dleidert> ... and we would have to clean up
17:02:49 <kanashiro> dleidert, valid point
17:03:00 <terceiro> well, I think it's less work to clean up an eventual mistake than to remember to give the right permissions to every repo
17:03:17 <boutil> terceiro: agreed.
17:03:20 <PiratePraveen[m]> terceiro like I said if most people think it is safe, then lets do it
17:03:40 <boutil> remember our alioth times, when everybody could force-push
17:03:45 <boutil> and we survived :)
17:03:52 <dleidert> We can certainly try and adjust our course if some incident happens
17:03:52 <Duck> PiratePraveen[m]: what's canonical is the archive, not the repo, and any DD can upload anyway
17:04:33 <boutil> (maybe not everybody... but still!)
17:04:38 <PiratePraveen[m]> Duck we can easily make DDs maintainers
17:05:11 <PiratePraveen[m]> even DMs
17:05:16 <terceiro> do we agree on: team packages should have branch protection set to "half-protected" by default
17:05:18 <terceiro> ?
17:05:26 <boutil> terceiro: +1
17:05:31 <Duck> terceiro: ok
17:05:42 <kanashiro> +1
17:05:45 <dleidert> Well the ideal solution would be tp protect upstream, not master, so only maintainers upwards could import new upstream version. I don't see master a scritical because devs are usually not DMs or DDs
17:05:46 <boutil> I would not have liked, when I started to ask permission for every repo I touched
17:06:19 <boutil> * when I started contributing,
17:06:23 <PiratePraveen[m]> terceiro +0 not too strong objection
17:06:49 <dleidert> Honestly I'm fine with both. We can always adjust
17:06:50 <Duck> PiratePraveen[m]: I think every DD has already some XP and should reasonnably be trusted, a DM usually not much yet, or is here infrequently, so I would nto go that far
17:07:20 <terceiro> I think we are mostly arguing over a non-issue TBH
17:07:28 <PiratePraveen[m]> boutil well you could get maintainer access after a few repos so you won't have to asks any more
17:08:08 <terceiro> #agreed team packages should have branch protection set to "half-protected" by default
17:08:19 <terceiro> let's move on to the next topic
17:08:26 <terceiro> #topic info about attic movement
17:08:44 <terceiro> #info we now have a ruby-team/attic namespace
17:09:03 <terceiro> #info packages removed from the archive should be moved to ruby-team/attic
17:09:06 <terceiro> anything else?
17:09:21 <dleidert> I moved >100 packages to attic
17:09:31 <boutil> dleidert: thanks!
17:09:37 <dleidert> packages not in oldoldstable or newer anymore have been archived
17:09:47 <dleidert> so they are not shown by default
17:10:16 <kanashiro> dleidert, thanks for your work! I saw some people discussion about an script to do it automatically, am I right?
17:10:45 <Duck> arf, I have one I was working on but… got delayed let's say
17:10:52 <dleidert> there is a tool in the teams meta repo called' attic' which creates the branches debian/jessie, debian/stretch and debian/buster if the packages is still there and then moves the repo into attic
17:10:59 <terceiro> Duck: you can always move it back
17:11:13 <Duck> of course /o\
17:11:36 <dleidert> and another tool mv-to-attic-and-archive, which simply moves a repo to attic and archives it
17:12:09 <dleidert> At some day I'll rewrite them in Ruby ;)
17:12:32 <terceiro> it's not in ruby? how dare you
17:12:45 <Duck> we can only read Ruby, how are we going to maintain them? /teasing
17:12:51 <kanashiro> thanks dleidert, it is good to have these details in the meeting minutes for future reference :)
17:13:17 <dleidert> It was easier for me to do this quickly in shell/bash :)
17:13:17 <terceiro> #info new script: mv-to-attic-and-archive
17:14:01 <terceiro> #info new script: attic
17:14:21 <terceiro> dleidert: again thanks for your efforting in organizing our beloved mess!
17:14:30 <terceiro> can we move on?
17:14:41 <dleidert> No problem. I love cleaning :)
17:14:45 <terceiro> we are already at 45 min, it would be nice to keep it under 1h
17:14:47 <dleidert> sure
17:15:05 <Duck> !next
17:15:23 <terceiro> #topic repos for packages that were never uploaded
17:15:36 <terceiro> question: Should packages in ruby-team, which have not been uploaded yet and are failry old (several years) be moved to attic or wnpp?
17:15:49 <terceiro> list of packages:
17:15:50 <terceiro> kuniri
17:15:50 <terceiro> pdfwalker
17:15:50 <terceiro> ruby-astrolabe
17:15:50 <terceiro> ruby-bond
17:15:52 <terceiro> ruby-bundler-ext
17:15:52 <terceiro> ruby-chefspec
17:15:55 <terceiro> ruby-cool.io
17:15:55 <terceiro> ruby-fauxhai
17:15:57 <terceiro> ruby-fileutils
17:15:59 <terceiro> ruby-goldiloader
17:16:03 <terceiro> ruby-gtkhex
17:16:05 <terceiro> ruby-idn
17:16:07 <terceiro> ruby-inspec
17:16:09 <terceiro> ruby-mathgl
17:16:11 <terceiro> ruby-numo-narray
17:16:13 <terceiro> ruby-require-all
17:16:15 <terceiro> ruby-ruby2-keywords
17:16:17 <terceiro> ruby-rubyipmi
17:16:19 <terceiro> ruby-sphinx
17:16:21 <terceiro> ruby-spinach
17:16:23 <terceiro> ruby-statsample
17:16:25 <terceiro> ruby-stemmer
17:16:27 <terceiro> ruby-sys-admin
17:16:29 <terceiro> ruby-totoridipjp
17:16:31 <terceiro> ruby-twitter4r
17:16:35 <terceiro> rumember
17:16:37 <terceiro> taskwarrior-web
17:16:39 <terceiro> transrate
17:17:12 <dleidert> boutil created two of them, which are empty. The rest are repos create dseveral years ago without an upload or any recent work
17:17:21 <kanashiro> I think we can leave attic just for packages that were in the archive at some point
17:17:36 <boutil> pdfwalker is a piece of origami-pdf that has been split
17:17:36 <dleidert> I was wondering if I can/should move them to attic or into mentors (wnpp)
17:17:52 <boutil> mine could be deleted (since they are empty)
17:17:53 <terceiro> indeed pdfwalker is needed
17:18:12 <PiratePraveen[m]> dleidert may be a new namespace
17:18:14 <terceiro> ruby-ruby2-keywords too
17:18:23 <PiratePraveen[m]> as it does not fit either
17:18:24 <sbadia> I'll move copy taswarrior-web in the dedicated team https://salsa.debian.org/tasktools-team (but anyway taskwarrior-web is unmaintained)
17:18:25 <peoplesmic> Debian Tasktools Team · GitLab (at salsa.debian.org)
17:18:29 <boutil> I could (re)push them
17:18:43 <PiratePraveen[m]> abandoned ?
17:19:11 <dleidert> sorry, I just recreated the list today. A very few might be false-positoves. I checked most last night and most of them are years old
17:19:37 <dleidert> I'd never move them without re-checking
17:19:44 <terceiro> dleidert: maybe you can post to the mailing list, and we revisit them next meeting?
17:19:51 <Duck> so the package I was talking about earlier is in this case (spoolinger) but not listed
17:20:06 <boutil> terceiro: +1
17:20:11 <dleidert> Sure. Can we agree to put them into mentors and archive the oldest for those we agree to move?
17:20:17 <kanashiro> +1 to send and email about it and let interested people show up
17:20:44 <dleidert> Duck: I have an ignore list attic-ignore.list in the team's meta repo. I checked *all* packages without a result from rmadison
17:21:08 <PiratePraveen[m]> dleidert move them to mentors only if someone is ineterested
17:21:16 <dleidert> Otherwise?
17:21:33 <terceiro> 🔥 :-)
17:21:39 <kanashiro> leave them as is for now? until the next meeting
17:22:13 <dleidert> terceiro: I have destroying other people's work
17:22:15 <Duck> dleidert: thanks :-)))
17:22:24 <dleidert> That's why I'd like to archive unused ones
17:22:29 <terceiro> dleidert: yeah sure, joking
17:22:31 <dleidert> s/have/hate/
17:22:32 <Duck> well it works at least in stable as it's DuckCorp production stuff
17:22:35 <PiratePraveen[m]> dleidert create abandoned namespace or simple delete them
17:22:50 <terceiro> moving is better indeed
17:22:57 <terceiro> I would agree with a abandoned namespace
17:23:38 <terceiro> agree? old repostories, never uploaded should be moved to a ruby-team/abandoned namespace
17:23:52 <dleidert> +1
17:23:54 <Duck> ok
17:23:56 <boutil> ok
17:24:05 <PiratePraveen[m]> or orphaned
17:24:12 <terceiro> #agreed old repostories, never uploaded should be moved to a ruby-team/abandoned namespace
17:24:18 <PiratePraveen[m]> more in line with debian terminology
17:24:37 <terceiro> #action dleidert to post to the mailing list with the proposal list of abandoned packages
17:24:53 <terceiro> #info we will revisit the list of abandoned packages in the next meeting
17:24:56 <terceiro> next?
17:25:18 <PiratePraveen[m]> or it could be confusing, abandoned is better
17:25:44 <Duck> !next
17:26:36 <terceiro> #topic dh_ruby removed built extension in ruby-http-parser when using --gem-install -> Bug?
17:27:02 <terceiro> dleidert: this is actually a bug in ffi-compiler, I provided a patch which utkarsh2102 alteady uploaded
17:27:10 <dleidert> Yeah. We probably don't have to discuss this now. I just hjit us yesterday. We can leave this to the list
17:27:10 <terceiro> that needs to be sent upstream at some point
17:27:27 <dleidert> terceiro: nope, dh_ruby actually deleted it when using --gem-install
17:27:41 <terceiro> dleidert: no, it wasn't deleted
17:28:02 <terceiro> ffi-compiler never installed it to the right location
17:28:09 <dleidert> You are talking about something else.
17:28:24 <terceiro> you mean it deleted the file you insatlled by hand in debian/rules?
17:29:09 <dleidert> No. utkarsh2102 first tried the --gem-install layout and there dh_ruby --install simply deleted the file
17:29:31 <terceiro> maybe we can skip all items that should be made into bug reports, and just discuss what we need to decide together as a team
17:29:37 <dleidert> So we commented out DH_RUBY in d/rules and went with the vendor layout. Then those things happened you were part of
17:29:59 <dleidert> Yes. I'm fine with that. We can discuss these things on the list
17:30:25 <terceiro> the next 2 items should also be bug reports
17:30:33 <dleidert> ack
17:31:02 <terceiro> #topic Wiki updates
17:31:06 <terceiro> who added it?
17:31:34 <dleidert> Me too. Nothing serious. Just apointer
17:31:39 <terceiro> Wiki
17:31:39 <terceiro> -https://wiki.debian.org/Teams/Ruby/Packaging#Handling_of_shebangs
17:31:39 <terceiro> remove ruby-interpreter here
17:31:39 <terceiro> https://wiki.debian.org/Teams/Ruby/Packaging#Updating_a_package_to_a_newer_version
17:31:40 <terceiro> git push --all --follow-tags (pushes tags with commits)
17:31:40 <terceiro> git config --global push.followTags true (sets this behavior by default)
17:31:40 <peoplesmic> Teams/Ruby/Packaging - Debian Wiki (at wiki.debian.org)
17:31:41 <peoplesmic> Teams/Ruby/Packaging - Debian Wiki (at wiki.debian.org)
17:31:43 <terceiro> https://wiki.debian.org/Teams/Ruby/IRCMeetings
17:31:44 <peoplesmic> Teams/Ruby/IRCMeetings - Debian Wiki (at wiki.debian.org)
17:31:44 <terceiro> revive the site?
17:31:52 <dleidert> Should this be revived? https://wiki.debian.org/Teams/Ruby/IRCMeetings
17:31:57 <terceiro> probably yes
17:32:05 <terceiro> utkarsh2102: can you look into it?
17:32:24 <terceiro> do we have a volunteer to do the necessary updates?
17:32:55 <utkarsh2102> shall do if nobody steps up :)
17:33:00 <dleidert> I'll do the first two. Maybe utkarsh2102 can care about IRCMettings
17:33:06 <terceiro> nice
17:33:17 <dleidert> We should probably update the site a sa whole
17:33:30 <terceiro> #action dleider to update Teams/Ruby/Packaging wiki page
17:33:47 <terceiro> #action utkarsh2102 to update Teams/Ruby/IRCMeeting wiki page
17:34:01 <terceiro> yes, please just do it
17:34:15 <terceiro> wikis are great but needed maintainance
17:34:33 <terceiro> #topic handling transitions
17:34:56 <terceiro> #link https://wiki.debian.org/Teams/Ruby/Packaging#Updating_packages_with_API_breaking_changes
17:34:57 <peoplesmic> Teams/Ruby/Packaging - Debian Wiki (at wiki.debian.org)
17:35:11 <terceiro> PiratePraveen[m]: is there anything that we need to decide about this *now*?
17:35:38 <PiratePraveen[m]> terceiro we decide on the list as well
17:35:47 <PiratePraveen[m]> if something needs to be changed in what I wrote
17:37:06 <terceiro> ok, thanks
17:37:06 <terceiro> #topic Rails 6 transition: when to upload to unstable?
17:37:06 <terceiro> I would say, just after ruby-defaults finished
17:37:06 <terceiro> #topic Rails 6 transition
17:37:47 <PiratePraveen[m]> terceiro +1
17:38:01 <terceiro> anyone against that?
17:38:05 <Duck> well
17:38:15 <Duck> redmine is not ready
17:38:25 <PiratePraveen[m]> kanashiro Duck ?
17:38:31 <terceiro> Duck: how long do we wait for it?
17:38:35 <Duck> and 4.2.0 does not seem to be happening very soon unfortunately
17:39:04 <Duck> still 86 issues, so that's going to take more time
17:39:07 <terceiro> darn, web apps are supposed to move too fast. now I'm consused -_-
17:39:38 <PiratePraveen[m]> one option is to embed rails 5 in redmine
17:40:02 <Duck> OMG, there's a task for migration I missed: https://www.redmine.org/issues/29914
17:40:04 <peoplesmic> Feature #29914: Migrate to Rails 6 - Redmine (at www.redmine.org)
17:40:22 <Duck> but I think 4.2.0 should be enough to work
17:40:56 <Duck> terceiro: sorry, no idea about the delay
17:41:02 <PiratePraveen[m]> we did that in gitlab with rails 5.0 when we already uploaded 5.1 which broke gitlab
17:41:03 <kanashiro> Duck, maybe we need to live with redmine broken in unstable and out of testing for some time?
17:41:24 <PiratePraveen[m]> and gitlab took a long time to catch up
17:41:40 <Duck> if we do that then we are not able to update bpo
17:42:11 <Duck> so this litteraly means we stop all work on redmine until 4.2.0 is out at least
17:42:19 <PiratePraveen[m]> kanashiro embedding rails 5 ?
17:43:06 <Duck> is there no other blockers really?
17:43:47 <PiratePraveen[m]> gitlab in experimental is already using rails 6
17:44:28 <kanashiro> the other app is open-build-service. I personally don't have time to work on that right now and I am not using it anymore, so it'd depend on Andrew Lee's effort
17:44:47 <Duck> if we go through then I'd like 4.0.6 to be in bpo first, because this version works well
17:46:02 <kanashiro> ok, so we work on redmine 4.0.6 until ruby transition ends and after that we can move forward with rails 6 transition
17:46:09 <kanashiro> sounds good Duck? ^
17:46:44 <Duck> kanashiro: that means: please do upload 4.0.6-2 to bpo, as I still cannot do it myself, sorry
17:47:08 <Duck> sounds terrible but I understand the need to go on
17:48:03 <terceiro> so can Duck and kanashiro coordinate with srud[m] utkarsh2102 PiratePraveen[m] on when to upload rails 6?
17:48:13 <kanashiro> Duck, I'll move this backport up in my priorities
17:48:13 <Duck> yes Sir
17:48:44 <terceiro> #agreed Duck and kanashiro will coordinate with srud[m] utkarsh2102 PiratePraveen[m] on when to upload rails 6, right after the ruby-defaults transition is done
17:48:49 <terceiro> and finally
17:49:05 <terceiro> #topic Ruby 2.7 transition status
17:49:15 <terceiro> kanashiro: go
17:49:44 <Duck> hum: https://www.redmine.org/issues/31500
17:49:46 <peoplesmic> Feature #31500: Ruby 2.7 support - Redmine (at www.redmine.org)
17:49:52 <Duck> also 4.2.0
17:50:03 <kanashiro> we have 2 packages that still need a rebuild against the new ruby-defaults: weechat and passenger
17:50:24 <kanashiro> weechat I already provided a patch here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954789
17:50:26 <Duck> I guess for redmine we can also do the same thing
17:50:27 <peoplesmic> #954789 - weechat FTBFS against ruby 2.7 - Debian Bug report logs (at bugs.debian.org)
17:50:50 <kanashiro> and for passenger we need some investigation, it is failing only in armel and armhf
17:51:21 <terceiro> kanashiro: wrt the ruby-bootsnap, we need to add Breaks: to ruby
17:52:44 <kanashiro> terceiro, there is no way to trigger autopkgtest of rails related packages with ruby-bootsnap from unstable?
17:53:57 <terceiro> kanashiro: there is, Breaks:
17:54:01 <terceiro> :)
17:54:16 <terceiro> Breaks: ruby-bootsnap (<< VERSION_IN_SID)
17:54:44 <PiratePraveen[m]> testing-proposed-updates? I guess it is not encouraged
17:55:09 <terceiro> is there anything we need to decide as a team?
17:55:23 <utkarsh2102> yes
17:55:30 <terceiro> on this topic?
17:55:31 <utkarsh2102> Ruby 2.7.1 is out.
17:56:00 <utkarsh2102> Should I update it? :)
17:56:07 <kanashiro> let's first make 2.7 migrate and then we can think about that
17:56:07 <terceiro> not before the transition ends
17:56:16 <dleidert> on this topic: the list at https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-ruby-extras-maintainers@lists.alioth.debian.org&tag=ruby2.7-transition is almost done. But some packages require attention.
17:56:18 <peoplesmic> User pkg-ruby-extras-maintainers@lists.alioth.debian.org — Debian BTS Usertag Browser (at udd.debian.org)
17:56:25 <utkarsh2102> of course
17:59:17 <terceiro> I think we are done
17:59:20 <terceiro> 1.5h already
17:59:30 <terceiro> #endmeeting