Re: Another approach to golang-* version migration
Hi,
> >> I really don't care, but I think we should have the strategies well
> >> documented, because this is tricky for us all. Maybe we can give up on
> >> recommending any particular strategy and just document all three
> >> distinct approaches that I'm aware of.
> >
> > I agree we should have a unified way to do this, and there should be
> > enough discussions to have multiple people to understand pros and cons
> > of different ways of doing it and landing on the agreed upon best
> > practice.
>
> Yes, although I'm slowly ariving at a position that this is all just
> arbitrary and subjective, and we already have several different styles
> in the archive, so nothing we will document will move the needle
> substantially. So when reviewing doc changes, we have to decide if our
> NEW documentation on this should introduce a conflict against what's in
> the archive, or chose some other stragegy, including:
>
> 1) Weasle word things a'la "The following single approach is what we
> recommend, but other strategies exists".
>
> 2) Describe several different methods, with details, possibly including
> a team-wide preference (if there is one).
>
> We have so many documents claiming that things must be in some
> particular way, and nobody is enforcing or caring about that.
I is quite understandable that nobody is trying to enforce some
unmaintained and outdated thing from 2017. Is somebody did, that would
immediately spark a discussion that forces the policy to be
modernized.
> I'm beginning to think this is a problem with our approach to
> documentation rather than a problem with the things that aren't
> compliant.
The main problem is that we are not really acting as a team. I am a
member in other packaging groups as well (e.g. Python, NodeJS) and
none of them act like a "real" team. Most people are just working
alone on their own packages and interact with others only when they
run in a wall.
I think that we would be much more as a team if we regurlarily review
each other's MRs, and most importantly, review and vote on changes to
the policy. There are buttons to vote at
https://salsa.debian.org/go-team/go-team.pages.debian.net/-/merge_requests
but very few are participating in voting, so no change is legitimized,
and thus no decsions or progress takes place.
Reply to: