Bug#930619: ITP: michabo -- Qt desktop client for Pleroma and Mastodon

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: michabo
  Version : 0.1
  Upstream Author : kaniini
* URL : https://git.pleroma.social/kaniini/michabo
* License : GPL v3
  Programming Lang: C++/Qt
  Description : Qt desktop client for Pleroma and Mastodon

Michabo is a desktop app for Pleroma and Mastodon servers built with Qt.
It is a lightweight client that uses only 1MB of RAM when not in heavy use.

Re: scratch buildds

[Wouter Verhelst]

On Sat, Jun 15, 2019 at 11:34:19PM +0200, Bernd Zeimetz wrote:
> 
> Hi Chris,
> 
> On 6/15/19 12:28 AM, Chris Lamb wrote:
> > Adam Borowski wrote:
> > 
> >> Thus, what would you guys say about a new distribution, "scratch"?  It 
> >> would
> >> be a kind of extra-experimental that doesn't put its build results anywhere
> >> persistent.  Throwing away built .debs would be ok, keeping just logs.
> > 
> > Perhaps I'm missing something but would introducing more architectures
> > to the salsa.debian.org continuous integrations runners not serve
> > mostly the same purpose? The developer's workflow would simply be to
> > push a commit and it would be built and tested automatically.
> afaik the CI runners use k8s to schedule their work, so I think using
> the default CI stuff from gitlab requires an architecture supported by
> k8s. arm64 is supported and I know that some people cross-compiled k8s
> for mips(el?), but I doubt its widely supported.
> 
> Am I missing something?

No, that's not the case. That is, it is *possible* to use kubernetes to
do GitLab CI, but it is in no way a requirement.

gitlab-runner has various executors to do stuff, and running something
inside docker (with or without kubernetes) is just one of the many
options.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

The Difference between debcheckout and dgit and what they try to accomplish

[Sam Hartman]

I'm trying to organize my thoughts leading towards a discussion about
git on salsa.

Last month we had a wide ranging discussion that started from a
discussion of preferred formats for git branch structure.
During that discussion, we explored the differences in what a tool like
debcheckout gives you vs a tool like dgit.

Here's my understanding of those differences.  I'd appreciate comments
on whether I've accurately understood things as well as more general
comments.


Debcheckout allows you to get the latest version of the maintainer's
preferred branch.

If you want to contribute to future development in Debian and make
things easy for the maintainer, it seems like this is the best tool we
have today.

Advantages:

* You get to see things in the maintainer's work flow.  You can submit
  patches in the form most familiar to the maintainer.

* You get to see ongoing development that may not have made it into
  Debian yet.

* You may see branches that have never been (and possibly never will be)
  in Debian.

Disadvantages when contributing to future Debian development:

* May not work at all or may provide out of date information if the
  vcs-git is outdated etc.

* We have many different git work flows and data models.  You may not be
  familiar with or like the one the maintainer uses.

* It may not be obvious how to build the sources.


Additional Disadvantages for other use cases:

* It may be challenging to find the source corresponding to binaries you
  have



Compare and contrast with dgit clone.  Dgit always (assuming there are
no dscs it cannot process) will give you a uniform git view of the
package in the Debian distribution of your choice.  It may give you
history, which may be more or less complete, depending on when and how
often dgit push has been used.
It is well defined how to build a dgit view of a source package.

Advantages:

* Lets you as a downstream or user get the source to modify the binaries
  you have so you can make changes.

* Regardless of what maintainer work flow and data model are used, you
  get a consistent way of interacting with the sources.

* May give you history sufficient for viewing without you needing to
  understand how the maintainer works with git.  Interacting with those
  commits may sometimes require knowledge of work flows other than
  dgit's native work flow/data model.  Example: you can probably review
  the history enough to read a patch.  But cherry-picking patches (or
  reverting) from maintainer view commits may sometimes require
  knowledge beyond standard git knowledge.

Disadvantages for Debian Development:

* Only gives you code that has actually been uploaded to the archive.

* When the dgit view is not the same as the maintainer view,
  contributing merge requests requires knowledge on your part or that of
  the maintainer.  You always have the bts and raw patches as a
  fallback, but it is often easier for maintainers to process things
  closer to their workflow.

* History diverges from maintainer's history if dgit push is never or
  not always used.

Conclusions
===


I think that for the discussion I'm hoping to start soon, we're focused
on development within Debian.  That is, we do care about code not yet
released to the archive.  We do care about getting future changes
integrated, possibly even with little action on the part of the
maintainer.

That is, for the salsa discussion coming out of the DPL campaign, we're
focused more on those use cases than on finding the source to a given
binary.  And we explicitly do care about how proposed changes get into
the git data model/workflow that the maintainer uses.

I think the question of finding sources for binaries and of users having
a uniform approach for making changes is valuable.  It's just not the
focus of the discussion I said I would have during the DPL campaign.
I'm not even sure which is more valuable: I don't think all  the people
involved in the debian-vote discussion earlier this year understood the
difference adequately.

What I do know is that I think I'm already worried about whether the
discussion is too big.  I'm going to try and focus on what I said I'd
focus on because that's valuable.  There are other things that are also
valuable; by trying to narrow my own thinking in this instance I'm
trying not to make a judgment about them.

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Bill Allombert]

On Sat, May 25, 2019 at 01:26:47PM -0400, Sam Hartman wrote:
> 
> Hi. Almost two weeks ago [1] I  started a discussion on whether we
> wanted to increase the strength of our recommendation of the dh
> sequencer from debhelper.
> This message is a consensus call summarizing my reading of the
> discussion.
> 
>   [1]
>   https://lists.debian.org/msgid-search/tsla7fqjzyv@suchdamage.org

The magic of dh comes by making assumption on the upstream build system.
When these assumptions are correct then it is much less verbose than
debhelper. When they are not correct the maintainer needs to override
all incorrect guesses, in addition to writing the correct code, at which
point the benefit of dh is greatly reduced.  

Updating dh to a new compat level might include extra assumption that
will then need to be overrided.

The maintainer is the best placed to know when the trade off should be.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Consensus Call: Do We Want to Require or Recommend DH; comments by 2019-06-16

[Russ Allbery]

Bill Allombert  writes:

> The magic of dh comes by making assumption on the upstream build system.
> When these assumptions are correct then it is much less verbose than
> debhelper. When they are not correct the maintainer needs to override
> all incorrect guesses, in addition to writing the correct code, at which
> point the benefit of dh is greatly reduced.

This statement is quite contrary to my experience with dh.  The magic of
dh is to automate the normal sequence of debhelper commands, which is far
more than just integrating with the upstream build system.  When upstream
has an odd build system, I usually only have to override three dh
sequences (dh_auto_configure, dh_auto_build, and dh_auto_install); the
vast majority of dh and its accompanying simplification is still intact,
and the resulting overrides are still the same as or less verbose than
writing the equivalent code with debhelper.

The magic of dh is not having to remember what order you have to put
dh_strip and dh_fixperms in, or to remmeber to include dh_lintian when I
add an override, or to allow us to add dh_strip_nondeterminism globally
for most packages in Debian without requiring a mass bug filing.

> Updating dh to a new compat level might include extra assumption that
> will then need to be overrided.

The same is true of using any packaging helper that uses debhelper, and is
still true for new versions of Policy even if you hand-code everything.

-- 
Russ Allbery (r...@debian.org)   

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Ian Jackson]

I haven't really organised my thoughts and have been travelling a lot
and am very tired, so this is a bit bitty.  I may respond more
usefully in a day or two:

Sam Hartman writes ("The Difference between debcheckout and dgit and what they 
try to accomplish"):
> Debcheckout allows you to get the latest version of the maintainer's
> preferred branch.

"debcheckout" is just a convenience script for getting at whatever
Vcs-Git provides.  In this context I should note that "dgit clone"
will set up a git remote called "vcs-git" which you can "git fetch",
to access the same thing[1] as "debcheckout" gives you.

[1] There is a problem that the Vcs-Git metadata is in the wrong place
(like the Maintainer and Uploaders fields are) with complicated
implications in the presence of skew.  (Some of these you mention.)


> If you want to contribute to future development in Debian and make
> things easy for the maintainer, it seems like this is the best tool we
> have today.

That depends, I think, on whether you are trying to (a) join a
maintainer team, or do "maintainer-like" work; or, (b) do
cross-archive work with small changes to many packages, or
archive-wide testing, or similar.

Any case where the change you want to make is simple, but you want to
make it to many packages, is much easier to achieve with a dgit-based
NMU workflow.

RC bugfixing and other kinds of "passer-by" QA work is usually easier
with dgit too.  You only need to understand the bug, and the relevant
parts of the package, not hold some git workflow stuff in your head
too.

Also: if all you are planning to do is prepare and test a patch, then
usually the easiest workflow is dgit clone followed by some
git-format-patch.  I have submitted many patches this way and no-one
has seemed to think them inconvenient.


> Advantages:
> 
> * You get to see things in the maintainer's work flow.  You can submit
>   patches in the form most familiar to the maintainer.

You say "submit patches".  Maybe you mean "submit changes" ?

If you intend to submit *patches*, I think git-format-patch on a
dgitish git branch will do something that is (1) very standard and
expected by a maintainer and (2) easy for the maintainer to
incorporate.

However, what you cannot do without grappling with the maintainer's
workflow is submit a salsa git merge request.  I think it would be
possible to improve this - see below.

> * You get to see ongoing development that may not have made it into
>   Debian yet.

This may or may not be an advantage, depending on what you are trying
to do.

If we had the right metadata, we could automatically synthesize a dgit
view from the salsa maintainer branch, as desired.  But what you would
do with that next is not 100% clear to me...

> * You may see branches that have never been (and possibly never will be)
>   in Debian.

This is unrelated to using the debcheckout branch vs using the dgit
clone branch.  dgit makes access to the debcheckout history easy.
So this is nothing to do with `dgit clone' vs debcheckout.


> Compare and contrast with dgit clone.  Dgit always (assuming there are
...
> * Regardless of what maintainer work flow and data model are used, you
>   get a consistent way of interacting with the sources.

You missed:

Regardless of what maintainer work flow and data model are used, you
can prepare completely competent
  - NMU
  - QA upload
  - patches for sending to the BTS
without interacting with the maintainer workflow, with dgit clone.

> * May give you history sufficient for viewing without you needing to
>   understand how the maintainer works with git.  Interacting with those
>   commits may sometimes require knowledge of work flows other than
>   dgit's native work flow/data model.  Example: you can probably review
>   the history enough to read a patch.  But cherry-picking patches (or
>   reverting) from maintainer view commits may sometimes require
>   knowledge beyond standard git knowledge.

Whether maintainer view commits can be "git-revert"'d or
"git-cherry-pick"'d does indeed depend on the maintainer's workflow.

I don't think this problem is avoidable, other than by forbidding
workflows which do not have whatever properties are desirable.

> * When the dgit view is not the same as the maintainer view,
>   contributing merge requests requires knowledge on your part or that of
>   the maintainer.  You always have the bts and raw patches as a
>   fallback, but it is often easier for maintainers to process things
>   closer to their workflow.

As a matter of equity, I think it should be up to the maintainer to
deal with their workflow.  They chose it.

Unfortunately we lack a standardised way for a submitter using a dgit
view to present a branch with their proposed changes.

If we did, then the maintainer could use manual processing, or
tooling, to integrate the patches in whatever way they prefer.

To do this on salsa might need some special salsa behaviours.

We would of course need a way to turn "sane" (dgit view) git 

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Sam Hartman]

When I outlined disadvantages and advantages I tried to follow what
people who have been participating in the discussion to date described
as advantages and disadvantages.  For the things I listed I have high
confidence that the people involved understood the tools they were using
and their own needs to accurately categorize what they valued.

Clearly we'll need to talk about values for the project as a whole.  But
I think that some of your arguments in your response about whether
something was or was not an advantage made it harder rathre than easier
for me to see whether I understood the space.
> "Ian" == Ian Jackson  writes:



Ian> Also: if all you are planning to do is prepare and test a
Ian> patch, then usually the easiest workflow is dgit clone followed
Ian> by some git-format-patch.  I have submitted many patches this
Ian> way and no-one has seemed to think them inconvenient.

They are certainly no less convenient than patches submitted through the
bts any other way.
It would not make sense to express inconvenience to an individual
submitter who properly follows our established procedure even if that
procedure is frustrating.
However a lot of patches do languish in the bts for non-rc issues.  I
think we've been hearing on blogs, in the debian-vote discussion, and in
feedback from people who do make changes across the archive that they
want improvement here.
I acknowledge it is my job to see if I'm reading comments correctly.

[My comments about being able to interact with the maintainer's work
flow being an advantage]

Ian> That depends, I think, on whether you are trying to (a) join a
Ian> maintainer team, or do "maintainer-like" work; or, (b) do
Ian> cross-archive work with small changes to many packages, or
Ian> archive-wide testing, or similar.

Ian> Any case where the change you want to make is simple, but you
Ian> want to make it to many packages, is much easier to achieve
Ian> with a dgit-based NMU workflow.

Ian> RC bugfixing and other kinds of "passer-by" QA work is usually
Ian> easier with dgit too.  You only need to understand the bug, and
Ian> the relevant parts of the package, not hold some git workflow
Ian> stuff in your head too.
Apologies for being a bit repetative.

I understand this is your opinion.  I am not sure this is generally
accepted.  What I think I'm hearing from people is that they want to
actually be able to get closer to being able to change maintainer
sources than is supported by patches into the bts.

Dgit absolutely can be used to prepare a bunch of patches.  But unless
the maintainer actually uses dgit, it's not clear that the result is
easier for the maintainer to merge than a well submitted patch via the
bts produced from apt-get source.

(Yes, if you actually did an nmu, dgit clone users will benefit from the
dgit push).


But my reading of the discussion so far is that people see getting
patches actually integrated as a pain point.  If I'm understanding our
private conversations, this is not your focus.
This is an area where I think your focus and the project's desires for
improvements are not aligned.

In the debian-vote discussion people were talking about a eutopia where
every DD could push to every package.  And if not push, then submit a
merge request.

I think clarifying people's desires and understanding how critical being
able to push to a package and/or submit merge requests to it is will be
an important next step.






>> Conclusions ===
>> 
>> I think that for the discussion I'm hoping to start soon, we're
>> focused on development within Debian.  That is, we do care about
>> code not yet released to the archive.  We do care about getting
>> future changes integrated, possibly even with little action on
>> the part of the maintainer.

Ian> I think these things are important but:

Ian> for the salsa discussion coming out of the DPL campaign

Ian> I think you are narrowing the scope unduly, perhaps because you
Ian> already have an idea what kind of a solution you want, or
Ian> because you want to solve some problems and leave others for
Ian> later.

I want to talk about solving some problems and leaving others for later.
My prioritization is based on what I've read in discussions so far.

Ian> Obviously it's up to you what you want to prioritise but I
Ian> think we need a solution-neutral problem statement.

Ian> For me, that is:

Ian>  * There is far too much friction and makework caused by
Ian> Debian's antiquated source code management practices.

I don't think I could run a discussion that broad and get anywhere.  If
you or someone else would like to take a crack at running a discussion
that broad, I'm open to stepping back for a month or so and seeing where
the discussion gets.  I'd think a month ought to be enough time to see
if things get stuck or if we're making forward progress.

I don't even know

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Helmut Grohne]

Hi Sam,

On Sun, Jun 16, 2019 at 08:08:51PM -0400, Sam Hartman wrote:
> Ian> That depends, I think, on whether you are trying to (a) join a
> Ian> maintainer team, or do "maintainer-like" work; or, (b) do
> Ian> cross-archive work with small changes to many packages, or
> Ian> archive-wide testing, or similar.
> 
> Ian> Any case where the change you want to make is simple, but you
> Ian> want to make it to many packages, is much easier to achieve
> Ian> with a dgit-based NMU workflow.
> 
> Ian> RC bugfixing and other kinds of "passer-by" QA work is usually
> Ian> easier with dgit too.  You only need to understand the bug, and
> Ian> the relevant parts of the package, not hold some git workflow
> Ian> stuff in your head too.
> Apologies for being a bit repetative.
> 
> I understand this is your opinion.  I am not sure this is generally
> accepted.  What I think I'm hearing from people is that they want to
> actually be able to get closer to being able to change maintainer
> sources than is supported by patches into the bts.

As someone who performs archive-wide changes, I fear I need to somewhat
support Ian's view here. If you are making small changes to many
packages, the maintainer's git tree is not the thing you want to use.

In that kind of situation, dealing with commits that are not yet
uploaded is a disadvantage to your performance. Having to figure out the
maintainer's workflow is a disadvantage to your performance.

My personal conclusion here is that I send patches via the bts. It may
be suboptimal from a maintainer pov (some express a strong preference to
salsa merge requests). Whether I use apt-get source and debdiff or dgit
and git format-patch is a detail on my side.

Still, vcs-git is not my preferred interface to the archive, because its
lack of uniformity makes using it unproductive for me.

I hope this data point helps a little

Helmut

Re: The Difference between debcheckout and dgit and what they try to accomplish

[Andreas Tille]

On Mon, Jun 17, 2019 at 06:53:05AM +0200, Helmut Grohne wrote:
> 
> Still, vcs-git is not my preferred interface to the archive, because its
> lack of uniformity makes using it unproductive for me.

In other words: If vcs-git would be uniform would this be more
attractive to you?

Kind regards

  Andreas.

-- 
http://fam-tille.de