1 |
On Tue, Sep 16, 2014 at 07:26:06AM -0400, Rich Freeman wrote: |
2 |
> On Tue, Sep 16, 2014 at 6:18 AM, hasufell <hasufell@g.o> wrote: |
3 |
> > Ulrich Mueller: |
4 |
> >> |
5 |
> >> ChangeLogs are aimed at users |
6 |
> > |
7 |
> > Did any1 ask them if they care? |
8 |
> > |
9 |
> |
10 |
> I'm sure somebody will reply and say that they care. |
11 |
|
12 |
Yup, mainly because of this: |
13 |
|
14 |
> It still seems like a lot of overhead to me for a very one-off |
15 |
> workflow. Maybe if portage automatically output the relevant |
16 |
> changelog entries in pretend mode we could pretend that they're news |
17 |
> or something like that. |
18 |
|
19 |
..which seems to me the job of a consuming script. We[1] present the |
20 |
last entry from changelogs when, for instance, a package is coming |
21 |
through as a Downgrade from emerge. |
22 |
|
23 |
It's counter-productive to overload the plumbing layer, with porcelain. |
24 |
Equally the plumbing-layer has to provide enough info for the porcelain |
25 |
to make decisions. That info has to be tailored for the admin, not the |
26 |
ebuild developer, eclass author, or proxy-maintainer. |
27 |
|
28 |
It's not needed when nothing's going wrong, but when something weird is |
29 |
happening, the short message usually provides assurance and/or info |
30 |
on options. (see next) |
31 |
|
32 |
> If we actually move to a model where many users actually sync their |
33 |
> trees from git, then I'd expect the changelogs to be even less useful. |
34 |
> After all, git will actually tell you what changed since your last |
35 |
> sync. |
36 |
|
37 |
VCS commit messages are very different to the ebuild Changelogs ime. |
38 |
However if you're switching to git, have the equivalent info in git |
39 |
logs, and the user has a git clone by definition, that /can/ work. |
40 |
|
41 |
I would ask that you consider the different purpose of VCS commit |
42 |
messages, vs ebuild Changelogs. The latter are terse summaries from |
43 |
the admin perspective, and the former naturally tend to be more |
44 |
code-oriented, especially when applied to bigger projects, and |
45 |
especially with the ncremental-commit model that git fosters. (don't |
46 |
rebase: just push, and use add -p if you have to break it up[2].) |
47 |
|
48 |
Either way, I don't think the discussion about Changelogs should |
49 |
*at all* affect the move to git; you can change Policy after |
50 |
switching, very easily, and there will be other things to iron out |
51 |
which will take much more effort, so I don't think the switch |
52 |
should get sidetracked, by this or other post-switch topics raised. |
53 |
|
54 |
You've mentioned scripts a couple of times, and wanting help with |
55 |
them; can I suggest you post a (git preferably) url of something |
56 |
people can see and help you with? And tell us what IRC channel, |
57 |
if you prefer that to forums, or the list for code review. |
58 |
|
59 |
#git are excellent, btw, eg if you want to rewrite emails on import, |
60 |
in your case from LDAP, or get advice on large-scale deployment |
61 |
from the infra side. |
62 |
|
63 |
[1] http://weaver.gentooexperimental.org/update.html |
64 |
[2] http://forums.gentoo.org/viewtopic-p-7587838.html#7587838 |
65 |
-- |
66 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |