[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

Blind respect for authority is the greatest enemy of truth.
                       - Albert Einstein

Reply to: