Re: RFS: golang-github-rivo-tview
On Thursday, 27 September 2018 3:50:04 PM AEST Jongmin Kim wrote: > So I did name it 'debian/sid'. You did nothing wrong I see... But IMHO DEP-14 is such a terrible idea that I'll probable leave the team if it is ever going to be enforced... -- Regards, Dmitry Smirnov. --- We do our friends no favors by pretending not to notice flaws in their work, especially when those who are not their friends are bound to notice these same flaws. -- Sam Harris signature.asc Description: This is a digitally signed message part.
Re: RFS: golang-github-rivo-tview
On 27/09/18 08:47, Dmitry Smirnov wrote: > On Thursday, 27 September 2018 3:50:04 PM AEST Jongmin Kim wrote: >> So I did name it 'debian/sid'. > You did nothing wrong I see... > > But IMHO DEP-14 is such a terrible idea that I'll probable leave the team if > it is ever going to be enforced... Dmitry, we had this discussion a long time ago in the team list and in person during DebConf17, and decided to adopt this as policy. It has not been enforced yet due to lack of tooling, but that is the way forward the team has agreed on, as it is a more structured way to deal with multiple releases, have tools do the right thing automatically, etc. I really don't understand why you are so opposed to it, maybe me or somebody else can work with you to ease that feeling? -- Martín Ferrari (Tincho)
Re: how to help with docker.io ?
Reply in-line :- On 27/09/2018, Dmitry Smirnov wrote: > Thanks for forwarding this email to us, Michael. > > We've already exchanged few emails with shirish. > > > On Thursday, 27 September 2018 6:53:11 AM AEST Michael Stapelberg wrote: >> [+cc docker-maint, Arnaud (who did substantial work on docker and its >> dependencies), Dmitry (who last touched the package)] > > Although Arnaud helped a lot, I did substantial work on Docker and its > dependencies (not merely "last touched the package"). > > >> Arnaud, Dmitry, any advice as to how people can best help with docker? > > IMHO most of the effort is with Docker's enormous dependency tree so we > always have to package new dependencies (they keep adding more with every > release, not caring the slightest about code bloat); take care of bugs, > tests > and everything. One have to remember that Docker is more than 100 packages > that need good maintenance hence team effort is the only sustainable way to > > ensure good health of those packages. > > I'm planning to eventually retire from Docker maintenance. > Dear Dmitry, I am open to testing, doing build logs and helping out generally. Anything more than that such as packaging is asking more than I can deliver atm. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Re: how to help with docker.io ?
addition at bottom :- On 28/09/2018, shirish शिरीष wrote: > Reply in-line :- > > On 27/09/2018, Dmitry Smirnov wrote: >> Thanks for forwarding this email to us, Michael. >> >> We've already exchanged few emails with shirish. >> >> >> On Thursday, 27 September 2018 6:53:11 AM AEST Michael Stapelberg wrote: >>> [+cc docker-maint, Arnaud (who did substantial work on docker and its >>> dependencies), Dmitry (who last touched the package)] >> >> Although Arnaud helped a lot, I did substantial work on Docker and its >> dependencies (not merely "last touched the package"). >> >> >>> Arnaud, Dmitry, any advice as to how people can best help with docker? >> >> IMHO most of the effort is with Docker's enormous dependency tree so we >> always have to package new dependencies (they keep adding more with every >> release, not caring the slightest about code bloat); take care of bugs, >> tests >> and everything. One have to remember that Docker is more than 100 >> packages >> that need good maintenance hence team effort is the only sustainable way >> to >> >> ensure good health of those packages. >> >> I'm planning to eventually retire from Docker maintenance. >> > > Dear Dmitry, > > I am open to testing, doing build logs and helping out generally. > Anything more than that such as packaging is asking more than I can > deliver atm. > > > -- > Regards, > Shirish Agarwal शिरीष अग्रवाल > My quotes in this email licensed under CC 3.0 > http://creativecommons.org/licenses/by-nc/3.0/ > http://flossexperiences.wordpress.com > EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 > btw there doesn't seem to any docker-ma...@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo unless somebody wants to revive that list from the defunct group and have it under the alioth-lists.debian.net domain. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8
Re: RFS: golang-github-rivo-tview
On Thursday, 27 September 2018 9:24:40 PM AEST Martín Ferrari wrote: > Dmitry, we had this discussion a long time ago in the team list and in > person during DebConf17 I wasn't part of this discussion (probably being busy working) or I would have opposed it as hard as I could. No DEP-14 please. > and decided to adopt this as policy. What?!? We have to stop this madness. IMHO it is a disservice to team to introduce DEP-14 and a standard practice. > I really don't understand why you are so opposed to it, Because it is a bad idea, inconvenient and time consuming. It improves nothing and makes it mode difficult to maintain packages. Now I have to put on hold everything that have to do and write about it just to prevent it from happening... Why can't we work towards something useful? I'll see if I can put some ideas together in the next few days. I'm very very busy right now... > maybe me or somebody else can work with you to ease that feeling? Don't make it sound like my physiological problem. It is not about feelings. Although I do feel betrayed because someone works behind my back to sabotage what works in practice and replace it with inferior time consuming workflow. -- Regards, Dmitry Smirnov. --- We do our friends no favors by pretending not to notice flaws in their work, especially when those who are not their friends are bound to notice these same flaws. -- Sam Harris signature.asc Description: This is a digitally signed message part.
Re: RFS: golang-github-rivo-tview
On Thursday, 27 September 2018 9:24:40 PM AEST Martín Ferrari wrote: > Dmitry, we had this discussion a long time ago in the team list We briefly discussed in May 2016 and I've said "NO" back then. There were no consensus. > and in person during DebConf17, Where I have not been... > and decided to adopt this as policy. Who decided? How it has been decided? Where this has been recorded? Apparently without announcing that decision? I could find nothing about DEP-14 in this mail list since 2016-05 (until now). It looks like nothing has been decided about DEP-14 as a new standard repository layout for Golang packaging team, fortunately. -- All the best, Dmitry Smirnov. --- Sometimes the first duty of intelligent men is the restatement of the obvious. -- George Orwell signature.asc Description: This is a digitally signed message part.
Adopt DEP-14 branch naming in team workflow
Let's not hijack the RFS thread... On Fri, Sep 28, 2018 at 9:25 AM Dmitry Smirnov wrote: > > On Thursday, 27 September 2018 9:24:40 PM AEST Martín Ferrari wrote: > > Dmitry, we had this discussion a long time ago in the team list and in > > person during DebConf17 > > I wasn't part of this discussion (probably being busy working) or I would > have opposed it as hard as I could. No DEP-14 please. > > > > and decided to adopt this as policy. > > What?!? We have to stop this madness. IMHO it is a disservice to team to > introduce DEP-14 and a standard practice. > > > > I really don't understand why you are so opposed to it, > > Because it is a bad idea, inconvenient and time consuming. > It improves nothing and makes it mode difficult to maintain packages. > > Now I have to put on hold everything that have to do and write about it just > to prevent it from happening... Why can't we work towards something useful? > > I'll see if I can put some ideas together in the next few days. > I'm very very busy right now... > Please do give us some reasons. Just complaining doesn't help... In section 1.4 of https://go-team.pages.debian.net/workflow-changes.html We only adopt the branch naming. The only difference is the master branch now called debian/sid. I don't think that could be such terrible as you described. > > > maybe me or somebody else can work with you to ease that feeling? > > Don't make it sound like my physiological problem. It is not about feelings. > > Although I do feel betrayed because someone works behind my back to sabotage > what works in practice and replace it with inferior time consuming workflow. > -- Shengjing Zhu
Re: DEP-14 branch naming in team workflow
On Friday, 28 September 2018 12:30:13 PM AEST Shengjing Zhu wrote: > Please do give us some reasons. Just complaining doesn't help... Will do. I wish "let's not do it because I don't like it" were enough... > In section 1.4 of https://go-team.pages.debian.net/workflow-changes.html Thanks. But there are more harmful suggestions like using "wrap-and-sort"... So frustrating... > We only adopt the branch naming. The only difference is the master > branch now called debian/sid. I don't think that could be such > terrible as you described. May be not as terrible but certainly not well justified either... The change itself, already introduced to some repositories, causes confusion and inconsistencies as well as inconvenience in GitLab where default branch should be reconfigured. Changing branch naming convention just should not be done without compelling reasons. Current practices are not too bad (not bad enough) to demand changes for vast majority of repositories. "master" as a default branch targeting default upload suite "unstable" is natural and intuitive. There is no need to disrupt that. -- Regards, Dmitry Smirnov. --- What is the truth, but a lie agreed upon. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Re: DEP-14 branch naming in team workflow
FTR, > > and decided to adopt this as policy. > > Who decided? > How it has been decided? > Where this has been recorded? > Apparently without announcing that decision? https://alioth-lists.debian.net/pipermail/pkg-go-maintainers/Week-of-Mon-20170807/014361.html https://alioth-lists.debian.net/pipermail/pkg-go-maintainers/Week-of-Mon-20171016/015809.html And it has a link to the pad, where people have votes on the decisions. https://oasis.sandstorm.io/shared/l4YsLYdwUgnhzzwmKS_TGwWyVQ9Ol8EKiMR8qhpHaS2
