[Bf-committers] Withdrawal

Antony Riakiotakis kalast at gmail.com
Tue Sep 16 09:30:47 CEST 2014 

I wouldn't say no to a WIP/Regression scheme. It would be clearer to people
reading the logs or not knowing that code.
 Of course we might forget to do properly or some coders might not like it.
Why not just let coders who like it do it and see how it works?
 The need for meaningful commit messages is taken for granted I think.

On 16 September 2014 08:58, Campbell Barton <ideasman42 at gmail.com> wrote:

> On Tue, Sep 16, 2014 at 4:40 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> wrote:
> > @campbell, that sounds to much burocratic for me
>
> Agree, and I hesitated to propose for this reason.
>
> > :) IMO it'll be just
> > easier to be more verbose in the commit log, so it's not just "Fix TXXX:
> > Foo bar", but also:
> > - Includes a bit of explanation what da heck was going on. Having like
> > few-kilos-long patch with just title copy-pasted from the tracker is not
> > that useful at all. That could be considered a separate topic, a part of
> > some "code style" guideline to help other developers to understand
> what/why
> > was changed. might deserve separate thread in the ML perhaps, but it's
> > somehow glued in here.
> >
> > - For the regressions fixes we already did things like "To be backported
> to
> > final release" post-scriptum for 2.71. Worked rather fine, was much
> easier
> > to keep track of what fixes are to be for sure ported over. It never
> meant
> > to be some some strictly specified sentence for that btw. We're not
> robots,
> > so why to construct such a rules?
> >
> > - Think the same less formal approach would work better for making Bug
> > Fixes section generation easier.Could be like "This bug was introduced in
> > blender 2.69" or "The same happened in the release" or whatever else.
> >
> > - Also, for me it was always an issue to parse some developer's commits
> to
> > get meaningful information. For example formation like "Fit TXXX\nNeed to
> > do foo to solve bar" is rather a total crap. You ends up going to the
> > tracker, reading the description, tries to explain that in one sentence.
> > Also sometimes commit logs are like "Fix TXXX: Blender total crash".
> What i
> > mean is: it's more important to make sure the description of bug in the
> > commit message is explicit enough for the release notes page generation.
> > Maybe more important than indication of regression/ongoing fixes
> indication.
>
> IMHO this is 2 issues - having well written commit log is fine, but
> wont ensure you can tell if the error thats fixed was present in last
> release or not.
>
> If I had to write "The same happened in the release" after every
> commit that fixes a bug in a release, IMHO this is more annoying then
> having some convention/keyword, everyone will write it a bit
> different, or forget to write, and it means more to read when
> gathering commits to include in release notes.
>
> At this point I wonder if we should really be spending this time to
> gather fixes for each release, the lists from previous releases are
> incomplete or include fixes for bugs not in the previous release, its
> just not very accurate and automatically selecting commits for
> inclusion involves adding some kind of meta-data to each commit which
> ends up being bureaucratic & devs probably end up not using.
>
> > @troubled, that's just an overkill.
> >
> > On Tue, Sep 16, 2014 at 9:28 AM, Trouble Daemon <troubledaemon at gmail.com
> >
> > wrote:
> >
> >> What about using git notes?
> >>
> >>   https://kernel.org/pub/software/scm/git/docs/git-notes.html
> >>
> >> Dan
> >>
> >> On Mon, Sep 15, 2014 at 10:10 PM, Campbell Barton <ideasman42 at gmail.com
> >
> >> wrote:
> >>
> >> > To follow up on a related point.
> >> >
> >> > Making this list of bugfixes is quite time consuming and unless you
> >> > read the commit logs daily _and_ know the code, its quite hard to tell
> >> > which issues to include in the release log.
> >> >
> >> > It would be good if there was some indication from a commit to know if
> >> > the bug is from some recent change, or if its a bug in the previous
> >> > release.
> >> >
> >> >
> >> > Suggest we could indicate this in the subject:
> >> >
> >> > - Fix T1234: Some Text
> >> > - WIP Fix T1234: Some Text
> >> > - Regression Fix T1234: Some Text
> >> >
> >> >
> >> > Meaning:
> >> >
> >> > - Fix - regular fix for a bug existed in last release.
> >> > - WIP Fix - fix for change in new code (never in a release)
> >> > - Regression Fix - fix for bug introduced in a release.
> >> >
> >> >
> >> > Many fixes would be WIP, so at a glance we can tell not to include
> >> > (its useful for reading commit logs too).
> >> > Often I write something like "Fix for recent change in ..." so typing
> >> > 'WIP' is less hassle.
> >> >
> >> > Although I'm not sure its practical to enforce this long-term (we
> >> > attempted complicated conventions before and ended up not using).
> >> >
> >> > Any suggestions?
> >> >
> >> > On Mon, Sep 15, 2014 at 5:08 AM, Gavin Howard <
> gavin.d.howard at gmail.com>
> >> > wrote:
> >> > > Well, if I don't get it done, you have to. The time constraint was
> so
> >> > > you could expect it done before having to work on it yourself.
> >> > >
> >> > > On Sun, Sep 14, 2014 at 1:04 PM, Sergey Sharybin <
> sergey.vfx at gmail.com
> >> >
> >> > wrote:
> >> > >> Sounds cool, only not sure why to define such a time constraints?
> >> > >>
> >> > >> On Mon, Sep 15, 2014 at 12:59 AM, Gavin Howard <
> >> > gavin.d.howard at gmail.com>
> >> > >> wrote:
> >> > >>
> >> > >>> In reality, Ton, I sent that email only to you; I didn't know
> >> Sergey's
> >> > >>> address, I didn't want to spam the mailing list, and I was already
> >> too
> >> > >>> embarrassed. (So much for that.) So it's not Sergey's fault. And
> >> > >>> neither is it yours; I know you're busy, so I was planning on
> >> > >>> resending the email today anyways. But I should have sent it to
> the
> >> > >>> whole list. Yet another mistake. Sorry.
> >> > >>>
> >> > >>> The truth is that I'm not frustrated with you all. What did me in
> was
> >> > >>> going back through and trying to clean up the fixes as Sergey
> said. I
> >> > >>> thought I understood what he said, and I realized that I didn't.
> Like
> >> > >>> I said, it was my own incompetence at following simple
> instructions.
> >> > >>> Just to be clear, I never thought I was insulted. I simply get
> >> > >>> frustrated with myself quite easily, especially after last summer.
> >> > >>>
> >> > >>> Sergey, your clarifications helped. (I think.) Give me 24 hours
> to go
> >> > >>> back through and get it up to standard.
> >> > >>>
> >> > >>> God Bless,
> >> > >>> Gavin Howard
> >> > >>>
> >> > >>> On Sun, Sep 14, 2014 at 9:31 AM, Sergey Sharybin <
> >> sergey.vfx at gmail.com
> >> > >
> >> > >>> wrote:
> >> > >>> > I didn't actually see your mail from monday. Either it got lost
> >> > somewhere
> >> > >>> > in my client or i dunno.
> >> > >>> >
> >> > >>> > As for the fixed bugs section it's not that bad actually, the
> stuff
> >> > Ton
> >> > >>> > mentioned in the minutes are just guidelines for that page to
> make
> >> it
> >> > >>> > maintainable. It doesn't mean it's fully wrong or so. Main issue
> >> > with the
> >> > >>> > page is that it lacks information about the revision range it's
> >> valid
> >> > >>> for.
> >> > >>> > So if you suddenly becomes busy and i (or cambo or whoever else)
> >> need
> >> > >>> > finish it -- it'll be rather tricky to figure out where to
> start.
> >> To
> >> > >>> avoid
> >> > >>> > such issues, we put on the top of the page:
> >> > >>> >
> >> > >>> >   Changes from revision AAA up to BBB
> >> > >>> >
> >> > >>> > It should be really easy for you to add information about
> revision
> >> > your
> >> > >>> > list is updated to.
> >> > >>> >
> >> > >>> > Other issue is that i saw quite a few fixes which were a fixes
> for
> >> > new
> >> > >>> > stuff added to 2.72. We don't mention that in the change log. It
> >> > should
> >> > >>> be
> >> > >>> > easy for you again to just ignore such fixes for the rest of the
> >> > >>> revisions
> >> > >>> > from now on up to the very release. We'll need to clean up
> existing
> >> > list
> >> > >>> > from those fixes, but for that you can have at least mine help,
> and
> >> > as
> >> > >>> max
> >> > >>> > -- there could be more volunteers to help cleaning stuff up.
> >> > >>> >
> >> > >>> > And the structure issue is also not that difficult to solve.
> It's
> >> > just
> >> > >>> > matter of using old structure and copy-pasteing new fixes to
> it. Or
> >> > >>> > renaming the sections, so Modeling is more like a Mesh Editing,
> >> > >>> Compositor
> >> > >>> > is Node / Compositor and such. Sticking to some "standard"
> template
> >> > is
> >> > >>> good
> >> > >>> > for the readability of changes imo. And for this you can also
> use
> >> my
> >> > help
> >> > >>> > or help from someone else in the community.
> >> > >>> >
> >> > >>> > So to summarize, there is some clean up to be done on the fixes
> >> > page, but
> >> > >>> > it's not that much of work and it doesn't mean you need to do it
> >> all
> >> > >>> (we'll
> >> > >>> > for sure help with the cleanups and so). And consider
> information
> >> > from
> >> > >>> > Ton's mail about fixed bugs section as a guideline for the
> future
> >> > work on
> >> > >>> > that section. Do not consider it as an insult on your work, we
> >> really
> >> > >>> > appreciate your help.
> >> > >>> >
> >> > >>> > On Sun, Sep 14, 2014 at 9:11 PM, Ton Roosendaal <
> ton at blender.org>
> >> > wrote:
> >> > >>> >
> >> > >>> >> Hi Gavin,
> >> > >>> >>
> >> > >>> >> Sorry, it's unfortunate that nobody replied to your mail from
> last
> >> > >>> monday.
> >> > >>> >> I had no time either.The issue would/could have been easy to
> >> handle
> >> > in
> >> > >>> irc
> >> > >>> >> though... asking sergey or campbell or me. I can only confirm
> >> > they've
> >> > >>> been
> >> > >>> >> very busy and didn't notice or forgot the mail.
> >> > >>> >>
> >> > >>> >> In any way - most important is to at least keep communicating!
> >> When
> >> > that
> >> > >>> >> fails it's usually the core of the issues in a volunteering
> >> > >>> organization.
> >> > >>> >>
> >> > >>> >> I'll ask Sergey to clarify the remarks I copied to the minutes.
> >> > >>> >>
> >> > >>> >> -Ton-
> >> > >>> >>
> >> > >>> >> --------------------------------------------------------
> >> > >>> >> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
> >> > >>> >> Chairman Blender Foundation - Producer Blender Institute
> >> > >>> >> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
> >> > >>> >>
> >> > >>> >>
> >> > >>> >>
> >> > >>> >> On 14 Sep, 2014, at 5:09, Gavin Howard wrote:
> >> > >>> >>
> >> > >>> >> > All,
> >> > >>> >> >
> >> > >>> >> > This is going to be a pretty weird email, but whatever.
> >> > >>> >> >
> >> > >>> >> > I've been using Blender for several years now, after being
> >> > introduced
> >> > >>> >> > to it while at version 2.49. I used it a little, then set it
> >> > aside for
> >> > >>> >> > a while. A year later, I came back to a wonderful 2.5x
> series. I
> >> > was
> >> > >>> >> > excited, and because I /thought/ I could program, I wanted to
> >> > help.
> >> > >>> >> >
> >> > >>> >> > I was /completely/ wrong about my skill.
> >> > >>> >> >
> >> > >>> >> > I bombed GSoC 2013, and as a result, I got super frustrated
> at
> >> > myself
> >> > >>> >> > and went into "hiding". After a while, and more education, I
> >> > decided
> >> > >>> >> > to do something a little more humble: the Release Notes.
> >> > >>> >> >
> >> > >>> >> > As you all know from last week's Developers' Meeting, I did
> the
> >> > >>> >> > Release Notes wrong, especially on the Bug Fixes page. I went
> >> back
> >> > >>> >> > through and tried to fix the problems, but my judgment is
> >> > lacking, and
> >> > >>> >> > I'm sure that I didn't quite fix them. Quite frankly, I am
> >> > frustrated
> >> > >>> >> > with my ineptitude yet again.
> >> > >>> >> >
> >> > >>> >> > I know that the Blender Foundation doesn't need my help, and
> at
> >> > this
> >> > >>> >> > point, I am pretty sure my "help" is a burden in several
> ways.
> >> So
> >> > I
> >> > >>> >> > really wonder if it would be better without me.
> >> > >>> >> >
> >> > >>> >> > I sincerely hope it hasn't been a burden in /every/ way.
> >> > Regardless of
> >> > >>> >> > if I have or not, I think it's time I call it quits. I'm just
> >> not
> >> > >>> >> > competent enough to help out, even in a non-development role.
> >> > >>> >> >
> >> > >>> >> > I will finish out this release, but once 2.72 (and any 'a' or
> >> > other
> >> > >>> >> > subsequent bugfix release) is out, I will not "help" out
> >> anymore.
> >> > I'll
> >> > >>> >> > still be a user; Blender (and Cycles!) helped me secure a
> spot
> >> in
> >> > >>> >> > BYU's Animation Emphasis for the Computer Science major, and
> I
> >> > don't
> >> > >>> >> > intend to stop using it. But my role in its development will
> >> > >>> >> > disappear.
> >> > >>> >> >
> >> > >>> >> > Sorry, Campbell; I know you don't like doing those Release
> >> Notes.
> >> > >>> >> >
> >> > >>> >> > Thanks for everything.
> >> > >>> >> >
> >> > >>> >> > God Bless,
> >> > >>> >> > Gavin Howard
> >> > >>> >> > _______________________________________________
> >> > >>> >> > Bf-committers mailing list
> >> > >>> >> > Bf-committers at blender.org
> >> > >>> >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >> > >>> >>
> >> > >>> >> _______________________________________________
> >> > >>> >> Bf-committers mailing list
> >> > >>> >> Bf-committers at blender.org
> >> > >>> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >> > >>> >>
> >> > >>> >
> >> > >>> >
> >> > >>> >
> >> > >>> > --
> >> > >>> > With best regards, Sergey Sharybin
> >> > >>> > _______________________________________________
> >> > >>> > Bf-committers mailing list
> >> > >>> > Bf-committers at blender.org
> >> > >>> > http://lists.blender.org/mailman/listinfo/bf-committers
> >> > >>> _______________________________________________
> >> > >>> Bf-committers mailing list
> >> > >>> Bf-committers at blender.org
> >> > >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >> > >>>
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> With best regards, Sergey Sharybin
> >> > >> _______________________________________________
> >> > >> Bf-committers mailing list
> >> > >> Bf-committers at blender.org
> >> > >> http://lists.blender.org/mailman/listinfo/bf-committers
> >> > > _______________________________________________
> >> > > Bf-committers mailing list
> >> > > Bf-committers at blender.org
> >> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >> >
> >> >
> >> > --
> >> > - Campbell
> >> > _______________________________________________
> >> > Bf-committers mailing list
> >> > Bf-committers at blender.org
> >> > http://lists.blender.org/mailman/listinfo/bf-committers
> >> >
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> >
> >
> > --
> > With best regards, Sergey Sharybin
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
>
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

More information about the Bf-committers mailing list