[pkg-go] Various problems with packages in the group

[Dmitry Smirnov]

On Sunday 13 September 2015 15:54:43 Martín Ferrari wrote:
> This week I have spent a considerable amount of time tidying up the
> group's repositories.

Thank you. :)


> I learnt most of these guidelines in the pkg-perl group. Without a lot
> of person-power, they maintain over 3000 packages, with an impressible
> attention to detail, and they make it very easy for new contributors to
> join the group. I really trust what that group considers good practices :-)

Nice to learn from the best. :)

However most of Perl packages are superior to Golang packages. The latter 
bundle build-dependencies very often while Perl packages rarely need to 
undergo DFSG-repackaging. Almost all Perl packages (I can't recall even a 
single exception) have formal version, probably because CPAN require modules 
to be versioned. Packaging Perl software is usually easier and takes less 
maintenance effort.

Golang software exhibit bad practices all over as far as I can tell...
Unfortunately this have implications to our workflows because of frequent 
version mocking and DFSG cleanup.


> P: Many repositories had permission problems and missing hooks (which in
> turn means no KGB notifications nor PET updates), because they were
> created manually instead of using the setup-repository script. The
> permissions problem is particularly bothersome as it makes it impossible
> for anybody else to work on the package.

I've already experienced permissions problem twice and I wonder if we can ask 
admins (whom specifically?) to fix this problem for all repositories...


> P: Packages missing upstream source or history. Although many groups
> tend not to include source, it is good to have consistency. I would
> argue that not having the source makes your life as a maintainer a lot
> more difficult, and with most people using git these days, having
> upstream's history can be a life saver.

There are some pros and cons. I agree that upstream history is useful but we 
should let maintainers to keep local branches if they prefer to avoid 
accumulating unnecessary burden of upstream changes in public repository.
It is easy to get orig.tar with `origtargz` or with `uscan` when upstream 
have formal releases. For packages where upstream do not tag releases, sadly, 
it is hard to get orig.tar without tracking upstream repository...

Typically we only need upstream history since last release and there is no 
need to accumulate upstream history of changes since beginning of time 
because of its rapidly diminishing value. 


> S: Always use debcommit -r, which will create the tag automatically,
> when the package is about to be uploaded.

What do you suggest to do with tag if package is rejected?

I've made it a personal policy to tag only once package is accepted...


> P: Having unfinished packages with 'upstream' distribution in
> debian/changelog, instead of 'UNRELEASED'. This is a convention
> originating in dch: when you start working on a new version of a
> package, dch will set the distribution to 'UNRELEASED', so there is no
> confusion with already-uploaded versions. This is also use by PET to
> differentiate work-in-progress packages, with packages that are ready to
> upload or already uploaded.

I believe we've violated this practice because "dh-make-golang" used to set 
distribution to "unstable" but now it is fixed.

-- 
Best wishes,
 Dmitry Smirnov.

---

It is a mistake to try to look too far ahead. The chain of destiny can only
be grasped one link at a time.
        -- Winston Churchill

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-go-maintainers/attachments/20150914/9e26bb12/attachment-0001.sig>