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

2015-09-15 Thread Dmitry Smirnov 
On Tuesday 15 September 2015 11:28:01 Martín Ferrari wrote:
> On 14/09/15 12:25, Dmitry Smirnov wrote:
> > My solution to that supper-annoying problem is to keep Debian packaging
> > (i.e. "debian/*" files) and upstream files apart, unmerged. Therefore
> > "master" branch will contain only debian packaging and "upstream" branch
> > holds
> > upstream changes. Simply add the following to your "debian/gbp.conf" 
file:
> The problem with this (apart that I find it much more annoying not to
> have the source), is inconsistency. I think the team should either keep
> all the sources or none. Otherwise, one has to deal with N different
> packaging workflows, and that does not scale.

What is the problem with minor inconsistency if there is no difference in how 
package is built? It is the same git repository and most of actions will be 
the same (unlike SVN repositories for example). Besides merging upstream 
sources is separate effort that have little to do with packaging. If we want 
learning curve to be less steep we need to avoid require maintainer to be 
profoundly experienced with git. I still remember my frustration when I got 
my first merge error on importing upstream tarball and hours I wasted in 
order to resolve the problem instead of doing meaningful work on package.

What do we achieve by having upstream sources in "master"?

Besides we are all have our preferences and I do not wish to impose mine on 
others. There is such thing as Maintainer's comfort and convenience -- I 
believe it matters more than minor inconsistency. We already have those 
inconsistencies -- like you've said some packages need two upstream branches 
and some don't. I'd argue that when `uscan` works one needs no "upstream" 
branch at all but of course there is no harm to have local upstream branch or 
to push DFSG-compliant upstream branch (if it is not too heavy) to shared 
repository. It should be decided on case-to-case basis by maintainers.

I want to mention KDE team again -- they have to work with non-DFSG packages 
with over 20_000 files (e.g. Calligra) and it is such a hassle to import 
upstream sources that they've decided to make it a team's policy to track 
only packaging. As result their repositories are very small.

Once again, I believe we should allow small variations in repository layout 
for best maintainer's convenience.


> For repackaging, what I do instead is to keep an upstream branch that
> follows upstream git history, and from there create a 'repackaged'
> branch that has all the needed removals. It has some work when merging
> in an extra version, but in general it is pretty straightforward and
> keeps a record of how the source was changed.

I think it is a labour intensive, and requires you to track non-DFSG changes 
as well as repackaged ones. I do not want to have non-DFSG stuff in 
repositories at all. Also to avoid bloating public repository I do not want 
to store upstream history -- not everyone needs upstream branch unless of 
course there are no formal upstream releases...

-- 
All the best,
 Dmitry Smirnov.

---

Few people are capable of expressing with equanimity opinions which
differ from the prejudices of their social environment. Most people are
even incapable of forming such opinion.
-- Albert Einstein, from "Aphorisms for Leo Baeck;
   Opinions of Albert Einstein"


signature.asc
Description: This is a digitally signed message part.
___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

2015-09-15 Thread Martín Ferrari 
On 14/09/15 13:07, Dmitry Smirnov wrote:

> 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.

That's true. CPAN upstreams are the best! Still, go packaging is not as
bad as -say- java or the likes. Basically the biggest hurdle is
repackaging, and that does not need to affect our workflow much (see my
other mail).

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

I asked in #alioth, but got no answer so far. In the meantime I worked
around the issue by copying the repos with my UID, and fixing
permissions. The old repos are still there, with a '_perm_problems'
suffix, until they can be removed.

>> 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?

If you reupload, just force push a new tag. Otherwise, remove the tag.

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

It is not a big issue, but it means it is more difficult to track
packages that need to be sponsored. There are a few non-DDs in the team,
and I would like to make it easier for them to work on packages, and for
DDs to sponsor them.

-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

2015-09-13 Thread Michael Stapelberg 
As a meta-point: I think we should change dh-make-golang to do the
right thing once we agree on these suggestions. At least the first
point you mention (repository creation) is already properly handled,
i.e. dh-make-golang gives you a setup-repository command to run.

On Sun, Sep 13, 2015 at 2:54 PM, Martín Ferrari  wrote:
> Hi all,
>
> This week I have spent a considerable amount of time tidying up the
> group's repositories.
>
> This was motivated initially because I wanted to work on pending bugs,
> uploads, etc. And a great tool to keep track of pending work is PET [1],
> which Michael set up a while ago, and the UDD Maintainer dashboard [2].
>
> For these tools to be useful, a few conventions need to be followed.
> These conventions are usually very useful for team maintenance, as there
> is much less guessing involved when working with a package that somebody
> else prepared.
>
> I've also found issues that hamper team work, even if they are not
> problematic for PET/UDD.
>
> So, here is a list of problems, and what I consider
> solutions/best-practices for them. I believe them to be more or less
> non-controversial across packaging teams, and I believe it would help a
> lot the team if we all use them.
>
> 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 :-)
>
> Comments and criticisms welcomed.
>
> The list:
>
> 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.
>
> S: Always create repositories running '/git/pkg-go/setup-repository
>  '

Agreed, I think this is a no-brainer.

>
>
> 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.
>
> S: Instead of just importing debian/, start by adding upstream as a
> remote, and 'git checkout -b upstream' based on the tag you want to package.

Does this imply having a git history such as displayed in
https://anonscm.debian.org/cgit/pkg-go/packages/golang-uuid.git/log/?
I find that super-annoying for packages with active upstream
repositories, because I’m almost never interested in an individual
upstream commit, but rather at high-level changes that directly
correspond to uploads to Debian. I.e., I prefer seeing a single
“Imported upstream snapshot X” commit over seeing hundreds of
individual upstream commits.

>
>
> P: Missing tags for releases. This confuses PET and anybody working on
> your package: without the tag, you can never be sure what is the commit
> that matches what was uploaded.
>
> S: Always use debcommit -r, which will create the tag automatically,
> when the package is about to be uploaded.

Agreed. I think whenever this happens, it’s just a mistake such as
forgetting to push the tag or something similar.

>
>
> 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.
>
> S: Use dch to start a new version, and dch -r to mark it as finished and
> ready for upload/sponsoring. Packages that are marked like this but not
> tagged are usually candidates for sponsored uploads.

See also https://github.com/Debian/dh-make-golang/pull/16 — I wanted
to change the team policy document on that before accepting the PR,
but I think we all agree by now.

>
> [1] http://pet.debian.net/pkg-go/pet.cgi
>
> [2]
> https://udd.debian.org/dmd/?email1=pkg-go-maintainers%40lists.alioth.debian.org
>
> --
> --
> Martín Ferrari (Tincho)
>
> ___
> Pkg-go-maintainers mailing list
> Pkg-go-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers



-- 
Best regards,
Michael

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers

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

2015-09-13 Thread Martín Ferrari 
Hi,

On 13/09/15 18:28, Michael Stapelberg wrote:
> As a meta-point: I think we should change dh-make-golang to do the
> right thing once we agree on these suggestions. At least the first
> point you mention (repository creation) is already properly handled,
> i.e. dh-make-golang gives you a setup-repository command to run.

Ah, possibly many of these issues I found have an in dh-make-golang..
Honestly, I haven't tried it yet :-)

>> 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.
>>
>> S: Instead of just importing debian/, start by adding upstream as a
>> remote, and 'git checkout -b upstream' based on the tag you want to package.
> 
> Does this imply having a git history such as displayed in
> https://anonscm.debian.org/cgit/pkg-go/packages/golang-uuid.git/log/?
> I find that super-annoying for packages with active upstream
> repositories, because I’m almost never interested in an individual
> upstream commit, but rather at high-level changes that directly
> correspond to uploads to Debian. I.e., I prefer seeing a single
> “Imported upstream snapshot X” commit over seeing hundreds of
> individual upstream commits.

I does imply that, yes. I guess this (having upstream history) is not as
important as the other points, but I would argue that in many situations
it can help a lot your work (for example, if you want to find when and
why something changed in the code, or why a patch stopped applying), and
it does not really get in the way. You can usually just ignore upstream,
and merge only when starting a new release. I guess you could also
rebase and pack all those changes into a single commit, but then the
whole point of tracking upstream is lost.

On the other hand, not having the upstream source at all (I found one
package like that today) is bothersome, and I don't see any good reason
for that..

>> P: Missing tags for releases. This confuses PET and anybody working on
>> your package: without the tag, you can never be sure what is the commit
>> that matches what was uploaded.
>>
>> S: Always use debcommit -r, which will create the tag automatically,
>> when the package is about to be uploaded.
> 
> Agreed. I think whenever this happens, it’s just a mistake such as
> forgetting to push the tag or something similar.

Possibly. I have adopted a set of git config options that I took from a
really detailed description of a git workflow (I don't remember the link):

# Assuming the debian remote is called 'debian':

git config --add remote.debian.push 'refs/tags/debian/*'
git config --add remote.debian.push 'refs/tags/upstream/*'
git config --add remote.debian.push 'refs/heads/debian/*'
git config --add remote.debian.push 'refs/heads/pristine-tar'
git config --add remote.debian.fetch 'refs/tags/*:refs/tags/*'

This will always push debian-related tags and branches, and avoid
pushing other tags (like upstream tags). It is very convenient.

>> S: Use dch to start a new version, and dch -r to mark it as finished and
>> ready for upload/sponsoring. Packages that are marked like this but not
>> tagged are usually candidates for sponsored uploads.
> 
> See also https://github.com/Debian/dh-make-golang/pull/16 — I wanted
> to change the team policy document on that before accepting the PR,
> but I think we all agree by now.

I have not noticed that was being discussed. But you can assume my +1 on
that PR, obviously :)


-- 
Martín Ferrari (Tincho)

___
Pkg-go-maintainers mailing list
Pkg-go-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers