On 03/06/2017 12:15 AM, Barry Warsaw wrote: > There are lots of good reasons for that. I think most importantly is that if > a last minute RC bug were to pop up, no one wants to have to figure out (or > worse, debug) a new maintenance workflow in order to fix that critical > problem.
If such thing happened, I don't think it's such a huge issue to just fix the RC bug and upload, then figure out how to commit later on. Because of the freeze, the change will be minimal anyway. > But that only gates flag day. Any switch of this nature requires a lot of > work before flag day. Look at the switch from svn to git, Stefano did a huge > amount of testing and development to get us to that point, with lots of test > migrations, feedback, etc. Kudos to him for the tenacity and dedication to > the team on that. A huge +1 for the kudos to Stefano and yourself for this indeed. > Let's look at the switch from git-dpm as an example. We *know* there are > challenges in that conversion; I've experimented with it as have others, and > it's not a trivial operation. So we need one or a few dedicated people to > investigate all the technical details of such a switch. What are the steps > needed to convert an individual package? How and when will we convert all > team packages? What exactly will the new workflow look like? Does the wiki > page accurate describe all the common tasks that team members will need to > perform? Is there a test conversion that people can try out? Where are the > scripts to do the conversion so others can contribute? What is the process > for providing and addressing feedback as people test it? What's the timeline, > and when is flag day? I agree it's not trivial. > I think one of the problems specifically with getting rid of git-dpm is that, > while the tool is deprecated and there are known problems, it actually kind of > works pretty well for us. svn clearly was breaking down, but from a global > team point of view, git-dpm is still almost good enough, so the urgency to > switch hasn't been there. Here, I don't agree. but YMMV, I guess. Maybe there's no point discussing the urgency! :) > But we need volunteers to say "I am going to do the hard work to > make the conversion happen". And of course we're all busy, and it's a > thankless job (but thank you Stefano for your previous work!). So that's why, > IMHO, the git-dpm conversion hasn't happened yet. > > If we're just not going to find the round tuits to do the conversion before > then, this would make for a very suitable collaboration for a team Debconf > sprint. I'm hereby volunteering for such a sprint (if I hopefully make it to Montreal). Hopefully, migrating from git-dpm to git-pq wont be as hard as from SVN to Git. > CI/CD, automated testing, etc. cannot just happen by fiat. They may be great > ideas we can adopt, but *a lot* of hard work and dedicated time goes into > making sure the technology can handle things, but also, and more importantly > IMHO to make sure that everyone on the team knows how it works, understands > and can help debug any problems, knows where the well-written documentation > is, etc. We need dedicated people to help people on IRC and email when they > get stuck or have a problem. And we have to consider the needs of those for > whom contribution to DPMT is not a full-time job. I already talked and wrote about it, I would very much like a packaging CI/CD to be deployed for Debian. However, I'm scared to attempt doing it by myself only. I don't want to become a single point of failure. Cheers, Thomas Goirand (zigo)