Re: How can we make Debian packaging more standardised?
On 2021/03/19 20:05, Louis-Philippe Véronneau wrote:
> In becoming a DD, one of the main challenges I faced was the absence of
> a standard way to package software in Debian.
> I've since seen first hand how having a very large number of ways to
> package things in Debian confuse and ultimately discourage people that
> would otherwise have been interested in joining the project.
That's true for regular contributors and old-timers too.
> One of the reasons I like team-maintained packages is teams often have a
> single packaging standard. Sadly, each team has their own way of doing
> things and working in multiple teams means working with multiple
> If you were elected as DPL, what would you do about this? Sam Hartman
> tried to lead discussions on using git, but sadly it seems it didn't
> yield anything tangible.
I consider this an item still on the collective project's todo list to
figure out. I've received plenty of e-mails to the DPL alias regarding
git workflows, but there has just been too many high priority things to
take care of this term and sadly this just hasn't made the cut in terms
of my DPL load. This is one of those issues which could be delegated but
then again, it's also a discussion that's already open for anyone to
drive, so that would be kind of redundant?
> I understand change is never easy and often disrupts people, but I think
> we should be striving for a more cohesive packaging ecosystem.
> Even if we don't ultimately enforce it, being able to point people an
> officially recommended way to create packages in Debian would be a large
> step forward.
We both touched on git a bit above, but I do think that's the first
place to start. It's probably the place where there's currently the most
excess of options available and most confusion, at least compared to the
rest of our packaging policies as far as I can tell. Like, do we call
new branches "master" or "main" (or even "debian/main" (not to confused
of course with "debian main)), do we use gbp or dgit or one of the many
git helper tools out there (I admit I don't know how to use either
properly and have somehow managed to get away with it, but I do plan on
learning how to use dgit if I can find a good primer on it), etc.
Usually team policies help a lot with all those, but as you say, they
tend to be different. If it was up to me, I'd standardise on using git
for a start. Based on a chart from debian trends, we're inching
close to squeezing out svn, but there's still a very large amount of
packages not listed as being in VCS at all. That could potentially make
a release goal. On that note, a release team member has indicated to me
that even though they don't create release goals anymore, that DDs could
still do so *wink* *wink*.
I also think that we should really standardise on salsa for git hosting.
Sure, it might be slightly more convienient for your particular workflow
to host it on your own server, or on GitHub, but I really can't think of
a single good reason to not have it on Salsa and there are plenty of
There are a few other trends on that site that I think would be useful
too, but as a start I think standardising on git and salsa would be a
very good start.
Now, to answer your question on what I would do about this as DPL in the
next term, that's tough to say, on the git issues at least, I'd like to
get the right people together and at least kick some proper discussion
off in something like a BoF. Some discussion that doesn't start off on a
mailing list but that's also well structured so that it's not some
useless heated discussion that quickly evaporates. If I sound a little
noncommittal about all this, it's because it's really hard to predict
what the next year will look like in terms of the influx of DPL tasks,
but I do think that the next year will be easier than the last, I've
worked very hard to stay on top of things and I'm hoping that there will
be more time for the DPL and the rest of the DDs to address this in a
more structured and productive manner.