On Tue, 2014-12-02 at 15:35 +0000, Lehtonen, Markus wrote:
> Hi,
> 
> On 28/11/14 15:23, "Patrick Ohly" <[email protected]> wrote:
> 
> >On Fri, 2014-11-28 at 12:57 +0000, Lehtonen, Markus wrote:
> >> On 28/11/14 14:17, "Patrick Ohly" <[email protected]> wrote:
> >> >Which spec files will be "semi-automatically" maintained? I wasn't
> >>aware
> >> >that we had such a category ;-}
> >> 
> >> It's the "spec file marked for auto-update" in the diagram. Need to make
> >> the description clearer on this.
> >
> >What I meant is: which of the current Tizen git trees will be in this
> >"semi-automatically maintained" mode?
> 
> This proposal doesn't take a stance on this. Probably it would be good to
> start
> with all packages start to use the fully automatic mode in the core
> packages as
> soon as possible. The fully/semi mode would be defined in the .bb
> packaging meta
> data (in the per-pkg git repo) so it would basically be the package
> maintainer's
> call which one to use.

I can't think of any real usage for this semi-automatic mode and
therefore propose to remove it from the proposal. It'll make the
automatic tooling simpler, which IMHO is good.

> >> The idea behind the auto-generation of .spec-related patches for the
> >> "semi-automatic" packages was to work as a gentle push/reminder towards
> >> maintaining the packaging metadata in .bb. That could be removed, if
> >>seen
> >> useless/redundant/annoying.
> >
> >I suspect that you mean packages where someone has created a .bb file
> >once, while others continue to use and edit .spec files. If yes, then
> >pushing the generated .spec for review will essentially undo the later
> >manual changes to the .spec file. I don't think we should do this.
> 
> If not pushing an updated patch, an option would be to put an automatic
> comment
> to Gerrit that "I see only .spec was changed, you should preferably update
> .bb instead".
> What do you think?

I think such reminders are better handled outside of the workflow, for
example by doing regular scans for packages maintained as .spec, and
then taking appropriate action.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to