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

Re: Format 3.0 (git)

]] "Bernhard R. Link" 

| * Tollef Fog Heen <tfheen@err.no> [110924 16:16]:
| > I find reviewing what's changed between two arbitrary versions in git
| > much easier than doing the same with debian source packages, so I think
| > it's pretty clear this is a matter of preference.
| But if it is some other version control system, which is easier then?

In my experience and with my knowledge, I find git the easiest.  It's
much easier than CVS, SVN and baz/tla.  bzr is about as hard, but since
I use git more frequently I find it easier to use.  For you or some
other contributor I expect the list to look different.

| > Yes, and to continue that thread: The way we do that is to distribute
| > the source of our work.  The most useful definition of source I've come
| > across is the GPL's: The preferred form for modification.
| >
| > Given I maintain my packages in git, it's quite clear that the preferred
| > form for modification of my packages is through git and not debian
| > source packages.  That we don't have a good way of distributing the
| > source of packages is a fault I think we should address.
| "Preferred form" explicitly does not say which one's preferred form.

That is correct.

| I might prefer some code with German comments stating those details
| that are significant to me, and not some English comments also
| describing things that are clear to me because I use such constructs
| all of the time.

If you consider German comments preferable over English comments, you
should distribute the version with German comments.  If there is no
version with German comments it can't be the preferred form.  The
preferred form has to actually exist.

| I also do not prefer at all to work on something without my default
| editor settings, still I do not consider them part of the source.

I don't see how this is relevant any more than whether you prefer to
hack while sitting in a chair or lying on a sofa.  That preference does
not make said char or sofa part of the source.

Maybe I'm completely misunderstanding your point above, but your two
previous paragraphs look a lot like strawmen to me.  If they aren't,
please feel free to explain what you mean.

| > I don't put much weight on the «it should be simple to hack on packages
| > and VCSes make it hard» argument.
| Usefully hacking on Debian packages is only a part of my complaint,
| and I am sad that it is reduced to that.
| First of all it is not only about only even Debian users, giving
| back is about the whole software community.

It's much easier for me to give patches back upstream when I can give
them patches that apply directly to their development tree, rather than
having to guess at what kind of metadata their system wants.  (git
format-patch and git send-email springs to mind.)  So if you want to
make it easier to contribute patches back, we should all be using the
same VCS as upstream where at all feasible.


| > git used to be hard to use back in the olden days, but it isn't
| > particularly hard nowadays.
| Learning git is not that hard anymore, I guess (, though I am not
| really able to assess that from having looked at it for a long
| time). But trying to use to access some stuff must still be quite
| hard: it has some model of things and some private nomenclature
| (think: index, tree, commitish) that will not make it that easy
| to come from zero to be able to locate some commit and do the
| right diff in some not too long time, even if knowing some other
| VCSes.

Of course it has nomenclature, just like Debian packages has:
build-depends, depends, suggests, recommends, maintainers, uploaders,
standards-versions, rules files with targets, patches that are magically
applied and unapplied at various times.

Building packages is complex business and we are not working towards
making it simpler.  I don't think 3.0 (git) would make much of a
difference either way there, tbh.

Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply to: