Re: gitlab-ci-runner updates
On 2021-04-29 11:35:30, Dmitry Smirnov wrote:
> On Wednesday, 28 April 2021 11:00:19 PM AEST Antoine Beaupré wrote:
[...]
>> > I like simple workflow resembling the following:
>> > https://salsa.debian.org/onlyjob/notes/-/wikis/bp
>>
>> It would be helpful to have a link to those notes (or a TL;DR:) in a
>> README.source in the source package...
>
> Why? Just because some developers forgot how to build a Debian package
> without GBP? Once that was a common knowledge and still should have been.
There are many ways of building a debian packages, with or without GBP.
>> Well that's what git reset is for. :)
>
> More needless operations and still a bloat of the git repo size...
I respectfully disagree on the "needless" part. Also the "bloat" doesn't
propagate to upstream refs and will be cleaned up by gc eventually.
>> Hum. That's a rather long read and I'm not sure I want to get into a
>> "how my way of building Debian packages is better than yours". It seems
>> we all have our ways and while that's unfortunate, I guess that's life.
>
> I'm not asking you to read. Personally I always strive to learn how
> to make things better. I've found that GBP workflow is full of problems
> and that it does not really solve any problem either. Wouldn't you
> like to know?
I have read many, many, opinions and ideas on what the best packaging
workflow is. I am moderately curious of yours, and will probably read it
eventually, but if I need to read each Debian developer's paper on how
to package stuff, I will have to read about 600 such essays, and while
I'm curious, I lack the time.
> Besides it is not just "my way of building is better" (it may or may not
> suit you). It is that GBP is at least unproductive and difficult to use
> with packages that "vendor" extensively, and in some occasions (e.g.
> docker.io) GBP does not work at all. With several packages we only
> started to make progress when we stopped using GBP's repo layout.
Good to know, thanks, I will keep that in mind.
>> The key point, in my mind, is that each package should explicitly
>> document its own workflow clearly somewhere, and that wasn't done in
>> this specific package. I looked at the existing branches from Salsa and
>> they *did* have the upstream/pristine-tar/master so I assumed gbp was
>> the right way to go forward. I'm happy to use another workflow.
>
> Make sense. Thanks. I would remove those useless branches but some may
> prefer to use them so whatever...
I would strongly suggest getting rid of them if you do not plan on using
or maintaining them. They are bringing much confusion to the table.
[...]
>> I hope my small amount of work will have been useful for you!
>
> Did I miss any commits?
No, all the work I did was in this email.
[...]
Anyways, it seems we're diverging into a packaging bikeshed painting
contest, and I don't quite see us getting anywhere with this. You win,
paint it the color you like, it's your package anyways.
I was just suggesting you make it slightly more obvious what your
particular workflow is, because it's not obvious to a Debian developer
not used to your specific one.
a.
--
Blind respect for authority is the greatest enemy of truth.
- Albert Einstein
Reply to: