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

Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa



On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote:

> But I think having recommendations available when people are new, when
> they are looking for what to do when writing new tools, when the trade
> offs don't matter, is really important.  I think it's important enough
> that it's worth time for a quick vote (and I do believe we can
> efficiently handle GRs).

I agree with your message, and I'd like to expand on "when people are
new". I probably don't qualify as new in Debian, and I maintain some
package outside of teams. For those packages, I suffer from the lack of
a team policy that gives me a default way of doing things unless I have
better ideas.

Also, as over time my packaging practices have become outdated, I have
found it both difficult and frustrating to engage on a quest for
figuring out "how does one do this thing nowadays?"[1], and if there
were default recommendations available, I would have considered them a
boon[2].

When the upstream is straightforward and I'm not engaging in innovating
packaging practices, I'm significantly happier having a default script
that I can follow, instead of reinventing or refiguring out the wheel
every time I have an upload to make[3].

So, maybe I'm not new in Debian, but Debian is often new to me, When
there's no team to provide me with some well thought defaults, I could
use a well documented set of well thought defaults to work with.


Enrico

[1] if one finds themselves in a similar position, a good way of staying
    up to date is to become Application Manager. AMs routinely learn a
    lot from applicants
[2] maybe with some policy-style upgrading checklists
[3] the things I maintain don't need frequent uploads, and it's become
    sort of my expectation that for each upload that I make I need to
    plan some nontrivial yak shaving time to figure out which of my
    assumptions have become invalid since the last one
-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

Attachment: signature.asc
Description: PGP signature


Reply to: